Well I said I would talk about our experiences with Eclipse
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.
Friday, September 2, 2005
Thursday, September 1, 2005
Studio 8 Launch Event
I went to our local Studio 8 launch today.
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
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
Tuesday, August 23, 2005
XPComponents and Flux
Someone suggested that with so much happening in the Flash world at the moment I should talk about the future direction of XPComponents.
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.
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.
Thursday, August 18, 2005
Excluding AS2 Classes
Recently I have been looking at how to exclude classes from a swf as part of a strategy for constructing large multi-swf RIA where core classes are loaded in as a common shared library at run time and then individual forms are loaded on demand.
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.
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
<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.
Friday, August 12, 2005
New Flash 8 Player Security
Someone on Flashcoders today mentioned that one of our demos crashed under FP8, so I installed FP8 to check it out.
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.
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.
Flash 8 IDE
Its been over 5 months since I last got round to blogging, we�ve been heads down working on XP3 the next generation of the XPComponent framework but now its out the door our heads are coming back up. I will try to highlight some of the new features in XP3 in future posts but for now Flash 8!
So Flash 8 is announced, some great new features for sure, but I was somewhat disappointed in what wasn�t there.
I read this blog by g.wygonik and I agree with what is being said not so much from the aspect of particular features discussed but about development of the IDE in general.
Mike Downey has made several comments on the subject which I feel are very significant and are worth highlighting.
Let me summarise:
People wont use the Flash editor even if we improved it
People want other things improved
Flash is not for application development Flex is
Mike does say that this doesn�t mean that they are never going to improve the editor/IDE but to be honest that comment doesn�t make a whole lot of sense. If the facts as stated are true then how are you ever going to justify the resources needed to improve the IDE to match that of other similar products (IDEs - Delphi, VisualStudio, Editors-Eclipse,SEPY) particularly when in 2 years (or whenever F9 is out) the IDE will be even further behind the alternatives and the mountain will have become even steeper and higher.
Mike somewhat dismisses the rant about missing features by saying don�t get upset if your own personal favorite feature is not in Flash 8, but I think that is unfair the rant is not so much about one persons favorite feature but about lack of development in general of the IDE stretching back over several generations of Flash.
If we now have to wait until Flash9 to see any improvements that�s a long ways off and I cant see things changing then anyway. We have put resources, time and money with the aim of developing jsfl tools and wizards for use with our components in the IDE, our belief was that a visual IDE was an important element in creating Flash applications and a good IDE is a major productivity benefit to a language (just look at the Delphi IDE) and that someday soon the Flash IDE would be at least brought into the ballpark of VisualStudio (not the greatest IDE by any means ) but I realize now this is just not going to happen. The decision has been made and clearly Macromedia are following a different path.
So as a company focused on RIA�s or supporting developers who create RIA�s I have to take this on board. I shouldn�t be using the IDE to create applications and instead I should use Eclipse. So today I downloaded Eclipse, although we do do a lot of Java development we are not Eclipse users (we use JCreator) so it was something new (also makes me wonder how many MS shops were in MM�s survey group �cos I don�t know of many who use Eclipse) .
I don�t really have a problem with Eclipse but I will say if I am using Eclipse to write my code for sure I am going to use MTASC to compile it. Its just a natural fit and it seems that everyone else has the same idea.
I may be gaining in productivity using Eclipse/MTASC as I don�t spend half my day waiting for a recompile or needing to restart Flash after a crash but its not a visual IDE and in some areas my productivity is going to suffer.
One of the cool things with MTASC. is I can already build Flash8 swf�s even before the release of Flash8.
The question I find myself asking is why would I now want to upgrade to Flash 8? It has nothing to offer me that I don�t already have, and it sounds like its unlikely to have anything for the foreseeable future either.
Its a shame really a good visual IDE is a major productivity boost, Delphi has it, VB has it, others have it, Flash on the other hand doesn�t and seems to be giving up but there is no point in trying to fight lost battles so over time XPComponents will shift its focus away from the Flash IDE towards Eclipse and MTASC as the target development enviroment as MM suggest and so expect to see a lot more from us in this area in the future.
So Flash 8 is announced, some great new features for sure, but I was somewhat disappointed in what wasn�t there.
I read this blog by g.wygonik and I agree with what is being said not so much from the aspect of particular features discussed but about development of the IDE in general.
Mike Downey has made several comments on the subject which I feel are very significant and are worth highlighting.
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
Let me summarise:
Mike does say that this doesn�t mean that they are never going to improve the editor/IDE but to be honest that comment doesn�t make a whole lot of sense. If the facts as stated are true then how are you ever going to justify the resources needed to improve the IDE to match that of other similar products (IDEs - Delphi, VisualStudio, Editors-Eclipse,SEPY) particularly when in 2 years (or whenever F9 is out) the IDE will be even further behind the alternatives and the mountain will have become even steeper and higher.
Mike somewhat dismisses the rant about missing features by saying don�t get upset if your own personal favorite feature is not in Flash 8, but I think that is unfair the rant is not so much about one persons favorite feature but about lack of development in general of the IDE stretching back over several generations of Flash.
If we now have to wait until Flash9 to see any improvements that�s a long ways off and I cant see things changing then anyway. We have put resources, time and money with the aim of developing jsfl tools and wizards for use with our components in the IDE, our belief was that a visual IDE was an important element in creating Flash applications and a good IDE is a major productivity benefit to a language (just look at the Delphi IDE) and that someday soon the Flash IDE would be at least brought into the ballpark of VisualStudio (not the greatest IDE by any means ) but I realize now this is just not going to happen. The decision has been made and clearly Macromedia are following a different path.
So as a company focused on RIA�s or supporting developers who create RIA�s I have to take this on board. I shouldn�t be using the IDE to create applications and instead I should use Eclipse. So today I downloaded Eclipse, although we do do a lot of Java development we are not Eclipse users (we use JCreator) so it was something new (also makes me wonder how many MS shops were in MM�s survey group �cos I don�t know of many who use Eclipse) .
I don�t really have a problem with Eclipse but I will say if I am using Eclipse to write my code for sure I am going to use MTASC to compile it. Its just a natural fit and it seems that everyone else has the same idea.
I may be gaining in productivity using Eclipse/MTASC as I don�t spend half my day waiting for a recompile or needing to restart Flash after a crash but its not a visual IDE and in some areas my productivity is going to suffer.
One of the cool things with MTASC. is I can already build Flash8 swf�s even before the release of Flash8.
The question I find myself asking is why would I now want to upgrade to Flash 8? It has nothing to offer me that I don�t already have, and it sounds like its unlikely to have anything for the foreseeable future either.
Its a shame really a good visual IDE is a major productivity boost, Delphi has it, VB has it, others have it, Flash on the other hand doesn�t and seems to be giving up but there is no point in trying to fight lost battles so over time XPComponents will shift its focus away from the Flash IDE towards Eclipse and MTASC as the target development enviroment as MM suggest and so expect to see a lot more from us in this area in the future.
Tuesday, June 14, 2005
XP3 whats new part 1 - DataBinding
XP3, the third generation of XPComponents, will be released in a few days and people have been asking what is new in this release so this is the start of taking a look at some of the changes.
XP3 represents an evolutionary rather than revolutionary change although we have taken the opportunity to review the whole architecture and refine it.
DataBinding
A lot of work has been done in the data binding area.
DataSources in XPComponents are somewhat the equivalent of DataProviders and we provide a number of different types.
The basic DataSource which exposes a single data object (think of the equivalent of the data model for an html input form), ListDataSource which encapsulates an array of objects and XMLDataSource which represents an array of XMLNodes.
The XMLDataSource allows you to display and manipulate XML documents in a DataGrid or other controls whilst retaining the data in its orginal native XML format.
However if you wish to translate your source xml into native objects once it has been downloaded, we also provide the RecordsetDecoder and NodeListDecoder, which will automatically convert xml nodes into native objects. Both of these classes generate there own internal schema for a document to enable them to convert objects back into xml at some later point if you wish. These classes are both built on the new ArrayProxy class which provides support for "lazy" decoding.
All datasources provide built in support for inserts, updates and deletes with various validation events to prevent invalid being committed, these work in hand with the XPDataGrid's row based editor to prevent you moving to another row in the grid whilst data is not valid. We also track all changes that are made to the data to enable you to easily update the server appropriately.
An important new feature is the DataRelation, data relations provide built in support for master/detail or parent/child relationships between datasources in the client. So for example if you have a invoice(master) datasource and an invoiceitems(detail) datasource moving the master record will automatically cause the detail records to be filtered to expose only the related records without any code required.
The DataRelation also provides support during editing. It will block any attempt to move the master recordset whilst a child record is being edited unless that record can be sucessfully validated.
This enables you to quickly setup some quite complex and sophisticated structures on the client.
We also provide a number of connectors to handle communication with the server covering CSV, XML, remoting, web services and others.
XP3 represents an evolutionary rather than revolutionary change although we have taken the opportunity to review the whole architecture and refine it.
DataBinding
A lot of work has been done in the data binding area.
DataSources in XPComponents are somewhat the equivalent of DataProviders and we provide a number of different types.
The basic DataSource which exposes a single data object (think of the equivalent of the data model for an html input form), ListDataSource which encapsulates an array of objects and XMLDataSource which represents an array of XMLNodes.
The XMLDataSource allows you to display and manipulate XML documents in a DataGrid or other controls whilst retaining the data in its orginal native XML format.
However if you wish to translate your source xml into native objects once it has been downloaded, we also provide the RecordsetDecoder and NodeListDecoder, which will automatically convert xml nodes into native objects. Both of these classes generate there own internal schema for a document to enable them to convert objects back into xml at some later point if you wish. These classes are both built on the new ArrayProxy class which provides support for "lazy" decoding.
All datasources provide built in support for inserts, updates and deletes with various validation events to prevent invalid being committed, these work in hand with the XPDataGrid's row based editor to prevent you moving to another row in the grid whilst data is not valid. We also track all changes that are made to the data to enable you to easily update the server appropriately.
An important new feature is the DataRelation, data relations provide built in support for master/detail or parent/child relationships between datasources in the client. So for example if you have a invoice(master) datasource and an invoiceitems(detail) datasource moving the master record will automatically cause the detail records to be filtered to expose only the related records without any code required.
The DataRelation also provides support during editing. It will block any attempt to move the master recordset whilst a child record is being edited unless that record can be sucessfully validated.
This enables you to quickly setup some quite complex and sophisticated structures on the client.
We also provide a number of connectors to handle communication with the server covering CSV, XML, remoting, web services and others.
Thursday, February 17, 2005
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..
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..
Wednesday, February 16, 2005
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.
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 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?
Saturday, February 12, 2005
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.
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.
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.
Saturday, February 5, 2005
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).
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).
Friday, February 4, 2005
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 ?
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 ?
Wednesday, February 2, 2005
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.
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.
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.
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.
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.
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
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.
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.
Subscribe to:
Posts (Atom)