This is a port of our recently released FLEXPCharting which was for Flex2.

XPCharting For AS2 uses the exact same API as the Flex version and has the same features set as well. That includes over 30 different chart types, chart effects, color palettes, graphical borders etc.

This version is framework independent, it does not use nor interfere in any way with the FMX2004 framework, it is as happy being used in a class based application as a movieclip based one.

It is very flexible and lighweight with the footprint being around 60k for a chart including effects and borders.

If you need a poweful charting package for your AS2 applications today then this is for you, and if you decide to upgrade your application to Flex at some point in the future your code will be ready to run with FLEXPCharting.

For more info on XPCharting for AS2
http://www.xpcomponents.com/xpcharting.shtml

For more info on XPCharting for Flex
http://www.xpcomponents.com/charting.shtml

You can see the result here MY FirstChart.

Overall the experience was good, easy to install, easy to use and the end result is not to bad even if not perfect. There were a few glitches, it sometimes picks up the mouse or key click late so for example the menu has closed before the screen says "click here" same for some dialogs boxes. It also consumes a lot of disk space whilst recording the demo I built used over 1GB during building. Occasionaly it was also reluctant to stop recording.

Having said that it did exactly what it was supposed to and editing the timeline and adding in new objects was really simple.

I plan on trying a couple more demo building applications in the next few days to get a comparison. I will try to blog about them all.

I would be interested in hearing what you use.

Initially I looked around to see if there was any existing RegEx plugin for Eclipse but none of those I found did what I wanted, namely to test parse expressions and replace experessions. So as a result we now have created our own plugin.

You can download it for free from here http://www.xpcomponents.com/regexbuilder_1.0.zip

The plugin is designed to let you test out all Regular Expression but particularly parse and replace experessions.

Unzip the contents into your plugin folder and start FlexBuilderwith the clean option.

You might need to click on the menu Window/OtherViews to show the plugin.

Tools Demo

XPCharting provides a simple API for adding interactive chart tools into a chart at run time. Interactive tools are designed to let end users manipulate charts at run time, probably one of the most common usages, and the one we have implemented ourselves, is allowing users to draw trend lines over a stock chart.

The demo highlights the use of our TrendLineTool on an AxisChart which plots the DJIA for the last year.

The user can draw trend lines on the chart at run time using the mouse.

First press the mouse button down and then start to drag, a trend line is anchored where you clicked and then drawn to the current mouse location. The line is highlighted red whilst it is being sized but reverts to black once the mouse button is released.

But what if a user wants to change the trend line after it is drawn?

If you mouse over the middle of the line segment it turns blue indicating it can be moved, click down and then you can move the line to a new location. Note the line retains its current angle whilst being dragged.

But what if you want to resize or change the location of the end points?

If you mouse over the two end points of the line then line turns red indicating it can be resized and the end points moved by clicking down on the line whilst it is highlighted

Additional features included deleting lines by holding the shift key down when clicking on the line or duplicating a line by holding the control key down when clicking a line.

If you have any ideas for other tools drop us a line you never know we might just implement it.

Upcoming Features
XPCharting is continuously being updated, we are currently working on rotated text for the chart legend just what you need when you are short of space, look out for that very shortly.....

If you have any suggestion for a new feature or new chart types let me know....

FLEXPCharting is built on the Adobe Flex2 Framework and is 100% compatible with your Flex applications.

It is more than just a straight port of the AS2 version, it marks a major revision with many new and enhanced features. We have focused on providing more power to the developer and providing the tools that make it easy to create sophisticated charts. New chart types provide the developer with the power to create sophisticated chart analyses quickly. SubCharts enable you to add series to a child chart rather than being overlaid on the main chart, this is a commonly seen feature of stock charts where sub charts display additional information like volume or RSI that isn't appropriate to be overlaid. 3D look, graphical borders, DataEffects all empower the developer to create stunning visuals with little effort.

New series types
Lots of new series types like Stochastic, RSI, On Balance Volume, EMA and SMA.

SubCharts
SubCharts are a powerful new feature of FLEXPCharting. A sub chart is added below the main chart and shares a common horizontal axis with the main chart. This is useful where the series cant be overlaid, for example an RSI study tends to get lost if overlaid on a stock index chart but when appended underneath it easily conveys valuable information. The sub chart does not display a horizontal axis but shares the main chart horizontal axis.

