Flashcoders down again.....

Dont know whats up with Flashcoders these days.

This is the second time in a week that its been down, and when it goes down it goes down for days on end (2 days already this time).....

What with all the problems with searching the archives after the recent service upgrade, makes you wonder whats up.

I know its a free service so one should try to support not complain but I regard it as an important business resource, its format as a mailing list makes it vastly more valuable than web forum based sites.

So if there is an underlying issue maybe the community as a whole needs to address it before we all lose an important resource.

And just to make it very clear... Thanks! to the guys who do provide FlashCoders, whoever you are, my frustration is only becuase youve made it so good its a pain not have it around..

Property getter/setters in MX2004 and the Component Inspector

Properties in MX2004 highlight how Flash uniquely occupies a space somewhere in between the Windows centric world and the Java centric world.

In Windows style a property is used just like a variable
var x = myComp.myCustomProperty;
myComp.myCustomProperty=x

and are declared using the get/set keywords

function get myCustomProperty():Number{ return __myCustomProperty; }

However in the Java world we use get/set methods
var x = myComp.getMyCustomProperty();
myComp.setMyCustomProperty(x);

and declared like this
function getMyCustomProperty():Number{ return __myCustomProperty; }

So what's the big deal you ask, so Flash just lets you use either style, so isn't that a good thing?

Well, yes if it did in fact let you freely use both styles, but it doesn't!

You see if you want to expose that property in the Component Inspector you can only do that using the implicit get/set style but on the other hand if you want to define your property in an interface you can only do that using the getter/setter methods.

So that's a problem. You can't create a property that works in both the Inspector and an Interface.

So how can we work around it? If you look at the MM Source Code you will find the only answer is to simply code both style of property getter/setters.

At a minimum this is inefficient coding, adds to the bloat of components and is more code to debug.

I hope this will be resolved in the next version of Flash, preferably by making the Java style getter/setters work with the ComponentInspector or by allowing properties in interface definitions.


Whilst talking about the ComponentInspector, I must say this is something that really needs improving a lot in the next version of Flash.

In MX2004 it can be said to be a good first effort but it is still years behind component inspectors common in other products.

Features I would like to see are:
1) Custom Property Editors - Create a property editor using JSFL and assign that editor as a handler for particular properties of a component. Currently you can have a component wizard but that is a poor alternative. Users expect to be able to click a property to edit it not search somewhere else for a wizard.

2) Custom Class properties - The Collection property introduced a custom class property but only in the context of a collection, we need the same thing but for single properties. Currently you can have an "Object" property but this is very limited, has many inherent limitations and only produces a generic object not a typed class. It also needs to allow this class property to be null.

3) More efficient code generation - Currently Flash generates setter code for all exposed variable, it also requires you to set a default value in the metadata. If a property is still at its default value Flash still generates code to "set" its value. Code that commonly duplicates you own component internal code that sets the default value. The IDE should be smart enough to NOT generate code if a property is using its default value. This is particularly an issue as the IDE generates the code per instance whereas your own internal code is per class. If you have many properties at there default value this can result in a sizable proportion of the movie footprint be taken up by unnecessary code. The current approach only works as long as you only expose a few properties in the IDE (as MM do) but then what's the point of the inspector if you are not going to use it.
It becomes a major issue if you say expose 20/30 properties per component and have maybe 100+ component in an application, that�s an awfull lot of "dead" code being injected into you movie.

4) Allow null values - Currently properties MUST have a value, there isn't a way to have a null value. This is particularly relevant to Object type properties where you currently you need a second Boolean property to indicate "nullness".

5) Improve code generation for Collection properties - Collections properties generate a lot of code, that�s particularly an issue as the IDE generates the code even if the collection is empty. Again the IDE code is per instance whereas your own code is per class which makes collection properties currently impracticable for general use limiting them to special cases and only in components that will only have a few instances per application.


I know this probably isn't the most popular improvement and many may not see the reason why we rate it so highly, but what we are looking to do is to enable you to work more efficiently through providing you with components that are both easier to use and more powerful, in other words a strong foundation will enable you to build better applications.

We believe strongly that a good powerful visual editor is the key to making Flash more usuable as a development enviroment rather than just a "nice" add on. Its also why we prefer to see the IDE improve than resort to third party tools.

Components that wont update

This is bugging me, though I must admit it's not a very commmom problem.

I have a particular group of components that simply wont update when recompiled.

I mean I alter the code, recompile sucessfully, but the "new" component contains the old code not the new code.

This particular set of components is slightly unusual in that they have a few lines of code in a frame action, I alter the frame action code, so there can be no question about it having "picked" up an old file, but the final component shows the old code.

The work around is I have to copy the component out into an empty fla, recompile it in the empty fla, and it is then updated and I can then delete the new fla.

