What happened to UpdateCommandUI?

[SugarDaddy]

I'm pretty new to C#, but I've had a lot of experience with MFC. MFC
had a mechanism for updating dialog controls using an idle message.
For those unfamiliar, basically you would override OnIdle and call
UpdateDialogControls(), and that would send WM_UPDATECOMMANDUI messages
to all the controls in the dialog. Then you could add handlers for
each control that you wanted to update. For example, if you wanted a
button to be disabled if some text box was empty, you would add the
UpdateCommandUI handler for the button that would check the state of
the text box. It was very useful, and completely undetectable as far
as the user goes (no flicker).

I can't seem to find that kind of mechanism in C#. I can create an
Idle handler for the application and call Update() for all the
controls, but the handler for Update isn't called unless the control is
invalidated -- so that's no good. So I've tried calling Invalidate(),
and then create a handler for Invalidate on each control. However, by
calling invalidate, it creates an annoying flicker in many controls --
basically any control that's not a button.

I figure there must be a way, and microsoft wouldn't completely leave
it out, but I could be wrong. Any help would be appreciated.

 

[Daniel O'Connell [C# MVP]]

I'm pretty new to C#, but I've had a lot of experience with MFC. MFC
had a mechanism for updating dialog controls using an idle message.
For those unfamiliar, basically you would override OnIdle and call
UpdateDialogControls(), and that would send WM_UPDATECOMMANDUI messages
to all the controls in the dialog. Then you could add handlers for
each control that you wanted to update. For example, if you wanted a
button to be disabled if some text box was empty, you would add the
UpdateCommandUI handler for the button that would check the state of
the text box. It was very useful, and completely undetectable as far
as the user goes (no flicker).

I can't seem to find that kind of mechanism in C#. I can create an
Idle handler for the application and call Update() for all the
controls, but the handler for Update isn't called unless the control is
invalidated -- so that's no good. So I've tried calling Invalidate(),
and then create a handler for Invalidate on each control. However, by
calling invalidate, it creates an annoying flicker in many controls --
basically any control that's not a button.

I figure there must be a way, and microsoft wouldn't completely leave
it out, but I could be wrong. Any help would be appreciated.

I don't know of anything specifically to do this. Most of the time I would
probably handle that in the TextBox's TextChanged event since I only need
the code to execute when the textbox's state changes rather than on idle
ticks. Still, you should be able to roll your own implementation without
much trouble, shouldn't you?

 

[SugarDaddy]

Oh, it's not an issue of moving existing code to .NET. I was just
wondering if .NET included the same mechanism that MFC had.

I guess the model has changed, and it breaks the abstraction concept.
What I mean by that is: If I want a button to be enabled or disabled
based on the state of another control (checkbox, textbox, whatever...)
then it's the job of the button to monitor the state of that control
because the button knows about what controls it depends on. Now, with
the seemingly new model, the button still remains a dependency, but the
button doesn't know about what it is a dependency of. Only the
controls that have the button as a dependency know about the button.
So instead of controlling the state of the button within some handler
of the button, I know have to control the state of the button from
within handlers for the controls that the button depends on. Basically
it changed from all the code in one spot to all the code in multiple
spots. It's ugly, and it seems like Microsoft wouldn't have left out
this wonderful mechanism since .NET includes so much more than MFC had.

But thank you for your response. It's not an issue of not knowing how
to code it. It's an issue that it's basically a hack of the
UpdateCommandUI mechanism of MFC.

 

[Bob Powell [MVP]]

This doesn't exist in Windows Forms controls.

MFC was an application framework and provided lots of additional
functionality that helped out a lot. Windows Forms is a loose collection of
individual controls. No control / form / application integration is
provided.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[SugarDaddy]

I figured as much. Oh well. Thanks for the reply.

 

[Daniel O'Connell [C# MVP]]

Oh, it's not an issue of moving existing code to .NET. I was just
wondering if .NET included the same mechanism that MFC had.

I guess the model has changed, and it breaks the abstraction concept.
What I mean by that is: If I want a button to be enabled or disabled
based on the state of another control (checkbox, textbox, whatever...)
then it's the job of the button to monitor the state of that control
because the button knows about what controls it depends on. Now, with
the seemingly new model, the button still remains a dependency, but the
button doesn't know about what it is a dependency of. Only the
controls that have the button as a dependency know about the button.
So instead of controlling the state of the button within some handler
of the button, I know have to control the state of the button from
within handlers for the controls that the button depends on. Basically
it changed from all the code in one spot to all the code in multiple
spots. It's ugly, and it seems like Microsoft wouldn't have left out
this wonderful mechanism since .NET includes so much more than MFC had.

I don't think its all that different. Whats the difference in subscribing to
a UpdateCommandUI handler and subscribing to a TextBox.TextChanged handler?
Only difference is you have to subscribe to multiple events instead of one.

 

[SugarDaddy]

Yeah that's the difference. It's not a big deal. That's the way I was
doing it. I was just wondering if I was missing out on an easier way
of doing it.

But basically I can get the same effect if I create a method such as
"UpdateControl()" and call UpdateControl from each one of the handlers.
I guess it's a bit more efficient as well, since you're only calling
update when it needs attention rather than calling update on every idle
messages.