TreeView multiple selections

  • Thread starter Thread starter Guest
  • Start date Start date
Hi, Jeffrey:

I didn't question Control's event order in general, but here the events in
both applications and Overrides On***() and our codes inside them when
customized.

Keep in mind the context is that we are customizing TreeView so we put codes
in Overrides On***() events.

Let's see an event order:
OnNodeMouseClick() --> .NodeMouseClick() --> OnAfterSelect() -->
..AfterSelect().

The order is by design. It looks ok.
But after we customized it, we have codes in OnAfterSelect(). Now we can see
application's .NodeMouseClick() is run before Overrides OnAfterSelect().

In other word, app's codes run before Control's customizing codes.

But I expect all customizing codes are run before any app's codes. So app's
codes can have the correct outcome from customizing codes. But that's not the
case. That's what I mean by "mingle".

Thanks.

Li
 
Hi Li,

Thanks for your detailed explanation!

Ok, I see your key concern now. However, there is no design spec or
document stating that "all customizing codes should run before any app's
codes". There is no guarantee for this, so you should not take this as
assumption. Actually, events are not magic; it is always the OnXXX method
internally fires the XXX event. So the control events order are always
OnXXX->XXX->OnYYY->YYY. You'd better use this design order instead of that
assumption.

If you wanted that your code is fired very early, maybe you should place
them in the constructor of the control class. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi, Jeffrey:

Thanks for your message.
Basically we share the same point now. Just want to make some side notes:
(Feel free to not continue this discussion if you don't want to)

1) Design order: OnXXX->XXX->OnYYY->YYY.
The problem is when we customize a control, we don't know XXX or YYY. We
implement OnXXX and OnYYY. Then we give this customized control to other
developers. They will use it in various app and implement different XXX. They
don't care what is in OnYYY. We don't want them to check OnYYY before they
design their XXX. And in some cases they can't even see the OnYYY (it is by a
..dll).

2) Place them in the constructor of the control class.
In some cases we still need an event to implement something. For instance,
we need a click event to implement multiple selection. If users do nothing,
nothing happens. In this case a constructor will not do.

3) My thinking is that basically it is not safe to use On*** events to
customize a control. You never know how other developers fire their app
events. Just like what you said, the design should base on
OnXXX->XXX->OnYYY->YYY. But when we base on XXX/YYY, it is not a customized
control. It is a case by case design. We may just better off move OnXXX's
codes to XXX to make it more straightforward.

I didn't say we cannot do it in an app. What I said is we can't customize it
in this way.

Thanks.

Li

"Jeffrey Tan[MSFT]" said:
Hi Li,

Thanks for your detailed explanation!

Ok, I see your key concern now. However, there is no design spec or
document stating that "all customizing codes should run before any app's
codes". There is no guarantee for this, so you should not take this as
assumption. Actually, events are not magic; it is always the OnXXX method
internally fires the XXX event. So the control events order are always
OnXXX->XXX->OnYYY->YYY. You'd better use this design order instead of that
assumption.

If you wanted that your code is fired very early, maybe you should place
them in the constructor of the control class. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
Hi Li,

Thanks for your feedback.

Below are some options from me:
You should treat OnXXX like an event. We seldom use the XXX events in the
customized control, they are used for the application developer instead of
control author; as customize control author we should use OnXXX for event
processing.

Yes, I agree that application developers know nothing about the OnXXX(they
are protected methods). Application developers should use XXX events for
processing. But I did not see any problem here. As the customize control
author, the advantage of using OnXXX method is that your code can choose to
execute before and after this XXX event, although there is no guarantee
that OnXXX will execute before all XXX, YYY, ZZZ events.

I am not sure why do you say "it is not safe to use On*** events to
customize a control. You never know how other developers fire their app
events". Actually it is the OnXXX fires XXX event, not application
developers:
OnXXX(Argument e)
{
//customize control author code that executes before XXX event
if(XXX!=null)
{
XXX(e); //fires XXX event
}
//customize control author code that executes after XXX event
}

Does this make sense to you?

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top