> Hi there,
>
[quoted text clipped - 9 lines]
> this situation but in any case, the form hasn't even been created yet. Is
> it therefore normal for some form-based events to be fired while the
Yes, that happens.
> constructor is still running. If so then it's potentially dangerous to
> define events using the forms designer so we should presumably add them
> ourselves in "OnLoad()" typically (or otherwise design all handlers to
> check that the window has actually been created which is ugly IMO). Can
> anyone elaborate on this situation. Thanks.
The designer registers events as the last thing it does for any control.
Usually that's good enough. In a couple cases you have to register the
handler later yourself, I've seen that too.
Robert Brown - 12 Jan 2007 00:31 GMT
>> Is it normal for form-based events to fire in "InitializeComponent()".
>> I've got a "DataGridView" on a form and I set its "CellValueChanged"
[quoted text clipped - 10 lines]
>
> Yes, that happens.
Ok, thanks for the confirmation. It's arguably a questionable design however
since these events really seem to be intended for the post-window (creation)
environment. It's even possible for this problem not to surface until your
program has been released (though in practice it's likely to be caught long
before that).
>> constructor is still running. If so then it's potentially dangerous to
>> define events using the forms designer so we should presumably add them
[quoted text clipped - 5 lines]
> Usually that's good enough. In a couple cases you have to register the
> handler later yourself, I've seen that too.
Ok, I'll exercise caution from now on. Thanks again.
RobinS - 12 Jan 2007 06:41 GMT
Don't set the event in design mode. Do it in your Form_Load routine.
That will take care of your problem.
Robin S.
-------------------------
>>> Is it normal for form-based events to fire in
>>> "InitializeComponent()". I've got a "DataGridView" on a form and I
[quoted text clipped - 29 lines]
>
> Ok, I'll exercise caution from now on. Thanks again.