:::: MENU ::::
Posts tagged with: flashbuilder

Debugging Flash/Flex Apps in Google Chrome (and killing the cache)

Since switching over to Google Chrome as my default browse some months back, I have had one persistent (see also annoying) issue: I have been unable to get the Flash Debugger to run properly in Chrome. I initially tried a number of fixes, none of which seemed to resolve the issue. Eventually, I gave up, and simply started using FireFox for debugging. Fast-forward a few months, and I am now ready to bail on FireFox due to memory usage issues (my Macbook AIR has almost gone up in smoke a few times thanks to these lil problems). To add to the fire, I have also been dealing with the HUGELY bothersome (and very common) issue of the browser caching my .swf files while I am debugging (i.e. I run debug, and the file displayed is a cached version, so I end up trying to resolve bugs that may not even exist anymore). So this morning, sitting in a cafe in Little Italy (San Diego), listening to the rain falling softly on the concrete outside, I decided it was high time I tackle theses issues. Luckily for me (and you), the solutions came quickly, and I now have Google Chrome debugging my flash builds, and running the latest build every time no less!

Debugging in Chrome:

Aaron West wrote a nice blog post outlining the how to make sure Google Chrome is using the debug version of the flash player here: http://www.aaronwest.net/blog/index.cfm/2010/4/27/Configuring-Chrome-with-Flash-Player-Debugger . Aaron did a very nice job of explaining the changes necessary to make force Chrome to use the debug player, so I will not reiterate them here; however, I will add one thing (which turned out to be the missing link for me): In order to find the correct Flash plugin to disable, you may first need to click the “Details” link in the upper right-hand corner of the screen. Doing this will expand the list of plugins (in my case, there were 2) and allow you to disable the correct one.

Plug ins













Disabling Caching:

I saw a number of fixes for the caching issue, some of them better than others, but none quite as elegant as I would hope (i.e. a setting in Chrome to simple disable caching). Then I came across a blog post by Andre Gil’s (sorry for the spelling, I don’t know how to make the fancy accent over the e), which outlined a very nice solution in which Andre had written a small application that essentially gives you the option to launch Google Chrome with the cache disabled. You can get the app, and read about its’ use in the section titled “Cache Problems” of the following post: http://blog.somepixels.net/2010/05/how-to-develop-and-debug-flex-on-google-chrome/


That’s all folks. Now get back to work, and happy debugging!



I am still having some issues with caching. Currently, I have found that I most often have to do a hard-refresh in Chrome in order to force it to load the latest build of the .swf. I will be working on finding a solution for this and will update once I have it!

Listening for events in a (Flex) Spark Itemrenderer

I recently ran into an issue where I was creating a custom itemrender in Flashbuilder (Flex) which contained a button. I wanted to listen for the button’s Click event and have an event handler within the itemrenderer respond to it. Sounds simple enough; however it did not work.. AT ALL! After a bit of fumbling around, and a whooooole lot of Googling, I found the problem AND (more importantly) the solution!

What was happening was this: When the button inside of my itemrenderer was clicked, the itemrenderer itself was receiving the click event first, and after notifying the parent list that it had been clicked, some updating took place in the list and all further events were killed (including my button’s click event). I’m sure there are way more technical ways to explain exactly what was occurring; however, I’m lazy, and I have a rather simple fix which works just fine for my purposes, so I’ll spare you the tech jargon and smart talk for now..

Instead of listening for the buttons MouseEvent.CLICK event, I instead listen for MouseEvent.MouseDown. That’s it (told you it was simple). Apparently, the MouseDown event is triggered before the click event (which actually makes quite a bit of sense), and as such, you are able to capture it before the itemrenderer swoops in and steals all the glory (and the events)!

It’s important to note, in the MouseDown event handler inside of your itemrenderer, you MUST call event.stopImmediatePropogation() on the event that gets passed into the handler method. Failing to do so will allow the event to bubble up the chain and once again give the itemrenderer a chance to steal the show. Calling event.stopImmediatePropogation() will stop the event dead in its’ tracks, and give you a chance to apply any logic you might have in your event handler (I’m assuming there is actually a reason you want to capture the event, other than making it your bitch..).