Friday, January 28, 2005

Why the framework must change and why it probably wont

No not another rant against AS2 components, anyway seeing as we produce a competing set of components ourselves a rant from me wouldn't be that credible, but instead I hope here is some reasonable arguments for why the framework really needs to be overhauled.

Many have ranted about the "bloat" of MM's AS2 components and the evils of mixins, sure I have even done that myself, but here is why really these complaints miss the point. If that was all that was wrong then we and others would have jumped in with new framework components that were lighter and mixin free but you dont see them, you dont see many components that extend the framework either. Instead what you see is people completely doing away with the framework. Why?

Now a lot of these replacement components tout being lighweight alternatives to the framework but as saw someone comment ona maillist recently its not hard to produce lighweight components, the real question is not are they lighter but what features did they leave out. Complain as you might about the MM set but they are full featured and they do contain all the extra features that a components need to be used in regular applications, forms, events, tab/focus control, and data binding. Practically all the other components I have seen tend to leave out some functionality or other in order to make them lighweight. I dont believe that this is the correct approach and I think it makes claims about being lighweight alternatives somewhat dubious.

To be honest as a component developer I dont think I should have to provide these core functionalities I think they should be part of the basic enviroment.
I would drop our own implementations in a heartbeat if MM provided a way for me to use there FocusManager or DepthManager but here lies the heart of the problem.

You see I believe MM wear two hats when it comes to Flash one as developer of the FLash VM and core classes what I regard as the "platform" and the other as producer of a set of components. In FMX2004 though these roles have been blured to such a degree I seriously doubt it can be fixed. The framework is a mix of patches and extensions to the core VM and base classes and classses for component development with the two are interlinked in such a way that you cant have one without the other.

Two examples to show the point.
MM realise that Focus Management is broken in the player but instead of fixing the player they wrote the fixes in actionscript, I dont believe that was a good idea but none the less that isn't really critical. However their fix makes use of UIObject, the core of the component framework, and whats more actually in its code to build a tab list it checks to see whether a control is a UIElement or not.

So you cant use the FocusManger with your own components unless you are happy to have the whole framework dragged in and you also need to be subclass of UIObject in order to take full advantege.

You either have the framework or you dont have the VM fix simple as that.

It need not be like this even if MM needed to be able to "tag" certian clips as being "components" they could have used an Interface, they introduced these in FMX2004 and then didnt use them. They could have created an IComponent interface and then required all component to implement that interface. I could then create compatible compoents that weren't derived from the framework.
I mean why should core functionality fixes onlybe available to ther own components

The framework also make regular use of mixins to alter prototypes of intrinsice objects then calls them blindly.

Give you an example of how bad this can be.

I had a class bound to a clip it made no use of the framework and just extended from my own base class. I was puzzled as to why when I dropped an MM TextInput control onto it the TextInput control "lost" its styling. I tracked this down to UIObject making a call to _parent.getStyle and in my class I had a private method getStyle. This is very bad MM component made no attempt to check whether it was calling another UIObject its just assumed that since it had "fixed" all movieclips prottyppes it was safe to do it. Thats bad architecture not only did it screw up their component it screwed up mine as well. In our own components we dont later prototypes and we have a "parent" property that we set to the next object in hierarchy above us thatis part of our base class so we only make calls to our owns components.

These things need to be changed separate core VM fixes form the component framework, use Interface as tags not insisiting on deriving from a class.

Make this an open platform and people willbe able to extend and improve it and in so doing it will increas the interest and use instead of currently where there is practically only a choice of either using MMCompoents or not using flash.

Why the framework must change and why it probably wont

No not another rant against AS2 components, anyway seeing as we produce a competing set of components ourselves a rant from me wouldn't be that credible, but instead I hope here is some reasonable arguments for why the framework really needs to be overhauled.

Many have ranted about the "bloat" of MM's AS2 components and the evils of mixins, sure I have even done that myself, but here is why really these complaints miss the point. If that was all that was wrong then we and others would have jumped in with new framework components that were lighter and mixin free but you dont see them, you dont see many components that extend the framework either. Instead what you see is people completely doing away with the framework. Why?

Now a lot of these replacement components tout being lighweight alternatives to the framework but as saw someone comment ona maillist recently its not hard to produce lighweight components, the real question is not are they lighter but what features did they leave out. Complain as you might about the MM set but they are full featured and they do contain all the extra features that a components need to be used in regular applications, forms, events, tab/focus control, and data binding. Practically all the other components I have seen tend to leave out some functionality or other in order to make them lighweight. I dont believe that this is the correct approach and I think it makes claims about being lighweight alternatives somewhat dubious.

To be honest as a component developer I dont think I should have to provide these core functionalities I think they should be part of the basic enviroment.
I would drop our own implementations in a heartbeat if MM provided a way for me to use there FocusManager or DepthManager but here lies the heart of the problem.

