Last week I got my first PocketPC for some development work and ran into some issues that I havenÂ’t seen mentioned. The PocketPC is a pretty powerful little machine, but what I didnÂ’t realize at the beginning was that Pocket Internet Explorer and most browsers for other pdaÂ’s, 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.

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 →

Recently I started playing with Unity, a great XML Socket server product. One of UnityÂ’s 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 flaÂ’s library.

When I sat down initially to write some code, I didnÂ’t get any code hinting in my favorite editor PrimalScript since the classes were distributed in an SWC. SWCÂ’s are just zip files which contain a bunch of files that support the component. The majority of the SWCÂ’s 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 donÂ’t 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 SWCÂ’s.
Continue reading →