Is this normal

Hi there,

Is it normal for form-based events to fire in "InitializeComponent()". I've
got a "DataGridView" on a form and I set its "CellValueChanged" event using
the forms designer. Ok, VS initializes my event in "InitializeComponent()".
However, "InitializeComponent()" later calls
"ComponentResourceManager.ApplyResources()" which (to my great surprise)
fires my event (which my handler then chokes on since it thinks the window
is already running). Looking at the call stack, the event was fired while
initializing the header text on one of my "DataGridView" columns (from the
resource file). I'm not sure if this particular event should even apply in
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
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.

"Robert Brown" <no_spam@_nospam.com> wrote in message
news:ugjzZjdNHHA.4604@TK2MSFTNGP06.phx.gbl...
> Hi there,
>
> Is it normal for form-based events to fire in "InitializeComponent()".
> I've got a "DataGridView" on a form and I set its "CellValueChanged" event
> using the forms designer. Ok, VS initializes my event in
> "InitializeComponent()". However, "InitializeComponent()" later calls
> "ComponentResourceManager.ApplyResources()" which (to my great surprise)
> fires my event (which my handler then chokes on since it thinks the window
> is already running). Looking at the call stack, the event was fired while
> initializing the header text on one of my "DataGridView" columns (from the
> resource file). I'm not sure if this particular event should even apply in
> 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.

>> Is it normal for form-based events to fire in "InitializeComponent()".
>> I've got a "DataGridView" on a form and I set its "CellValueChanged"
>> event using the forms designer. Ok, VS initializes my event in
>> "InitializeComponent()". However, "InitializeComponent()" later calls
>> "ComponentResourceManager.ApplyResources()" which (to my great surprise)
>> fires my event (which my handler then chokes on since it thinks the
>> window is already running). Looking at the call stack, the event was
>> fired while initializing the header text on one of my "DataGridView"
>> columns (from the resource file). I'm not sure if this particular event
>> should even apply in 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.

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
>> 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.

Ok, I'll exercise caution from now on. Thanks again.

Don't set the event in design mode. Do it in your Form_Load routine.
That will take care of your problem.

Robin S.
-------------------------
"Robert Brown" <no_spam@_nospam.com> wrote in message
news:OcQmzDeNHHA.1248@TK2MSFTNGP02.phx.gbl...
>>> Is it normal for form-based events to fire in
>>> "InitializeComponent()". I've got a "DataGridView" on a form and I
>>> set its "CellValueChanged" event using the forms designer. Ok, VS
>>> initializes my event in "InitializeComponent()". However,
>>> "InitializeComponent()" later calls
>>> "ComponentResourceManager.ApplyResources()" which (to my great
>>> surprise) fires my event (which my handler then chokes on since it
>>> thinks the window is already running). Looking at the call stack,
>>> the event was fired while initializing the header text on one of my
>>> "DataGridView" columns (from the resource file). I'm not sure if
>>> this particular event should even apply in 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.
>
> 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 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.
>
> Ok, I'll exercise caution from now on. Thanks again.
>