Yes, of course I am talking about bound controls.
Since you can't change or set values of bound controls it the on-open, then
you have to move the code to the on-load.
Now, since as a matter of the development process, then this fact kind of
hints that the on-load event is going to be where most developers are going
to put their setup and initializing code for the form. So, as a developer, I
would expect to see this setup code in the on-load event. So, while you CAN
set un-bound controls in the on-open, it certainly makes more sense to put
that setup code with all of the other code that sets the bound contorls. Of
course, if you are not setting any bound controls, then I suppose it does
not really matter. However, I would still expect to find the setup and
initialize code in the on-load. (that is where I as a developer would first
look!). You really don't want to have two locations out of habit where you
put the setup code for a form. So adopt one good programming standard. Since
you *have* to put the bound controls setup code in the on-load, then you
might as well also put the un-bound setup code there also. It just seems to
make sense to me.
Save the on-open event for verifying, and code that tests to *prevent* the
form from loading (eg: no data records, or cannot get a record lock etc).
Thus, the on-open code is for code that tests to prevent the form from
opening, it is thus has a cancel event. If that cancel is set, then all of
the forms initializing and setup code (that we now agrees goes in the
on-load event) will not even run! I mean, why run all the forms setup code
if we cancel the load by using the on-open cancel ability?
The split between on-load, and on-open shows a fabulous design decision the
by Microsoft Access developer team. VB never did have a cancel event, nor
this natural split between form open code that can cancel, and the form load
that is used for setup code. Access is really nice in this regards.