Flexible Date Handling
Often charts needed to display date as a discontinuous range rather than a strict linear progression, For instance financial charts usually only have data for mon-fri rather than a full week. XPCharting default DateTime axis is a hyrbid value/category type allowing dates to be discontinuous but at the same time the are treated as Date objects that can be grouped as well as formatted. For example even with a discontinuous range of a years data it can still determine the periodicity and the appropriate labelling for the axis, displaying months with tick marks on the first data point of the new month whatever day it happens to be. We also provide a date/time as values axis so you get the best of both worlds. Date/Number formatting and parsing is handled by our own fully internationalized library which can format and parse any given pattern for any locale.

Multiple Axes
Multiple axes are supported. The SeriesSet object makes it easy to use a pair of indices with an array of Series whilst at the same time with each chart supporting multiple SeriesSets you can have any number of axes.

Drop Support
We have added in simple drop support so that users can now drag rows of data from a List or DataGrid control and drop it on to a chart and the chart will render it.

3D
3D versions of Pie and Doughnuts are included with work underway for more 3D types. We have provided both a full wire framed 3D model and also a shaded 3D model. The 3D charts can all be rotated in 3 dimensions.

DataEffects
We have added a whole slew of DataEffects like Fade, Slide, Zoom, Wipe etc. The effects are applied to a series when data changes. Many are built in allowing you to use them simply by setting a string property rather than needing to create them.

Palette
The Palette is a powerful new feature we have added to simplify the management of colors in a chart. The Palette not only manages all the strokes and fills in a chart but also can build them starting from a simple array of colors. It can create gradients both linear and radial and it will also generate additional complementary colors if it runs through the initial array rather than recycling which is important for per item fills. We have provided 15 built in palette each one with a range of complementary colors, these include the Halo palette, as well as others like BLAF or Excel. You can also easily create your own palette by specifying an array of colors or modify an existing palette. The palette makes it trivial to quickly change stroke width or alpha or use gradients without needing code just setting a few properties on the chart.

Background/Borders
We have provided 20 odd graphical border skins that allow you to quickly create attractive, distinctive charts.

Note: Although it is built on the existing Flex framework it doesn't not require the Adobe Flex Charts library.
For more info see http://xpcomponents.com/charting.shtml

We started using Eclipse a couple of weeks back as we have begun testing out Flux our flash xml ui product as it is targeted at non-IDE users.

We haven't used Eclipse before as all our previous Java coding has been done in JCreator which is a super fast C++ editor for Java, it is fully featured, with code folding and code completion and yet when it loads it takes only 18Mb of ram and rarely does it get much more than that, compared to Eclipse which being Java is a memory hog, a few days back I got up to 300MB in Eclipse and that was with every window closed!

Anyway Iam getting off the point, after installing Eclipse and getting it integrated with VSS for version control it was time to start editing some ActionScript.

First off we tried ASDT with Eclipse, ASDT is open source and free.
The initial experience was unfortunately bad. Like everyone when you start of in a new environment you tend to play around, so I created a project that would cover our source code that was in the Configuration/Classes folder. This was quite a trivial thing to do, unfortunately ASDT wasn’t happy about creating this project so it gave out an error message and proceeded to rollback. Unfortunately for me there is a known bug in the ASDT rollback code and thank you very much, ASDT deleted every single file under Configuration/Classes, going on for a 1000 classes! I must admit I was warned that ASDT has a tendency to delete files but, you know, I was smarter than that wasn't I! Lucky for me we have VSS so it was easy to replace the code.

After that I was put off for a few days but came back to it and with some help from a friend got ASDT and flashout working together relatively easily.

To be honest I found ASDT rather clunky, for its syntax checking it relies upon MTASC, there is nothing wrong with MTASC but MTASC is a compiler not an editor syntax checker. So here I am working on a class and ASDT says that there is an error in another class that is being referenced, I open that class fix the error jump back to my original class and lo and behold no errors! Unfortunately it’s not true, just that one error has been fixed, I need to get the syntax checker to kick in again to see if there are any more errors, so I have to "touch" the file, just type a space or something, then it will tell me the next error, and we begin the cycle again ..... That to me is a pain, and it was slow, even in the Flash IDE I can click the syntax checker and I get all the current errors displayed. Actually I found I was more productive using the Flash IDE editor and then just tab out to a command prompt to run MTASC than working with ASDT but thats a personal preference.

