Good to know, Douglas. I should have qualified my information that my team was (a) under time pressure to make something work and (b) all self-taught on Flex so while we found solutions, they were not always optimal :-). Douglas's solution below sounds cleaner but we had never learned enough about the lifecycle to get hooks working properly with the commitProperties and the various invalidate functions. Trust him; he's posted a lot of good stuff :-)
-Marty On Mon, Feb 28, 2011 at 2:23 PM, Douglas Knudsen <[email protected]>wrote: > I will start with stating that anytime I see Application.application in > code my colon and spine tense up a bit. Yeah, that's a big red flag with the > words "You better know why" on it :) :) Thus Application.application.doLater > scares me. doLater() scares me in a similar way. > > Now, likely I'd do the following for this, hoping it'd work, seems like it > would > 1) in the onChangeHandler() set a dirty flag and call > invalidateProperties() > 2) override commitProperties, look for the dirty flag and do the work > there. > > This should allow the checkbox to re-draw itself before your taxing work > occurs. Just call enabled=false on it in commitProperties at the top of > your work block. I suspect service calls may mess with your call to > CursorManager.setBusyCursor() > if making any in the work block. > > Another approach is to make this chunk of work happen asynchronously ala a > green thread approach. Check out Charlie's talk on this a ways back and > also Huyen Due Tao's 360 talk on the same topic for more. > > Douglas Knudsen > http://www.cubicleman.com > this is my signature, like it? > > > > On Mon, Feb 28, 2011 at 12:51 PM, Marty Blood <[email protected]>wrote: > >> Dale, >> >> I've run in to similar problems to this in the past. For us it came down >> to how Flex / Flash handles the rendering lifecycle. In particular it won't >> show any UI updates (e.g. the busy cursor or the checkbox being clicked) >> until it gets another chance to render a frame. So what might work is to >> use doLater to queue up the processing call to allow the runtime to hit a >> render cycle. Something like this (syntax should be close, I don't have >> access to Flash Builder right now): >> >> private function onCheckboxClick(): void >> { >> chkBox.enabled = false; //whatever your checkbox reference is unless the >> Application.application.enabled = false disables that too. >> (Application.application as MinervaApplication).mouseChildren = false; >> Application.application.enabled = false; >> CursorManager.setBusyCursor(); >> >> Application.application.doLater( { >> //run your processing >> (Application.application as MinervaApplication).mouseChildren = >> true; >> Application.application.enabled = true; >> CursorManager.removeBusyCursor(); >> chkBox.enabled = true; //see above >> }); >> } >> >> The chkBox.enabled setting may be unnecessary depending on what your >> Application.application.enabled = false disables. >> >> Hope that helps. >> >> -Marty >> >> On Mon, Feb 28, 2011 at 12:11 PM, Dale Bronk <[email protected]>wrote: >> >>> We're having an issue hopefully someone smarter than me can help with. >>> We >>> have the following in a function (just a snippet): >>> >>> Private function onCheckboxClick() : void >>> { >>> (Application.application as MinervaApplication).mouseChildren = false; >>> Application.application.enabled = false; >>> CursorManager.setBusyCursor(); >>> >>> // Do a bunch of processing that takes a second or two where we >>> // want the user to be able to do anything. >>> // This logic does include some UI modification. >>> >>> (Application.application as MinervaApplication).mouseChildren = true; >>> Application.application.enabled = true; >>> CursorManager.removeBusyCursor(); >>> } >>> >>> We actually have the blocking/cursor logic abstracted out into a >>> function, >>> but it is easier to show what we are doing this way. >>> >>> Our issue: >>> The blocking logic doesn't take affect. We do see the app "kind of >>> freeze" >>> but with no visual and it just queues up the user actions. The checkbox >>> does not check immediately. It waits until all the logic has executed. >>> The >>> problem is that during that 1 to 2 seconds of processing the user sees >>> the >>> checkbox not checked, so they check it again. That second click will >>> queue >>> up so that once the initial check processing is done, it then processes >>> the >>> second check creating a vicious cycle between app and user. There are a >>> couple places in our app where it is critical that they wait for several >>> calculations to be done before moving on and it seems to work just fine >>> in >>> other places. Other places the cursor goes to a wait, app is disabled >>> and >>> clicks are turned off so the user go click happy all they want and >>> nothing >>> will happen. We have the app styled so that disabled app does not change >>> visually. >>> >>> Thanks, >>> Dale >>> >>> >>> >>> ------------------------------------------------------------- >>> To unsubscribe from this list, simply email the list with unsubscribe in >>> the subject line >>> >>> For more info, see http://www.affug.com >>> Archive @ http://www.mail-archive.com/discussion%40affug.com/ >>> List hosted by http://www.fusionlink.com >>> ------------------------------------------------------------- >>> >>> >>> >> >
