With all the interest in mobile development there come the issue of dynamically resizing UI elements based on the pixel density of the screen. For example, if a button is set to be 100 pixels wide, it will appear at different physical widths depending on the device being used. This is because your desktop monitor may have a pixel density (DPI or PPI) of 86dpi but you mobile phone may have a pixel density of 326dpi (as is the case with the retina display on the iPhone 4). This may meant that you nicely designed UI is unusable, with items being too small to click on with your finger!
I was recently working a project which used both TLFTextFields and FlashVars, and I came across a rather nasty bug. Basically, if you have at least one TLFTextField in your project access to FlashVars will stop working. So I posted the bug on the Adobe Forums – Text Layout Framework section and thankfully Alan Stearns got back to me very quickly with the answer.
The problem is down to the Text Layout Framework Runtime Shared Library preloading.
Recently I stumbled across this post by Ryan Creighton at Untold Entertainment from back in October 2008 titled ‘stop(); Action Ignored on Nested Movieclip‘. It basically demonstrates how (in AS3) a child movieclip does not stop on the first frame (even though you have put a stop(); action on it) when it’s parent/container is dynamically attached to the stage.
To me this does seem like a bug. Unless I am missing some subtle difference in this area between AS2 and AS3 that I am missing. If so, please can someone explain it to me?
I’ve knocked up a couple of examples to demonstrate …
Firstly, here is the AS2 version that attaches the container movieclip to the stage using the old attachMovie method. Sure enough, the child movieclip does as it is told and stays on frame 1.
And here is the AS3 version that instantiates the Contaner class and adds it to the display list using addChild. As you can see the child movieclip ignores the stop() command on frame 1 and goes to frame 2 instead. Why?
Have just built a video player that allowed the user to switch to FullScreen mode and toggle the play/pause state using the SPACE key on their keyboard. However, I found that everytime the Flash movie entered FullScreen mode the playing video would pause and visa-versa.
I then discovered that the Flash Player was dispatching a KEY_DOWN event when entering FullScreen mode. More specifically, the keyCode == 32, which corresponds to the spacebar on your keyboard.
The workaround is to temporarily remove the KEY_DOWN event listener, and add it again with a slight delay once the FULL_SCREEN event has been dispatched. You could create the delay by using either a Timer, an ENTER_FRAME event or the setTimeout method. In TyZ’s example he used an ENTER_FRAME event, in my example below I use an instance of the Timer class.
Initially it looks very nice, but after a short play with the sliders my Firefox browser crashed and displayed a weird error message. It was not an error message I have ever seen before.
Windows XP, Firefox 2.0.0.13 Error Message: Illegal Operation in Plugin
I restarted Firefox and tried it again, but the same thing happened. It is 100% repeatable.
So then I thought I’d give it give it a whirl in Internet Explorer (IE 7.0.5730.11) and, bingo, another new error message.
Windows XP, IE Error Message
The version of the Flash Player I have installed is WIN 9,0,115,0 (Debug player).
I can’t believe this is STILL a bug with the Flash Player/Firefox/UK keyboards. This has been an issue since 2005!
Surely it should have been fixed by someone by now. If you are not familiar with it, basically, when you embed a Flash movie in to an HTML page you have the option of setting the background of the Flash movie to ‘transparent’ so that the HTML page underneath can be seen through. This is useful for various reasons, for example, if you wanted the Flash movie to have rounded corners (not square ones) and you wanted the background colour of the HTML page to show through in those corners. This is achieved by setting the ‘wmode’ parameter to ‘transparent’. More information about this setting can be found on the following Adobe TechNote.
However, when this setting is applied, browsed using Firefox using a UK keyboard, the @ symbols in input textfields get converted to ” (quote marks). Basically, the Flash Player thinks you are using a US keyboard.
There are two reasons why I am blogging about this now. The first is that it came up the other week on a project a colegue was working on. They had noticed that it was happening, but had got so used to pressing Ctrl+2 to get the @ symbol, that they had forgotten that this was not normal, and would confuse the user. The second reason I am mentioning it is that even Adobe’s own PhotoShop Express (just released) suffers from the same problem. You can see it in action on the ‘Join Now’ screen and the ‘Sign In’ screen. The problem is usually most evident on form fields where you are required to enter your email address (which is quite often). See screengrab below …
People have been blogging about this issue for the past three years. Here are a few examples …
The workaround in AS2 was to create a Key listener on a textfield that checks the CharCode to see if it is 34 and dynamically changes it to an @ symbol.
I have updated the workaround to work with AS3.0 using a CHANGE event listener on the textfield.
function textChanged(evt:Event):void{ var typed:String = evt.target.text.slice(evt.target.text.length-1, evt.target.text.length); if(typed == "\""){
evt.target.text = evt.target.text.slice(0, evt.target.text.length-1)+"@"; } }
To be honest, I’m not sure if this is a problem with the Flash Player or Firefox. But I do know that it is about time Adobe and Mozilla got together and sorted it out.
Last week I one of the designers I was working with came across a bug in Flash CS3, well I presume it is a bug. Basically they were trying to do a shape tween on a line, bending from one place to another on the screen. Nothing strange there. But the line is question was dotted. When the shape tween was applied the line lost all dotted appearance and reverted back to a normal stroke, and then became dotted again on the last keyframe. The same thing happened when the line was dashed.
Obviously I would have expected it to remain dotted throughout the duration of the shape tween. See below.
We then tried converting the line to a fill (Modify > Shape > Convert lines to fills), which nearly worked, but the tweening got confused and random dots started swapping places, plus the filesize got bigger.
Surely this is a bug. I have reported it to Adobe using their Bug Report Form.
January 6th, 2011 by 
Adrian 
2 Comments »
