>>>>>because the init is one of the last things happening... think about the events at the form level, where each and every aggregated control is added and then fires its init before the form init...
>>>>>
>>>>>HTH
>>>>>
>>>>>thomas
>>>>
>>>>I am trying to understand what you saying (and thank you, of course, for your help). Are you saying the control is first added to the container and then INIT of this control fires? If so, this is news to me.
>>>
>>>Yupp. At the form level the load was added to give you a chance for needed actions like opening cursors / tables and so on. Add logging the own name in each init and watch. vfp init#constructor!
>>>
>>>regards
>>>
>>>thomas
>>
>>I think I understand it now but I don't think it applies to my case. In the LOAD of the form NOTHING happens concerning the control in questions. This control resides on a container. The the container is dynamically added to the form in the INIT method of the form. And when watching in the debugger I can see how all other controls of this container are being instantiated but not the control in question.
>
>Yes - the order "working from inside" happens on each vfp control able to contain other controls when these are added at design time. Your container "works/initializes" each control until it comes to your cbo, which errors out before it's init fires. the container control init fires after each cotained controls init - but only if no error happens before, which does in your case.
>
>HTH
>
>thomas

I agree with you that this is what happens. But what puzzles me is why the container "check" for the alias used in the RowSource of the combo control (and of course does not find the alias) instead of first calling the INIT of the control. I have another form that has a container (also dynamically added) that uses exactly the same control and no problems there. Thank you for helping me understand the issue and hopefully get to the solution.