Is there a way to be able to catch changes of the WebControl.Enabled property?
You can’t capture Webcontrol.Enabled, but if you subclass WebControl (or any control subclassed from WebControl) you can do this in a sneaky way.
In a subclassed WebControl, add this method:
Sub Enabled(Assigns NewValue As Boolean)
WebControl(Me).Enabled = NewValue ' cast the control as a generic WebControl and set its Enabled Property
' put your code here
End Sub
This method shares the name of the Webcontrol's property, and will be called in favor of the property whenever a value is assigned using the MyControl.Enabled=Value syntax.
Here’s a simple example project that demonstrates this technique on a WebTextControl.
I suggest that you cast to the class that you subclassed from. Some of the Web Controls override the functionality (when sending commands to the browser) and using WebControl may not fire the right events.
[quote=40052:@Andrew Lambert]You can’t capture Webcontrol.Enabled, but if you subclass WebControl (or any control subclassed from WebControl) you can do this in a sneaky way.
In a subclassed WebControl, add this method:
Sub Enabled(Assigns NewValue As Boolean)
WebControl(Me).Enabled = NewValue ' cast the control as a generic WebControl and set its Enabled Property
' put your code here
End Sub
This method shares the name of the Webcontrol's property, and will be called in favor of the property whenever a value is assigned using the MyControl.Enabled=Value syntax.
[/quote]
This is known as shadowing and you may end up with some hard to track down issues when you do this
We generally recommend against it
[quote=40083:@Norman Palardy]This is known as shadowing and you may end up with some hard to track down issues when you do this
We generally recommend against it[/quote]
I did say it was sneaky 
Sneaky is one way to describe it
Problem causing is another - that’s generally what you get from doing it
If you cast a custom subclass of a built-in class as the built-in class, then it’s up to the you to ensure that the subclass can be safely coerced in such a way. Casting built-in classes as their superclass can certainly be a minefield, but with specific reference to the Enabled property of RectControl (on desktop) I havent seen any problems. WebControls are very different beasts, but it works on my machine.
My experience in the past showed me that shadowing works until something goes wrong… And then It can turn into a real nightmare to debug.
I need to know when a webcontrol is disabled or enabled to change its aspect accordingly. I thought WebImageView would do the trick but since I can’t catch a state change, I’ll try to use a WebCanvas where I can simply test the Enabled property in the Paint() event.
Eric, when I first started building web apps, I thought that enabling controls in perceived real time like I do in desktop apps was really important. In deployment practice, I find that network and server conditions can often work against the perceived real-time aspect of things. At some point, it just adds confusion as the user perceives they could click some control, then 1/2 second later, can’t for no apparent reason. To me, it seems better to mostly keep controls enabled, throw in a “help” label to tell the user what they need to complete some action, and check that things are completed when they click “OK” or whatever. Real-time enabling would work great if it just ran client-side, but that’s tricky with the WE framework.
Unfortunately I can’t use help text because the final users will be between 3 to 5yo.
So what do you do if they click an apparently enabled control that is waiting for the server to tell it to disable itself? If you deploy on the real Internet and not in a tightly controlled local environment where you can guarantee low latency on every request, that will happen.