I have tried all sort of different "tricks" to get flash to properly compile these components like "save and compact", delete and paste, but nothing works except compiling in a new empty file.

There are very rare occasions where this happens in other components but they tend to be rather random and usually you end up having to scrap the fla and start again but this particular set it is permanently repeatable.

Just wondering have others come across this issue of components that don't properly update when recompiled?

If you have is there any pattern to the problem and how do you work around it?

I need my daily fix of FlashCoders

Oh dear no FlashCoders for 12 hours, think I am starting to have cold sweats.

And just as the argument over variable naming and the non-existent AS3,threads looked like they were about to warm up again for the second day in a row.

Actually what flash mailing list/Forums do you frequent?

For me it's FlashCoders and ActionScript.org.

MM's own forums are just way to slow to access for me so I dont go there at all these days, although I would like to. Most of the others I come across now and again just dont have enough traffic to make it worthwhile.

AS Editor Tip

This isn't original but I thought it was worthwhile mentioning as I stumbled across this tip on some blog recently quite by chance, though I forget where, and it was something I didn't know about, maybe someone else out there is as dumb as me.

Ever needed to indent your code in the editor, can't find the indent button like in DW and don't like to use the code formatter?

Well just select the text block you want and hit Tab! Boy is that so dumb and obvious why did I miss it.

Of course shift-tab gets you unindent as well.

While we are here I might as well say a few things about the editor. I see a LOT of people moan about the editor, how they can't ever imagine using it again and how they use 3party tools like Sepy and Eclipse.
Well let me say I don't mind it at all and I spend a lot more time coding than probably most people do.
I would add that I do all my coding in class files so I never use the Actions Panel and I think maybe that is the difference.
I wouldn't give up using the editor as I really like the code hinting and the syntax checker which I am not sure you can get in the other editors and I mean by that including reminding me that a variable or function is private in another class not just that I am using keywords correctly.
In particular I like the way I that code hinting is not just limited to the MM set of classes but can work with my own classes as well. Not many editors I know of allow that or at least make it so easy.

That's not to say the editor is anywhere up to the level I wish. I think I saw someone say the other day that MM were not aiming at being the world's best editor and that fair enough but I think it's not unreasonable to expect it to be in the ballpark with say Borland's IDE.

Some features I think would cost little and be trivial to add. For example whenever I code I always have DW open, not because I am using any web stuff but simply I find it essential to have its search and replace tool to search over all my source files say for example I am trying to find where a particular method is being used across class files. Why can't Flash at least have an editor with the features of DW?

I also miss some of the old HomeSite (now sort of DW) editor extensibility features, like being able to add blocks of code or create macros for for-loops etc. It might be nice if JSFL could be used in this area as that seems to now be the "user level automation tool".

Well I hope we see some improvements in the IDE in the next release of Flash, this is one are at least where MM are not restricted with backwards compatibility.

Open code, formats, or conversation?

I read JD's post about "Open code, formats, or conversation?"

Wanted to make a reply but got rejected for "Questionable content"... Yeah I know, probably an over enthusiastic filter or it just doesnt like me but anyway, here's what I wanted to say.

Hmm,
Addressing the "community" aspect:
Send a response when people submit a wishlist item or request to join a beta program and dont get accepted.

Make the Devloper site more about delivering what the developer needs than pushing the newest MM feature or product (like flavour of the month with MM is clearly Video so almost every article is about Video). Maybe this is a perception thing but I find MSDN site to be a knowledge source where as the MM Developer site is probably the last place I look if I want information about Flash.

Adressing the open source vs closed source aspect:
I personally dont mind closed source but it needs to be very high in quality, very broad in scope and well documented i.e. I mean it has to be such that dont really want or need to touch it anyway. I would say that I dont feel that this applies at the moment to the AS2 Framework, WebServices, DataBinding and JSFL Wizards, some of which MM has made open source and some of which it hasn't.

That said I also dont really see a benefit that closed source gains a company when there is no real threat of a loss of critical knowledge to a competitor or some misue of the code and I dont understand the logic behind MM's choice of what to open source and what not to (though I dont mean this is an attribute unique to MM by any means lol).

UpdateAfterEvent

Easiest way to get this over is to imagine I am creating a custom cursor in Flash.

I have a class associated with a clip, in the class which extends MovieCliip have an onMouseMove event handler which updates the position of my clip and then call UpdateAfterEvent to make sure everything updates smoothly.

No problem it all works wonderfully!

Now a slight change in construction. Instead of associating my clip with the class I will make the class standalone, a plain old class object but I will pass it a reference to the clip it has to update.
Ok to make it work I need to make the class a MouseListener in order for the onMouseMove handler to get called.

Again no problem it all works!

Well... not exactly....

