Last week I got my first PocketPC for some development work and ran into some issues that I havent seen mentioned. The PocketPC is a pretty powerful little machine, but what I didnt realize at the beginning was that Pocket Internet Explorer and most browsers for other pdas, and slimmed down devices do not support any JavaScript.
This may not seem like a big issue, but if you visit any of your projects that were working before applying a workaround, you will probably find that the project does not anymore. It really depends on what kind of work-around you implemented. The most widely suggested work around seems to be a JavaScript re-write of the object/embed tag. Which works great, but as you probably guessed it completely fails under Pocket Internet Explorer and will fail under other slimmed down browsers/devices. So what is the best work around?
I would recommend a combination of server-side and JavaScript. On the server-side you would check to make sure that the user is a desktop user using the value return by user agent propert, and if so present them with the JavaScript workaround (You can even isolate IE users if you wanted). If they are not a desktop user, then present them with a static version.
Hope someone finds this information useful. This should be good workaround until Microsoft ends up changing Pocket Internet Explorer 
Maybe I’ll provide full code in a future entry.
Update: Thank to Chris Brandt for pointing out that Pocket IE does support some JavaScript. From my testing the Eolas workaround I had implemented was failing. I will have to track down the exact reason specific to Pocket IE. I would still reccomend the same workaround though as there are bound to be more browsers out there with no JavaScript support.
We purchased a copy of Windows-Eyes from GW Micro to see exactly how well some of our government sites worked with a screen reader.
So we received the software in the mail with a CD and approximately 150 page manual. Turned out this nice accessibility software has a little accessibility issue of it’s own. All 150 pages of the manual were blank. No text. Just lots of little bumps on all the pages.
Anyone read braille?
I ran into some odd problems with our custom components today. I had a set of components and when I included one component and used it everything was fine but when I included a second related component the first stopped working. Similar things happenned if I had the SWCs marked as export in first frame, which is set to on by default when you drag in a SWC from the component panel. With everything turned on some didn’t work, but with only some turned on they did.
With a little help from ASV Chafic was able to identify the problem as being related to extra symbols in the component SWFs (the ones inside the SWCs). Some components had symbols in there that they didn’t use. It turned out this was because in the original source FLA from which I created the SWCs, some random symbols had Export in First Frame checked (which is default when you set something to Export for ActionScript).
With this checked the symbols were included in the SWF even though they weren’t used by the component. Then when another component was used that did need these symbols, they weren’t imported properly.
So, to summarize this long story in one short sentence: Make sure nothing has “Export in First Frame” checked when creating components in Flash MX 2004.
The documentation says the “import” statement in Flash is just a convenience for programmers so we don’t have to specify a fully-qualified class name in our code repeatedly. The “import” statement isn’t supposed to have any real effect on the generated code. It’s supposed to be optional.
Turns out when developing components, “import” is required!
Continue reading ‘“import” is required for component meta-data’
Recently I started playing with Unity, a great XML Socket server product. One of Unitys cool features is it provides you with a bunch of AS2 classes that you can use to build pretty complex application. These classes are provided as a SWC that you include in your flas library.
When I sat down initially to write some code, I didnt get any code hinting in my favorite editor PrimalScript since the classes were distributed in an SWC. SWCs are just zip files which contain a bunch of files that support the component. The majority of the SWCs contents are .asi files which provide interfaces and class information to the compiler for type checking. They are very similar to regular classes except they dont include any of the implementation, only the interface of each class.
PrimalScript includes support for ASI files so, with little effort, you can get full code hinting for SWCs.
Continue reading ‘Code Hinting for SWCs in PrimalScript (Unity Client Classes Example)’
I needed to export a bunch of components from a source FLA several times for testing. Doing this manually got tedious very quickly, so, I created a small JSFL script to loop through the library and export all components.
var rootDir = "file:///C|/Documents and Settings/Sam/" +
"Local Settings/Application Data/Macromedia/" +
"Flash MX 2004/en/Configuration/Components/" +
"B-Line Charting Components 3.0/";
var items = fl.getDocumentDOM().library.items;
var item;
var j=0;
for (var i=0; i
Just change the root dir and put in your command folder.
We’re working on a documentation generator for ActionScript 2 that parses code commented with the JavaDoc style syntax to create HTML help, Flash help, or any other type of documentation. Here’s a sneak peak at the output and feature list…
Continue reading ‘Sneak Peak: BLDocs documents AS2 code’
