Best Place to Disable/Enable Menu Items at Runtime

  • Thread starter Thread starter Raeldor
  • Start date Start date
R

Raeldor

I put my code to disable/enable menu items at runtime into the paint event,
but then realized that if the user executes the shortcut key that the paint
even of course doesn't get triggered first, so the user can execute code
that should be not executable.

What is the best place to put this code? I didn't want to have to be
enabling and disabling all over my code, I just wanted one place where I can
check various statuses and enable/disable.

Thanks!
 
Hi Raeldor,

Can you tell me in which control's paint event you called the menu items
disable/enable code?

Yes, normally, Paint event is only fired when part of that control needs to
be repainted. Usually, this is triggered when part of this control is
overlayed by other form/control and reappear again. So it is likely that
when you are pressing the shortcut key, the Paint event is not fired yet,
which causes the menu item to be not updated. I assume this is your
problem.

Normally, we should not place the menu items status change code in the
paint event, because this will delay this code logic execution to the paint
event. So the solution to your problem lies with what program logic you
used to change menu items status. You should execute the status change code
immediate after certain condition is changed. This is the correct solution.

For example, your logic may be that: if the focus is in TextBox control,
you should enable the menu item, otherwise, you should disable it, then you
should execute the status change code in TextBox.Enter and TextBox.Leave
events.

Ok, I see that your concern may be that there are several conditions the
code need to check, so using my suggestion, you have to place the code in
all the condition events/methods.

Yes, I understand this concern. I think you have 2 reasons to this concern:
1. Executing the methods in several conditions may have performance issue.
2. Place code in multiple places may be hard to maintain.

#1 is not a problem, placing the code in Paint event will have much worse
performance result because Paint event is fired many times.
Regarding #2, I recommand you place the conditions check and status change
code in a single method, then in all the places, you may only change
certain condition flag, and just invoke this single
conditions-check-and-status-change method. This will allow you to maintain
the code in a single method and get rid of the delay update problem.

Hope this helps.

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.
 
Makes sense, thank you. I will implement it this way, but I can't help but
think that for something like a menu it would be much easier for it to have
some kind of event to allow you to enable/disable the menu (return value
from the event?) both for painting and for execution. Seems this is a very
common thing to do and that it would make life easier to have events for
common tasks. Just my 2c.

Thanks for your reply.
Ray

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

Can you tell me in which control's paint event you called the menu items
disable/enable code?

Yes, normally, Paint event is only fired when part of that control needs
to
be repainted. Usually, this is triggered when part of this control is
overlayed by other form/control and reappear again. So it is likely that
when you are pressing the shortcut key, the Paint event is not fired yet,
which causes the menu item to be not updated. I assume this is your
problem.

Normally, we should not place the menu items status change code in the
paint event, because this will delay this code logic execution to the
paint
event. So the solution to your problem lies with what program logic you
used to change menu items status. You should execute the status change
code
immediate after certain condition is changed. This is the correct
solution.

For example, your logic may be that: if the focus is in TextBox control,
you should enable the menu item, otherwise, you should disable it, then
you
should execute the status change code in TextBox.Enter and TextBox.Leave
events.

Ok, I see that your concern may be that there are several conditions the
code need to check, so using my suggestion, you have to place the code in
all the condition events/methods.

Yes, I understand this concern. I think you have 2 reasons to this
concern:
1. Executing the methods in several conditions may have performance issue.
2. Place code in multiple places may be hard to maintain.

#1 is not a problem, placing the code in Paint event will have much worse
performance result because Paint event is fired many times.
Regarding #2, I recommand you place the conditions check and status change
code in a single method, then in all the places, you may only change
certain condition flag, and just invoke this single
conditions-check-and-status-change method. This will allow you to
maintain
the code in a single method and get rid of the delay update problem.

Hope this helps.

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 Raeldor,

Glad to see my reply makes sense to you.

Based on my understanding, you think that it is better that MenuItem class
can provide an event, which will use the event handler return value to
indicate the menu item enable/disable status.

Yes, I understand this event is what you want. However, every event should
be triggered at a suitable time by code , when designing MenuItem class,
can you tell me when should this event fire? I can not think of a logic
suitable time for this event. Actually, this event fire time totally
depends on your program logic, the MenuItem class(FCL designer) can not
determine when you want to fire this event, so MenuItem class can not
provide a such event, but expose the enable status operation through the
property.

So the correct logic is placing the code in whatever time you want to
change the menu item status, and executing the enable status change code at
that time. There can not be a single event for your customized program
logic.

Actually, since you are aware of your program logic, you can define an
customized event, and you can fire this event in the correct place you want
this event to fire, and then you may place the code logic in this event.
But I think this approach is somewhat the same as I first provided.

Hope this express my thought clearly. 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.
 
The event would have to be triggered by both a paint of the menu or a
selection of one of the menu's items via hotkey.

It seems all the examples out there on the web for dynamically enabling and
disabling menu items rely on the paint event of the menu item. It kind of
makes sense, but just doesn't account for the hot-key approach of executing
the items. I guess the other option is to use is to just check the enabled
status of the menu item in the click event of the menu item before executing
the code. This would prevent the possibility of the hotkey being used to
activate the item and still allow your code for enabling and disabling to
remain in a single place.

I can certainly see your where you're coming from by enabling and disabling
as the statuses change, but this seems like a rather old-school approach and
would certainly result in a lot more code (or calls assuming you put the
checks into a single function) and would not be as elegant as having it in a
single event. I would be interested to see how Microsoft's internal .net
applications handle this issue.

Thanks again

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

Glad to see my reply makes sense to you.

Based on my understanding, you think that it is better that MenuItem class
can provide an event, which will use the event handler return value to
indicate the menu item enable/disable status.

Yes, I understand this event is what you want. However, every event should
be triggered at a suitable time by code , when designing MenuItem class,
can you tell me when should this event fire? I can not think of a logic
suitable time for this event. Actually, this event fire time totally
depends on your program logic, the MenuItem class(FCL designer) can not
determine when you want to fire this event, so MenuItem class can not
provide a such event, but expose the enable status operation through the
property.

So the correct logic is placing the code in whatever time you want to
change the menu item status, and executing the enable status change code
at
that time. There can not be a single event for your customized program
logic.

Actually, since you are aware of your program logic, you can define an
customized event, and you can fire this event in the correct place you
want
this event to fire, and then you may place the code logic in this event.
But I think this approach is somewhat the same as I first provided.

Hope this express my thought clearly. 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 Raeldor,

Yes, based on my review, I think your suggestion of defining a new event
makes sense. This event will be more convinient to define the logic for
menuitem status change.

However, current .Net MenuItem class does not get this done yet. Maybe our
Winform team believes that keeping the event model clear is the good
practise, so they try to give us more freedom of customizing the code model
with the old-school approach. Anyway, I think it is a good idea for you to
feedback this suggestion in the .Net Framework feedback center below:
http://connect.microsoft.com/feedback/default.aspx?SiteID=210

Our product team will receive your feedback and give it a judge. 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.
 
Back
Top