C-D2:
Thanks for you time. I have a tabbed input form for my customer. One tab has a phone-number subform on it. The subform has two command buttons, one opens a form to Add a new phone number for the customer. The other button opens a form to Edit the phone number for the customer. The edit button appears on each row for which a phone-number is displayed. The Add/Edit forms have fields for phone-type, phone-number, phone-note, assistant-name, preferred checkbox, etc. The phone-number subform only displays the phone-type, phone-number and phone-note. It is a continuous form, one phone number being displayed per row. Since the subform is used for display purposes only, not for edits, using the combo-box technique that you suggest, makes it appear as if the data can be edited on this form. Clicking on the combo-box even opens the drop-down tho' no selection can be made. If I add the phone-type field as a combo-box and then change it to a text-box, only the phone-type-ID (autonumber) appears. What I had to do was really sloppy. I just did away with the ID fields in my reference tables so "Home Phone", for example, became the key item, not an autonumber. Yeah, yeah, really messy. And of course as my application gets more and more complex, it is biting me in the butt. For some of my reference tables I have had to add back in the ID autonumber and then I use a combo-box to display the item I want and hide the drop-down arrow with a text-box cleverly colored to look like the form in the background.
This is a bigger problem than I describe because I have a dozen of these display subforms. I use this oddball Add/Edit button/form technique because we store so much minutia in each table that is useful for querying etc, but not something the user needs to see on the screen all the time. It boils down to just not enough real estate to display all the info on each of the subforms.