The issue as I see it with ASDT is that the pace of its development is just way to slow for it to keep up with the requirement needed for professional development, it not a criticism of the developers they have done a good job with the time they have, its just recognizing the fact they are doing it in their spare time and then don’t have enough time to dedicate to the project. It is the downside of open source development unfortunately. Really though there is an awful lot that needs doing and daresay it really needs re-writing from the ground up if it is to become viable long term.

But then in the last week along came FDT. FDT is a commercial equivalent of ASDT produce by PowerFlasher, it is also not exactly cheap! You can get it on a 20 day trial so we downloaded it and gave it a run.
Straight of it felt so much different from ASDT, you felt this was a product that was much more advanced, much more sophisticated. They have implemented there own syntax checking rather than relying on MTASC and this is just a huge plus. Not only do all your errors get labeled in one go but they actually put markers in the margin of your class file to easily see where the errors are and a little tooltip displays the error string. Now here is something which for the first time I would say was a productivity plus over the Flash IDE. FDT also picks up as an error where you havent put a ";" at the end of the line which is nice.

Not everything is perfect, this after all 1.0, we did have problem with classes reporting false errors due to an issue with not being able to resolve the super class. After struggling to sort this out for few days I contacted FDT directly and they were great and resolved the issue very quickly, it turned out to be a path issue which we could alter in the eclipse configuration.
Once that was fixed we were off and away, and I am happy to now report the XPComponent framework is fully compatible with FDT, no errors, no warnings (and also the same with MTASC).

I did mention to Nico at PowerFlasher that one thing that I missed from the Flash IDE was help panel integration. We have the whole XPComponent API in flash help panel format so you can have both code completion and easily get at the same sort of API help that MM provide for there own components when working in the Flsah IDE.
Well, they pointed that in FDT you can convert the Flash help so we ran that and in a couple of minutes we had our help file available in Eclipse. Unfortunately at the moment there is a small issue with the help as currently when it tries to jump to help for say the Button class it doesn’t have the right information to find the specific help file so you get a small list to choose form of all the help files for classes with Button in their name, like Button, ButtonList, RadioButton etc. but to give them there due the guys at FDT are working with us to find a solution to this problem so hopefully soon you will jump right to the help class and method you wanted without needing to pick anything from a list.

Overall when you compare ASDT and FDT the choice is clear, even though FDT is not cheap it is clearly so much better, so much more sophisticated and clearly a product with a devlopement team that are working round the clock to improve it further that’s it is well worth the price.

The only alternative on the horizon is Macromedia's Zorn, but at the moment Zorn is more questions than answers, what is it, when will it be available, how will it be packaged, what will it encompass and to be honest it is unlikley however it is packaged to be cheaper than FDT. So if your currently working in Eclipse I would say you really need to get FDT.

There was some really cool stuff to see.

I am quite excited about the bitmap caching, this will have a major performance gain for us in the more complex controls and in scrolling content like grids I imagine and particularly for our Charting components it will really enable us to expand on their current capabilities significantly.

Back in January we added user interactive tools to our XPCharting components for drawing trends lines and doing real time chart analysis but to be honest once you started adding more than a few trend lines on the screen the performance quickly dropped off.

It was cool and to a degree useful but it was really ahead of the players capabilities so we put further development of the more sophisticated features on hold awaiting the arrival of Flash8. In one demo which Mike ran, the Flash logo was built from bouncing blocks that were drawn on screen row by row. In Flash 7 it ground to a halt quickly, in Flash 8 it ran fast and never slowed at all, all the way through to the last line. As I watched I could just imagine our charts drawing series after series without any drop off in performance, I guess for that feature alone Flash 8 is worth it for us.

Some of the other graphics capabilities will be very useful as well, with things like bevels and drop shadows now being built-in this will enable us to replace the equivalent functionality we currently have in our components that is provided by AS2 code, this should provide further performance gains and hopefully enable us to reduce the footprint.

Video is not currently a significant factor for us and neither is mobile development because of the lack of support for AS2, so those features whilst really cool don’t do a lot for us.

As a flash component developer though the most significant thing to me was that in an hour long presentation from Mike Downey the word "component" never got mentioned, ok I correct myself it got mentioned once in respect of the video playback control which was called a "component". Also the MXDJournal special on Studio8 that was being given away at the event also never mentions components. How things change in only a couple of years!

