The Joy of Flex

(One in a series of random, daily, useful Flex tips.)

Say you have a button that causes your application to do something big, like switch modes. And say you want to make sure that, after the user presses the button, they can’t operate the UI until the mode change is complete. You are probably handling this by setting Application.enabled to false at the beginning of the operation, maybe in the click handler, and then setting it back to true after the operation is over.

Unfortunately, this leaves open a small window of opportunity where the user could click a second time before the application really beomes disabled. If you want to be sure that no further user action will be processed after you set enabled to false, then be sure to call validateNow() as the next line of code.

What window of opportunity, you ask? It’s between when you set Application.disabled to false and when the Application’s commitProperties() is executed: the invalidateProperties()/commitProperties() cycle. As with many property setters in the Flex framework, calling the Application.enabled setter doesn’t actually disable the application immediately. Instead, a flag is set, invalidateProperties() is called, and then the next time into the scripting engine, commitProperties() is called by the framework. In the Application’s commitProperties() method, the flag is checked, and if appropriate, then the application is disabled.

The invalidateProperties()/commitProperties() cycle is a good thing: it ensures that all property changes to an object during a scripting engine call take place at the same time, and prevents lengthy or expensive operations from being toggled repeatedly during the call. And it’s really important that, even for an operation like setting enabled to false, you be required to call validateNow() if you want it to take place immediately. If it didn’t work that way, then there’d be no good way to handle the situation where you want setting enabled to false and back to true before the stack unwinds to have no effect.

The window of opportunity is pretty small. In my testing, I was only able to get a second click in during this window if I could get the two clicks to both back up behind some other modal operation, such as a modal network request. It’s possible that another way to address this problem would be to set doubleClickEnabled to true on the button being clicked, and handle the double-click event just like a single click. This way, the second click would be consumed as part of the double-click rather than being handled separately. But I suspect it would still be possible to get two double-clicks in under some circumstances.

It’s probably also a good idea to call validateNow() after setting a button’s enabled property to false. The classic example is the “Buy” button in a shopping cart. I haven’t tested this case, but it seems possible that the same problem could occur with any component, not just the Application.

Technorati Tags: Flex, Flex Tip of the Day