FlashXP

I came across a very subtle gotcha this week.

I was creating an MXI to build an MXP for installing some AS2 components and source.

After building the MXP and then installing it we ran into some problems in Flash with previously OK code not compiling. The compiler claimed it couldn't load the class file. We checked back and we had the source file in the staging area and we had it in the MXI and the MXP built without any warnings.

Puzzling!

We checked again and noticed that there was a small typo in the MXI a class file was spelt "someClassFile" but should have been "SomeClassFile".

As far as the MXI was called when running on Windows as it built the MXP "SomeClassFile" and "someClassFile" are the same thing so the build was sucessfull.

When it came to installation the MXP file now expanded the class file and copied to the drive and followed the MXI instructions and wrote the file as "someClassFile". As this was a Windows installation the file "someClassFile" overwrote the old file "SomeClassFile".

Now back in the Flash IDE when we ran the program using AS2. The compiler under AS2 it seems is case sensitive even as far as just finding a file on the drive so "SomeClassFile" is different from "someClassFile" and therefore it couldn't find the file.

OOOpppssss!

Okay problem solved!

It would be nice I guess at some point if the Extension Manager became case sensitive as well to help catch slips like this but in the mean time ....be warned.... watchout for case sensitivity in file names when creating your MXI

Posted by Rob at 12:26 AM | Permalink | Comments (0)

I thought it might be worthwhile to occasionally highlight some of the less obvious features of XPComponents so were turning the spotlight on PropertyTriggers.

Basically Property Triggers enables additional property values to be applied to the target component based on a change in the value of a property on that component.

Thats a long winded way of saying when a property on a component changes it can trigger a series of related changes.

The simplest way to introduce PropertyTriggeers is to look at an example. Lets look at the most obvious use of a PropertyTrigger, probably the first thing you might try to implement yourself, a mouse rollover.

When the mouse rolls over a component we want to change the text font color to red and when it rolls out we want it to change to blue

In XPComponents whether the mouse is over a component or not is indicated by the isMouseOver property.

So we will create two property triggers the first to handle isMouseOver==true and the second for isMouseOver==false.

We can add a property trigger to a component by using its addPropertyTrigger (we do really try to make life simple for you in XPComponents).

addPropertyTrigger("isMouseOver", true, {fontColor:Colors.Red})
addPropertyTrigger("isMouseOver", false, {fontColor:Colors.Blue})

So we called the method passing first the name of the property this trigger will be associated with, secondly we passed the value of the property that will cause this trigger to fire, and lastly we passed a property bag, a set of name/value pairs of properties that will be set as a result of this trigger firing

In this case we were interested in changing the fontColor property to red and blue respectivley.

So thats it your done you have a rollover coded, or should I say you have a rollover but without any real coding.

PropertyTriggers can also be set in a class style object to give you the ability to just apply a style globally to a set of components.

So here is an actual live example.





We have a movie with 3 standard XPLabel components.

One is just a plain label, one has an added icon and the final "smart" one adds a mouse rollover Property Trigger.



This movie contains just 3 lines of code.

smart.enableMouseEvents=true;

smart.addPropertyTrigger("isMouseOver",true,{iconIndex:"open",fontColor:0x0000FF});

smart.addPropertyTrigger("isMouseOver",false,{iconIndex:"close",fontColor:0xFF0000});

There is a some more detail here http://www.epresenterplus.com/flash/docs/propertyTriggers.shtml especially regarding advanced triggers

Posted by Rob at 01:02 PM | Permalink | Comments (0)

I have been toying around with collection properties in FMX2004.

They are quite cool and potentially quite useful for component builders.

Basically a collection property is little more than an Array where the items are your own custom class but Flash IDE gives you a nice little property editor to allow users to edit itemsdirectly from the Inspector.

So for example you could have a "Columns" property with each item being of your own custom Column class with say fields for Title, Field etc

You create your Column class and with just a bit of metadata you have got a built in property editor for free.

It has a lot of potential uses that I can think of.

Unfortunately there are a few issues with the current implementation, mostly minor cosmetic issues but one is basically a "deal breaker" and leaves me really unable to happily use it.

Ok very minor issues first, the data is stored in the swf as a compact array of objects and at run time as your component is constructed Flash unpacks the array and turns it back into a Collection for you.
Basic steps are, create the Collection, then iterate over the array, and for each item create a new CollectionItem class and populate it, when its all complete set the property on the component. Problem is that that code exists for every instance of your component. The code is not class based neither is it static its just there taking bytes of footprint for every instance of you component in the movie.
Now its not much, maybe 30-50 bytes for each collection property per instance but if you had 100 instances of a component (say a custom Label or something common) its starts to add up.

This is really made a bit more of an issue because that code is generated whether the Collection has any data in it or not. So if the user didn't enter any data then I will still get set as a Collection with no items in it. Actually this also brings up another issue that Flash appears to generate code for setting all properties during construction even when the value is still the original default value (i.e. the user never entered anything).

