>Each combo represents a name of a location, those names are given by four different people. All four names are stored in one record. Now the problem is, the name may or may not be listed in each box but will be listed in one of them. So, if a user looks for the option in box1, its not there, boom, interactive change your done.
>

You have a serious design flaw, because the unique occurance of any given name in any given box might have multiple occurances in a single column. Behaviorally, you don't have 4 distinct lists that inferentially are tied together; only one needs to be an incrementally searched thing at any moment.

A grid that displayed the the value of all 4 columns, and a combobox that could be tied to the distinct list for the column last clicked if you really, really had to have a combobox to do a search migth fit your data a lot better, or if a name can only occur in one column one time, and never in another column, a union of the distinct sets tied to the common pkey (I think what Barbara P might be suggesting) or any of a number of other models might work lots better than the idea you have, which has no ability to logically operate the way you want would be better, because of the seemingly non-conssitent interaction between the 4 separate controls. You're making what is really a simple problem very hard with a bad interface.

In fact, a 4 column grid, and a textbox that did an incremental search in the currently-selected column of the grid, with nothing more than 4 indexes (one per searchable column) and a shift of the controlsource and active index for the table 'behind' the whole thing to search the right column using the textbox seems pretty obvious, given the behavior you want, with whatever you want for data entry - the search controls need not be the data entry controls. Two pages of a pageframe maybe, or two distinct parts of a single form - one the search, the other the detail of what the current detail record was...