Interesting problem. I was bored so I took a shot. This isn't perfect but it may suit your needs. At any rate, it may be as close as your going to get to what you actually want to achieve.
Here's the crux. Cascading combo boxes on continuous forms have always been problematic from a display standpoint because of the nature of continuous forms as you alluded to earlier. One of the tricks for solving this problem is to base the form on a query (which IMO you should always do anyway, not directly on a table). In the query you add the table(s) that are the row sources for your combo boxes. You then add the fields that represent the values that are
displayed in your combo boxes. Then, in your form you create text boxes that are bound to these fields (so the combo boxes are bound to the
key fields and the text boxes are bound to the
displayed fields, if that makes sense). You then size the text boxes the same height and width as the combo boxes (minus the width of the drop down arrow itself) and place them on top of the combo boxes (be sure to set "Bring To Front" form the Format menu for the text boxes). In the Got Focus event of each text box you set focus to the corresponding combo box so when the user clicks or tabs into it the focus will immediately go to the combo box instead. You also want to lock the text boxes. It looks like one combo box, but the text boxes will display the correct value for each row because they are bound to those fields.
However, that method is based on the idea that all the combo boxes are still bound to a key field in the form's record source. Throwing unbound combo boxes into the mix adds some more twists. To get this to work (at least somewhat) you end up having to create two continuous forms. One is for entering
new records (Data Entry property set to True) and the other is for
existing records (Allow Additions property set to False). Then you stack them as subforms in another form. In the After Update event of the "data entry" form you requery the "existing records" form.This is also a known work around but it is typically just used because some folks like to have the data entry row be at the top of the continuous form instead of the bottom. If you format and size everything right it looks essentially like one continuous form with the new record row at the top. In this case it was necessary because for new records, those text boxes that are supposed to display the values don't actually have any values to display until
after you select something in the third combo box (because it is the only one that is actually bound). It looked very odd because the first two combo boxes appeared blank (even though a selection had been made) until after the selection was made in the third combo box.
The other problem I ran into (because of the combo boxes being unbound) is that the left most combo box appeared blank on the first record in the existing records form when it was first opened. This was due to the fact that it was the first control to receive focus since it was first in the Tab order. To solve this I placed a text box on the form and made it "hidden". I did not set it's visible property to false because you cannot set focus to a control that is not visible, I just made it so small that you can't see it. It is at the extreme left of the row. If you want to do anything with it you'll have to select it from the property list and then change the width so you can see it. Anyway, that text box (txtHidden) is first in the tab order so it gets the focus when the form is first opened, allowing the first combo box to display correctly. If you want to see what I mean about what was happening, just change the tab order so that txtHidden is not first in the list, then re-open the form.
A couple of other things to note. The "data entry" (new records) form does not use the stacked text box trick. It's not necessary because it will always be only one row. Also,if your current form is already based on a query, then depending on the nature of that query (whether there is already more than one table involved and the type of joins if there is) then adding these other tables to it
could render it read only. If that happens then everything I just said will be completely useless to you (let's hope not, that was a lot of damn typing
).
Anyway, I'm attaching the example db. Form5 is the main display form. It's not a perfect solution, there are still some minor glitches like the unbound combo boxes appearing blank for just a second as you tab through the record. Maybe some of that can still be worked out, I'm not sure. It might work for you, it might not. Like I said, I was bored so what the hell.