You see I believe MM wear two hats when it comes to Flash one as developer of the FLash VM and core classes and the other as producer of a set of components. InFMX2004 though these roles have been blured indeed I believe the architecture is so poorly thought our that these roles are now so inextriciably interlinked that I doubt it can be fixed. The framework is a mix of patches and extensions to the core VM and base classes and classses for component development but the two are interlinked in such a way that you cant have one without the other.

Two examples to show the point.
MM realise that Focus Management is broken inthe player but instead of fixing the player they wrote the fixes in actionscript, I dont believe that was a good idea but none the less that isn't really critical by itslef. However there fix makes use of UIObject, the core of the component framework, and whats more actually in its code to build a tab list it checks to see whether a control is a UIElement or not.

So you cant use the FocusManger with your own components unless you are happy to have the whole framework dragged in and you also need to be subclass of UIObject in order to take full advantege.

You either have the framework or you dont have the VM fix simple as that.

It shouldnt be like this even if MM needed to be bale to "tag" certian clips as being "components" they could have used an Interfae, they introudced hese in FMX2004 and then didnt use them. They could have created a IComponent interface and then required all compoent to implement that interface so I could create compatible compoents that werent derived from the framework.
I mean why should core functionality fixes onlybe availe to ther own components

The framework also make regular use of mixins to alter prototypes of intrinsice objects then calls them blindly.

Giv eyou an example of how bad this can be.

I had a class bound to a clip it made no use of the framework and just extended from my own base class. I was puzzled as to why when I dropped an MM TextInput control onto it the TextInput control "lost" its styling. I tracked this down to UIObject making a call to _parent.getStyle and in my class I had a private method getStyle. This is very bad MM component made no attempt to check whether it was calling another UIObject its just assumed that since it had "fixed" all movieclips prottyppes it was safe to do it. Thats bad architecture not only did it screw up their component it screwed up mine as well. In our own components we dont later prototypes and we have a "parent" property that we set to the next object in hierarchy above us thatis part of our base class so we only make calls to our owns components.

These things need to be changed separate core VM fixes form the component framework, use Interface as tags not insisiting on deriving from a class.

Make this an open platform and people willbe able to extend and improve it and in so doing it will increas the interest and use instead of currently where there is practically only a choice of either using MMCompoents or not using flash.

Thursday, January 27, 2005

XPCharting 1.1 Released

We have just released XPCharting 1.1

In this release we have added several new chart types, many new customisation features and made it even easier to use.

Now supports rotated text display for chart axis, highlight particular points of interest with charts band and lines, pick from a selection of image borders/frames to display your chart in or just roll your own. Powerful formatting options allow you to create the chart just the way you want.

XPCharting is easy to use and simple to integrate into your flash application, the only charting package built with RIA's specifically in mind. Includes a CSVConnector and DataProvider. All charts render incredibly quickly and are ideal for real time data display.

If you want to know more then checkout http://www.epresenterplus.com/charting.shtml for more info and to look over our gallery or UserGuide.

Saturday, January 22, 2005

Managing your AS2 class files with VSS

One of the cool features of MX2004 was VSS integration but it turned out this was only as part of managing a project.

At first glance this seemed limiting, apart from needing a "project" in the first place, before you could activate VSS in a particular project you needed to create a "site" and then select that "site" for use by the project. A site seemed like it was assuming your project was for developing a flash web site particularly as it will automatically read sites you may have defined in Dreamweaver for your web site maintenance. Cool if that's what you are doing but not so useful if your not. Indeed I didn't really find documentation about using it in any other way so I quickly forgot about it.

As a component developer I wanted a way to manage all my AS2 class files which amount to several hundred files. There was no "site" as such, nor really a "project". It didn�t really seem that the whole project thing fitted with what I wanted.

At first I thought this might become a wish list item for Flash8 but after poking around I found a way to make it work. Of course if you have done this already it will just be "obvious" but if you haven't got that far your might struggle as I did and give up. Don't know about you but if something is important I will keep searching till I find a way but if its not so important I just give up very quickly if it is not made obvious to me as I have better things to do with my time, so here is how I got it to work for me.

First I am assuming you already have VSS installed on your system and you have a user account setup. I am using VSS6 by the way.

In the Flash IDE I created a project which I called "XPSource" though you can name it anything you like. At the same time I also created a project in VSS called "XPSource" under "$/".