If you take this in conjunction with what has been said about Zorn recently it is clear that the writing is on the wall for the Flash IDE as an application development eniviroment, like it or not the future is Eclipse (well at least for another couple of years before MM move on to the next "next big thing" LOL). I am going to do an article for the blog shortly on our experience with Eclipse, ASDT and FDT so I will go into more detail on this later.

After hearing how, after years of refusing to listen to designers about gif/png support on the grounds that it was too heavy too include, they found it could be added in only a few kbytes I was dissapointed that we didn’t also see RegEx added for us application programmers, its hard these days to name another significant programming language that doesn’t have RegEx built-in even ActionScript's cousins JScript and JavaScript have long had this capability, oh well maybe F9 then....

Overall the new player enhancements are great and without a doubt were needed, but from a developers perspective I find it hard to call it the biggest ever release but none the less I guess the improvements are welcomed.

Rob

This basically means talking about Flux!

Flux is the code name for a project we are currently working on.

Flux stands for a FLash User interface defined in Xml.

Might sound similar to Flex, I mean that’s Flash and XML right? True, they are similar products but I would describe them as siblings i.e. related but not competitors. Flux differs most significantly from Flex in that Flux is compiled at run time whereas Flex is compiled at author time, additionally all code behind in Flux is contained in actionscript class files not in scriptlets in the XML. I see both approaches as having there advantages and disadvantages, some situations will be best suited to Flex but I believabe others will be better served by Flux, I don't really see that there will be much overlap.

A typical Flux application consist of several precompiled libraries containing the XP3 component framework, plus your application specific code library and an xml file containing the definition of the overall application structure and screen definitions.

It will be possible for an application to be made up of more than one custom library/XML i.e. to have a Form or a group of Forms in a separate library and a separate XML file so that it will be possible to share Forms across different applications without needing to have the Form compiled into your application.

Much of the power of Flux comes from leverageing the existing capabilities of the XP3 framework with its layout managers, data binding, forms and application architecture.

The typical workflow that we imagine with Flux will be to create your application class files in Eclipse (i.e. ASDT, Zorn, or PowerFlasher), at the same time define your UI in XML, then compile your actionscript using MTASC, copy the compiled files plus XML to server and run.

The idea is basically similar to how you would handle a JSP or HTML application today, the interface is defined in an xml file then rendered at run time when a form is requested. Your own code behind will then exist in a compiled library and will be loaded and associated with the interface as it is rendered. The XML file will be modifiable after the application is compiled i.e. after being deployed, making simple layout changes trivial.

The foot print of Flux applications is generally very small, each Form will only be a few kb maybe in the region of 1 or 2 kb (obviously dependent on the amount of code you write) plus a few hundred bytes for the xml UI definition. The XP3 system libraries obviously are larger than this but then they will be cached on the client so they will only be needed to download once rather than with every application or Form.

Ultimately we hope to have a Flux Form designer that can be integrated with Eclipse though this currently has a low priority and wont be in Flux 1.0 .

Flux is currently under development, we don’t yet have a planned launch date but it will probably be sometime in October.

XPComponents will still continue to be targeted at both Flash IDE and Eclipse development, Flux will probably be sold as an add-on product that will targeted primarily for Eclipse based development.

For anyone interested in XPCharting, we have plans for substantial development of the charting package once we get our hands on Flash8. We are hoping that the improved graphic capabilities of Flash8 will provide the basis for major enhancements particular in user interactivity as well as improved rendering making more complex charts practical.

Flash 7 introduced the "exclude.xml" as a way to achieve this.

To exclude classes from compilation, create a specially named and formatted XML file and place it in the same directory as the FLA file. Name the XML file FLA_filename_exclude.xml, where FLA_filename is the name of your FLA file minus the extension. For example, if your FLA file is sellStocks.fla, the XML filename must be sellStocks_exclude.xml.

Place the following tags in the XML file:

<excludeAssets>
<asset name="className1"></asset>
<asset name="className2"></asset>
...
</excludeAssets>

The values you specify for the name attributes in the tags are the names of classes you want to exclude from the SWF file. For example, the following XML file excludes the mx.core.UIObject and mx.screens.Slide classes from the SWF file:

<excludeAssets>
<asset name="mx.core.UIObject"></asset>
<asset name="mx.screens.Slide"></asset>
</excludeAssets>