I dont know quite how this can be fixed but it could be more effecient, even doing nothing and dumping the raw data back into your property and forcing you to sort it out would be more effecient than the present solution. As I said not really a big deal but still its there.

Next minor point is that in the PropertyInspector Collection Properties seem to ignore the "category" attribute of the metadata. The category attribute allows you to group related properties togther in the PropertyInspector to make it easier for the user. With collections they all appear at the top of the inspector by themselves rather than being able to collect them together with other related properties.

The real big issue however is this.
When you have entered your data into you property and closed the editor the PropertyInspector displays your data as text like [{column0:345},{column1:123}].
At first that seems very cool, but eventually as you enter more data you realize it is actually displaying all your data and resizing the PropertyInspectors width to fit it all on one very long line. You very quickly end up with a PropertyInspector that has a massive width.

Where this becomes a total killer is that when you now click any another property say with a enumeration (i.e. uses a combobox) the Inspector auto scrolls over to the right to bring the dropdown button into view, unfortunately all the labels and values have now scrolled of the screen to the left and you are faced with basically an empty screen without any clue to which property you are now on. Its a nightmare for a user of your component.

Basically at this point you cant realistically edit any other properties in the Property Inspector if you have more than a couple of items in your collection property.

Thats unfortunate as otherwise its quite a neat solution to a few problems.

Anyway next thing I have to take a look at is writing a custom property editor, now does anyone know where there is some sample code to get me started?

Posted by Rob at 06:08 PM | Permalink | Comments (2)

Ok first thanks for those guys that pointed me to the source code for the new AS2 Remoting classes now I can compile my application!

So step one - I did the "minimum" change, basically nothing, just switched to the new NetServices to see whether it would all still work. I had previously been using an AS2 version of remoting that I had downloaded from the web I think I am a bit hazy about this, there seem to have been several versions floating around. Anyway I just changed one import statement and then hit run application .... and nothing happens. So that really is my own stupid fault, I had even read the "gotcha" and still I forgot to add those new libraries lol. So ok open up the library drag in the Remoting classes hit run again and it all works fine!

Now sit back have a cup of coffee and feel pleased with myself, it all works with the new classes. After a couple of swigs of coffee I glance out of curiosity at the file size of the swf, the old had been 90k, the new one 99k! That's a 10% increase in footprint for nothing, no extra functionality, nothing at all!

Now maybe I am the only one bothered by download footprint if so I am talking to myself here but to me it matters a lot. That is a hefty increase. So I started thinking about why this had happened.

There are two main things that come to mind.

Firstly the code itself just in mx.remoting alone the source code seems to have gone from 20k to 80k+ and then there is additional code in mx.rpc and mx.util .

Secondly really starts with saying that maybe point 1 shouldn't matter that much after all if I don't use a class it wont get compiled in right and it looks like the Recordset class is one of the main culprits for having blown up in size and I don't use it but the thing is that now we include the Remoting classes via a library not by import classes, the result of that I believe is that everything gets into your swf whether you use it or not.

So end result your stuck with a 9k increase in footprint if you move from the old classes to the new classes.

Well thats not good enough, there must be a solution he says!

I then had a bright idea, maybe I could delete the library and just import all the classes I needed. That didn't work, for some reason Flash point blank refuses to import those classes.

The next idea was to rename them under my own package tree so xp.remoting instead of mx.remoting, that got them imported but my application still failed maybe because the compiler was complaining about odd things.

So then I thought about the old remoting files and I got to thinking about using them but to in order to leave the option open to using the new Remoting I would move the old ones under my own package also I would only use the minimum I needed for my application.

Well I tried that and it worked. In fact my application went down from 91k to 88k.

What was the minimum I needed?
NetServices
NetServiceProxy
NetServiceProxyResponder
NetConnectionAS2

They all exist now under xp.remoting as one of my own packages, a total of 4k of source files. That's all!

So now I have a choice -3k or +9k.... I need a lot of convincing that there is something worth +12k in the new classes!

Now my moan is not so much about the new classes, I can understand sometimes you add functionality and it will add to the foot print, I would be willing to "tolerate" a tiny footprint increase, but given the environment that most people are working in where download size does matter can't we be a bit smarter than to just include everything in one shot. Especially where it wasnt like that before and there doesn't seem to be an obvious reason as to why the change in style. Going beyond this single instance it does really seem that bloat is a major issue and I feel that it is possible to be be smarter than this.

Posted by Rob at 05:17 PM | Permalink | Comments (2)

Maybe its me!

Using WebServices or Remoting (with the new AS2 compatible classes) seems to be stupidly awkward if you want to use AS2 classes.

Just taking examples from the help file to get you started the first thing you need to do is import the Service class i.e.
import mx.remoting.Service;

Well that all well and good if I am still writing my code in AS1 style and embedding it in the MovieClip into which I dropped the Remoting or WebService libraries but if I am an AS2 convert and I am using custom classes there seems to be a problem.

If I try to import the remoting classes into an AS2 class file the compiler complains that they dont exist!

