>>When I run a form how do I determine which object's init runs first. Is it determined by the taborder?
>>
>------------------------------------------- REPLY ----------------------------
>Matthew:
>
>Sorry, I did not monitor the UT yesterday so my reply is a little late. But here it is....
>
>Every other OOP language I know of provides for a means of reordering objects so that you can initialize them in the order you need. VFP for some reason does not. This is a great pain in the very low part of the neck when you need control A to initialize so that control B can be initialized in a certain way depending on a property of control A.
>
>David has indicated the most common method of handling the problem, which is to put all of the code needed to set the relationship between controls in the init() of the container on which they reside. That way you can be sure that all of the controls referred to in your code already exist.
>
>Another way is to remove all of the controls from your form and then copy them back one by one in the order you want them to fire. To me this is the most practical way -- it actually takes very little time, reduces coding and minimizes initiation time since all manipulation is done in the control's init() object -- not in the controls init() object then again at the container level. Since most of the controls on a form are irrelevant to firing order (labels and such), copy them in a block.
>
>The last, and most important thing, to do is drill M$ for not including a positive means of setting control order -- maybe they will add this critical feature in a future version if enough of us complain -- probably not, but one can hope.
>
>Regards,
>
>JME

Basically, it's all right, but why it's a great pain that you don't know what object is initializing first? Besides convenient Form.Init event, you can even create necessary objects programmatically and be sure that you fire AddObject in necessary place.