Ok so this does work but the problem is it does not work properly, there are still classes that get compiled into the swf.

I was pointed to this article by Darron Schall which did provide useful information.

However in one case after several hours work to rework a class so that it would be excluded I was pleased to see it worked and the class was excluded, however the swf footprint went up, I was wondering what was going on!
Well after poking around inside the swf using ASV I saw that though the target class was not there several other classes had now been included. These were unrelated to any changes I had been making.

So at this point I decided to go back to basics and try and look at some very simple cases to see what was really happening.

I created a swf with no assets but with some code that directly referenced half a dozen classes. Without the exclude file the swf was 54k, with the exclude file it was 159bytes, good so far!

I then created another swf with a particular component and with the exlude file it was 7k which was all made up of graphical elements in the component. Again, good so far.

So now what happens if I combine these two files?
Well at worst case the size should be simply the two individual file sizes added together, however if the two files shared some classes you might expect the total size might reduce.

So what did happen?

The resultant swf was 35k, why???
Using ASV I can see a whole bunch of additional classes were being included.

I cant see any logic to explain this behavior.

But thats not the end of the story, taking this 35k swf I added additional components and placed them on the stage.

Again logic says the swf size would stay the same or increase depending on the overlap of the classes needed but what happened was the swf decreased in size to 21k.

At this point I give up further testing, although using an exlude file does have a very significant effect and certainly becomes an essential part of the strategy for developing larger RIA's there is no way to predict its impact or plan the class structure to achieve the smallest size swf. Just to be clear, from my own testing on the average form I can achieve reduction in size ranging from 50% up to 80% using the exclude file but whatever reduction you do initially get there isn't anything you can do to tweek it to get the remaining classes excluded.

It would be nice to think that this might be sorted out in Flash8 but it has already been said that little has changed in Flash 8 related to actionscript and anyway MM's focus is moving away from Flash so I guess this might become a feature of Zom.

I should note in this respect that MTASC also supports an exclude file, though it uses a different format, from testing it was accurate and consistant in excluding files.

In fact we are currently using MTASC to build the core shared component library as it is able to achieve a significantly smaller footprint than the same built from the Flash IDE.

Whilst checking into the issue I ran the application from my local PC and came face to face with the new security features of FP8 from a user perspective.

All I can say is I hope it is improved by the time it is released.

The application basically links to our site and downloads an XML document and some jpg's.

First I got the message box saying that a potentially dangerous thing had been stopped and I needed to click settings if I wanted it to go ahead, fine so far. Bit to long a delay while it fires open a new browser and heads of to the MM site to show the security setting screen but ok if this is really unavoidable. Once there it took me a while to realise that I needed to add the url of our server as a trusted location and restart but OK got that done.

On restart I get the same message, again go to MM site, so maybe I got the wrong url, so I enter another of our servers url's as trusted and restart.

and again... and again... didnt matter what I put in it wasn't what FP8 needed.

So in the end I just clicked the option to say just trust everybody..

Thats fixed it..

Now this may be just a beta issue, but a suggestion here.
When you go to the security page why not tell me what the url the application was trying to access was and then just give me the option to say "OK that one is good" 'cos in reality no user is going to actually enter trusted sites it will be "all" or "nothing" unless you give them something to click.

We haven’t done any major code-editing improvements for hand coders as we found that almost all of the hand coders that we interviewed preferred to choose their own text editor. Even if we had added all of the features of an editor like PrimalScript or Eclipse (which would have been far too much work for a single cycle) users told us that they would still use their own editors. So we decided to focus on other things instead

We met with customers all over the world who represent every key segment of the Flash user base (solo devs, creative agencies, educators, enterprise shops, etc) and found that, overwhelmingly, everyone had a different idea of what features a good text editor should have and - even more so - were very attached to their existing text editor solutions.

The number of Flash users who are advanced hand coders and would be willing to give up their text editor to go back into Flash was far too small when compared to the greater base of Flash customers.

In the case of Flash 8, users made it clear that code editor enhancements like the ones mentioned in this thread were important - but not as important as the other things that we did.

We developed Flex because Flash authoring was never going to fit the traditional application developer market (Java/C++/.NET/etc) so we needed to do something new. Flex is not a replacement for Flash, it’s a new solution targetted at a completely different market

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..

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.

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?

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.