Well I can see its point, MM for there own reasons decided to distribute these classes in a compiled library which I have to drag into my movie if I want to use them but they didnt supply any source files for the compiler to do its checking in class files.

I am missing something here, did these files not install properly or is there some configuration that I need to change or what?

If I am right and these files dont exist and you can't use WebServices or Remoting in class files then why not?

As far as I can see MM could have distributed source stub files with classes marked as Intrinsic and we could have happily built classes and they could still have protected there code. In fact I was half toying with the idea of doing just that myself so i can keep the compiler happy.

All that aside WebServices and Remoting with Flash is really cool. Hopefully we can get some example up in a few days to start to show just how well this all fits in with the XPComponent framework.

Posted by Rob at 11:13 PM | Permalink | Comments (3)

This has got me thinking today!

A feature I want, but is it there already and I just don't know enough?

I was thinking it would be nice to be able to have compound properties in the PropertyInspector. What I mean by this is a property that is actually an object with its own properties.

For example a property called CD which is an object with properties Artist and Title.

Daft example but bear with me.

You see the PropertyInspector actually can handle some complex properties already. You can define a property as a Collection i.e. basically an Array but with a custom class for the CollectionItem.

To quote from the Flash help file....
You code the properties for a collection item in a separate ActionScript class, which you define as follows:

Define the class such that it does not extend UIObject or UIComponent.
Define all properties using the Inspectable tag.
Define all properties as variables. Do not write get and set (getter/setter) methods.
The following is a simple example of a collection item class file called CompactDisc.as.

class CompactDisc{
[Inspectable(type="String", defaultValue="Title")]
var title:String;
[Inspectable(type="String", defaultValue="Artist")]
var artist:String;
}

There you see! If my property was a Collection or an Array of CD's then I could have what I want now.

But I want less than that, I just want one single item not an array of them.

Hmmmm so that has to be asking less of MM not more, if they went to the trouble of making it handle an Array of Objects wouldn't they first have thought of it handling a single Object?

...... is there a way to do it ...

I haven't seen any documentation or examples on it so I suspect not.

Maybe another item for the wishlist

Posted by Rob at 05:53 PM | Permalink | Comments (0)

Well TGIF ....

There is thread running over on the FlashTeam blog, it has become a sort of IDE wishlist cool...

Anyway I thought i would add my 2cents worth

... but I got rejected ...

apparently my posting contained ***questionable content***

Well here it is in its completley uncensored form and if you are under the age of 45 or of a sensitive nature please view with a parent thank you....

If I could only have two features in the next version of Flash they would be

1) UNINSPECTABLELIST MetaTag. This has caused me so much grief in adding new props only to forget some inherited class had an inspectablelist to exclude some completley unrelated prop and as such it wouldnt reflect my new prop till I found the class and amended its inspectablelist.

2) Store text/xml docs in the library. Would be great to store config/menu xml docs in the Library as a resource that could be retrieved at runtime. Sure you can load from an external url but there are many instances where it would be better to store this in the library... as a twist on this... components could acces info in an xml file say with basic config info that they included in the swc.

3)Not a realistic wish as I am sure this is never going to happen but... I would like to be able to change style info(className) at design time and see the changes reflected immediatley, this would work if only the component could access some central repository of user defined style data in the IDE.

Posted by Rob at 11:38 PM | Permalink | Comments (0)

A while back I remarked about how I was having problems inside the Flash IDE with WSDL downloading.

Basically using the WebServices panel I could never download a WSDL file so even things like the WebServicesConnector wouldn't work as I couldn't select an operation in the Component Inspector.

Actually it was not only the WebServices that wasn't downloading but also I couldn't download Flash Help Updates either.

Well I tried everything to resolve this, I had a lot of helpful comments from people, some even from MM, of course the general view was I must have a firewall or something blocking the download. Nothing worked! So in the end I just gave up and moved on without Flash WebServices sadly...

Well recently and quite by chance I resolved this issue. Yippeee!

One day for an entirely unrelated reason I was trying to really "clean up" my PC and at the last I decided to delete everything in the Temp directory.

What do you know but the next thing when I am using Flash the Help updates and the WebServices work, great!!

Then a few days later it stops working again, oh no!!!!......... but then I recalled that cleaning up the Temp directory seemed to somehow have coincided with fixing the problem. So I exited Flash and deleted the Temp directory contents, restarted Flash and yes again it was Ok.

I have since found that basically whenever the Flash IDE crashes it leaves some files in the Temp directory and for an unknown reason these cause the IDE to be unable to download Help or WSDL files after you restart. Left to its own devices these files NEVER get cleaned up even on subsequent normal exiting of the IDE.

The problem is basically persistently repeatable and reproducible at will. It hasn't gone away even with the latest Flash "patch" I just know now how to resolve it when I want to.

So ... if you are having problems downloading inside the IDE, shut down Flash (make sure it is really shut down), go to Document and Settings\...\LocalSettings\Temp and delete everything you can find.

Posted by Rob at 04:23 PM | Permalink | Comments (0)