The next task is to add all you class source files to the flash project.
My class files are under the "xp" branch located at C:\Documents and Settings\XXXXXX\Local Settings\Application Data\Macromedia\Flash MX 2004\en\Configuration\Classes. The structure there mimics the classpath and package structure i.e. there is a folder "xp/util" which contains a file MathUtil.as.
Unfortunately there isn't a way to adds all files recursively to a project so this has to be done folder by folder. So first I recreated the folder structure i.e. in the IDE with my newly created project open I added a folder "xp" then double clicked it to open it and then again added a folder called "util". Now with that created I double clicked "util" and then selected "Add File(s)". This pops open a file dialog, navigate to the util folder and select all the files (click the first file, hold down the shift key and select the last file). Click the Open button and all the files will be added to the project "xp/util" folder. Repeat this for all folders and files in your class hierarchy.
When that is complete your project will look the same as a it does in Explorer if you looked at the root of Classes.

The next step is to create a "site" so we can activate VSS.
From the main menu choose Files/Edit Sites. Then click New on the Edit Sites dialog. This pops up the SiteDefinition dialog. Complete the fields as follows;
SiteName: "XPSource"
LocalRoot "C:\Documents and Settings\XXXXXX\Local Settings\Application Data\Macromedia\Flash MX 2004\en\Configuration\Classes\"
Email: "me@somewhere.com"
Checkout Name: "MyVSSUserName"
Below the last field is the Connection ComboBox, click it and select SourceSafe Database.
There is then a "Settings" button below the ComboBox. Click it and open the Open SourceSafe DB dialog. Again, complete the fields as below;
DatabasePath: The path to your srcsafe.ini file for example "D:\Program Files\Microsoft Visual Studio\Common\VSS\srcsafe.ini"
Project: "$/XPSource"
Username: "MyVSSUsername"
Pasword: "MyVSSPassword"

Then click Ok and close the dialog, then Ok again to close the SiteDefinition Dialog, and finally click Done to close the edit sites dialog.

Next go back to your project panel, right click and select "Settings" and in the dialog that opens, under Version Control, open the Site ComboBox and select "XPSource". Click Ok to close the dialog.

Ok now your done and ready to start loading VSS.

Select your top level folder under XPSource i.e. "xp" then right click and select "Check In" complete the usual check in dialogs and all your files are checked into VSS and marked as read only in your local folder.

That�s it basically, make sure your project is saved, and now anytime you want to check out a file open the XPSource project find the file double click it and you will prompted as to whether you want to just view it or check it out.

Once you have got this far its quite easy to customize this to you own needs. For example, create a new project that works on a subset of the class files, and in VSS create a new project and set it to share the files with your XPSource project. If your familiar with VSS this should be straight forward.

Rob

Thursday, January 6, 2005

removeMovieClip and onUnload conflict

Happy New Year!,
Don't know about you but this year it's felt really hard to get back into the swing of things again after christmas.

Anyway down to business this is a problem that I realize has been around for a while and I couldn't quite get to the bottom of it so I just worked around it but finally I decided to squash it once and for all.

The Problem:
There are a number of places where we might want to delete and recreate a series of masked clips through actionscript basically just like a reset, rebuild the clips same instance name, same initial properties.

When we did this we noted that after creating and then masking them for the second time the setMask call failed and our "mask" was visible on screen.
We looked for reason why the setMask call didn't work but couldn't see what was wrong. Anyway we were looking in the wrong place the issue was not the setMask call it was the removeMovieClip call beforehand.

Now when we watched in the debugger the clips disappeared as they should but we found that we could still find the clips via trace. Admittedly all the properties had gone and any child clips had disappeared but strangely some method worked and we found that getDepth() returned a negative value equal to 32769 + the original depth. Well the docs say that's not a legal depth. Then when we created the new clips reusing the instanceId they were created but the depth was still this illegal large negative value. I guess in that state it was not surprising that setMask wasn't going to work.

We then tried to figure out what caused the depth to change when we simply called removeMovieClip. Well after working our way through the code we eventually saw it was a simple onUnload handler that was the root of all this evil. The handler wasn't doing anything it was just "there", but if it was removed the clips went away nicely if it was set (even to null) then the clips wouldn't get properly removed.

Now the docs say the onUnload handler is called on the frame after the clip is unloaded (never did understand why) so I guess its hanging around so it can invoke the handler but the docs also say removeMovieClip wipes out your handlers and its true onUnload never gets invoked when you call removeMovieClip. However even though its not invoked it still prevents the clip from being removed immediately.

Now given the above explanation we did wonder what would happen if we gave the clips a frame to get themselves sorted out before recreating them again. It did help at leas the depth straightened itself out but we still couldn't get the setMask call to work.

In any event a frames pause was not a workable solution in this case as we need to delete and create in the same call.

So we renamed the onUnload function onDestroy then provided a mechanism for that to be invoked by removeMovieClip.

Its not a big deal but its a small gotcha.

On reflection though I think we really should have an onRemove or on Destroy event for MovieClips that are "removed" so that we can gracefully handle tidying up before a clip is killed whether it is by unloading or removing.