You see clearly the clips position is not being updated smoothly, there is a clear lag and its very jerky. Quite clearly UpdateAfterEvent is being ignored.

Now the Flash docs are a little confusing here.

Under UpdateAfterEvent it state that UpdateAfterEvent calls are ignored if they are not in an onClipEvent.

Under Mouse.onMouseMove however an example is given which is doing exactly as I am and calling UpdateAfterEvent from a Listener.

Now the 2 are not exactly mutually exclusive but it does leave room for doubt.

SO .......... should/does UpdateAfterEvent work when called from a Listener ?

Interfaces and why MM needs to take the tutorial

OK I don't have the time for a long blog entry and you don't have time to read it lol. So this is the first in a series of thoughts on why and how Flash needs to improve as a development platform.

No its not another MM components bash, anyway as a maker of Flash components ourselves we wouldn't have much credibility if all we did was bash them.

What I hope this is, is some serious, reasoned and constructive arguments about ways in which things could be improved for all of us.

As I have said before, with FMX2004 MM wear two hats, developers of an application platform and developers of a component set. If its easier to see it this way they are like MS, developer of Windows and developer of Office.

Many people have complained about the bloat of MM Components and a number of third party developers have stepped up to provide lighter alternatives but as some one commented recently its not difficult to make a lighter component, the question is not is it lighter but what functionality did you leave out to make it lighter.

In almost every case the answer includes Focus and Depth Management. To be honest I don't believe Focus or Depth management SHOULD be part of a component developers task, its a platform level task not component level.

Focus and Depth management in the player are broken or lack the features needed for real application development. To their credit MM realized this and fixed it in FMX2004. Unfortunately they didn't fix it in the player but instead fixed it in actionscript code but by itself that's not really so bad.

So why don't third party components make use of these fixes provided by MM?

Well the answer to that lies in the implementation. Taking FocusManager as an example, FocusManager imports the UIObect, UIComponent and SimpleButton classes directly and many other classes indirectly. These classes are basically the "core" of the component framework that you are trying to replace so you have basically shot yourself in the foot as your slim component is now even more bloated then the original component you are trying to replace! Not a good idea.

So here we see we have a key element at the platform level bringing in most of the component level classes. The question is why does it need to do that?

If you go through the code you can break the reasons down into two categories first as an identifying "tag" i.e. the FocusManager wants to only process certain object so it specifies that they must be UIComponents for example and secondly so it can call methods on objects, for example to call setFocus.

Ok fair enough that is needed and probably your first reaction is well ok how else could they have done that?

So the platform level is inextricably linked to the component level, you cant have one without the other and therefore third party developers have to leave it out.

But there is an alternative way that this could have been designed so that the two levels aren't linked;

By using Interfaces.

Using interfaces is almost second nature in Java, it is very common to find Interfaces being defined and then implemented in Java. Incredibly, with FMX2004, MM gave us Interfaces so we could do just that, and then basically threw them out the window and ignored them when it came to writing there own code.

So how might they be used?

Well first where a "tag" is needed, lets say you want to identify those objects that will come under your Focus Mangement, you can define an IFocusable interface. For a tag interface it needs not define any methods at all a class just implements it to sort of put its hand up and say "me to". In Java you can see this with things like the Serializable interface, its just says, ok save me.

Now the second part was where we need to actually execute methods but this is also straightforward we could simply add those methods to our IFocusable interface. So when I implement IFocusable I am saying I want to be managed and I know how to react to a setFocus call.

The FocusManager then doesn't care about what type of object you are just that you implement that interface. FocusManager has no link to the component level other than a small IFocusable interface class so now it happily can mange both the MMComponents and third party components without being bound directly to either of them.

As I mentioned FocusManger also includes the SimpleButton class (which derives from UIComponent). It does this because it has to implement a system default push button functionality and it needs to be able to execute an action when some user action results in a default "click". It might seem harder to follow but again here an interface solves the problem. We just define an IDefaultClick interface which defines the signatures for methods that the FocusManger needs to use, any class can implement that interface not just a SimpleButton and again everything works without mandating that only certain specific classes are acceptable.

Now before you worry that with the framework being already bloated the last thing we need is more classes, lets understand that interfaces don't contain code or method implementations, they simply contain definitions or signatures of methods. They are very light weight and probably would only add a few hundred bytes to your movie but in return you now have a way to integrate a wider range of components into your clips, ones that might indeed be lighter or have functionality that the standard set don't have and yet they could still provide the basic platform level functionality that any real application needs.


This only starts to scratch the surface of where interface's could be used to improve the current architecture and provide us all with a trully open development platform.

I hope also you can maybe start to see that interfaces could be a way to start to break down the "framework" as a single monolithic block and start to make at a series of interchangable services.

Anyway maybe more thoughts later when I get some time.