Unanswered: ListIndex won't update when form is bound
There are several (about 5) screens where the user can do different things for a Part Record.
I have a set of controls, including a combo box, that allows the user to select a Part ID. I use the same set of controls, and underlling code, on each form (efficient coding, consistent appearence for the user).
Along the bottom is a set of buttons to move across forms.
Now, I set it up so that when you press one of those buttons to move to a parallel form, if there is an active part selected (the Combo Box has a value in it) then the new form is opened with the part key in the Open Args.
When a form opens, an event checks the Open Args and if it's a valid Part Key, it sets the combo to that value and calls all the update screen events.
Four of the forms are unbound, and it works like a charm. The last form is bound and although the controls work correctly in every other way, assigning the value to the control through code doesn't (therefore foiling the "auto focus" described above).
The combo box is taking the value and even displaying the correct match, yet the list index remains -1. When the user physically selects a part, everything works fine (including the list index being correct).
Any ideas why the list index won't update? I tried triggering using the On_Current, On_Open, and On_Timer events, same results.
I have tried to manipulate list boxes index in code, but the help file explicitly states it is read only, and is updated by physical selection, as you have found.
However, I have coded round this by usung the selected item property that will highlight the required item (but not set the list index property!).
To do this you need to know the index of the selected item (OK if its a simple next/prevous selection ie current .listindex+/-1) otherwise you will have to search through the lists ID column idex (assuming the list has one) and highlight as before.
To do this you obviously know the ID of the item so you can then select the record required in code also for the form, thus keeping it all synchronised. It does take some figuring out, but it is possible.
That's for the response. You actually can assign a value to a list box directly - IF the multi-select property is set to No. That's because a "multi-select" list box always has a value of Null, whereas a "single-select" list box has a value equal to the value in the index colmn.
I'm using a Combo Box, which is single select by nature and whose Value property should always equal the data in the index column.
I did find a "work-around" that exposes an interesting glitch in Access. When the bound form opens, I immediately set the filter to "[PartKey] = -1" to clear the form (the part key will never be less than zero). It seems that, even though the Combo box is unbound, the empty recordset of the bound form causes the Combo box to a list index of -1 (meaning "not found") even if the data assigned to it is a valid value. Here's the interesting thing: even though the list index is -1, the value property actually has the correct data in it!
When the user manually selects the part (which is actually visible even though the list index is -1) it updates the list index to the right number.
I now set the form's filter to the correct PartKey before assigning the value to the Combo box and it responds correctly. So, there is appearently some relationship between a bound form's recordset and an unbound controls recordset.
btw: none of this hooey happens on my unbounds forms, which further supports my belief that you should use unbound objects whenever possible.