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.
Thursday, January 27, 2005
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.
Friday, April 16, 2004
Wacky instance variable initialization
Came across something that is so wacky its hard to believe its true.
We had a component where we initalize an instance variable to an empty object in the class declaration as in:
var myVar = {};
Nothing too earth shattering here!
So its clear we should have an instance variable intialized to an empty object, so I could then do something like this;
myComp.myVar.empty=true;
or this
myComp.myVar.name=_name;
and then trace(myComp.myVar.name) will display the components instance name.
OK so whats the issue .. well it seems that the object that myVar points to is static (or global if you will) so now every instance will see myVar.name as the same name and NOT its own instance name.
We thought we must be missing something about using "{}" so we tried using new Object() instead but to no avail, the object created is always static and all instances will be pointing at the same object.
We resolved it in the end by leaving the var as undefined and then in the ancestor "init" method setting it to an empty object, then it all works correctly or I should say works as expected.
Ok there maybe be some obscure explanation for why this behavior is correct but at least its not obvious nor is it in line with what you would expect in other languages and could catch you out in building you own components so beware...
unless of course its a neat trick you would like to exploit...
We had a component where we initalize an instance variable to an empty object in the class declaration as in:
var myVar = {};
Nothing too earth shattering here!
So its clear we should have an instance variable intialized to an empty object, so I could then do something like this;
myComp.myVar.empty=true;
or this
myComp.myVar.name=_name;
and then trace(myComp.myVar.name) will display the components instance name.
OK so whats the issue .. well it seems that the object that myVar points to is static (or global if you will) so now every instance will see myVar.name as the same name and NOT its own instance name.
We thought we must be missing something about using "{}" so we tried using new Object() instead but to no avail, the object created is always static and all instances will be pointing at the same object.
We resolved it in the end by leaving the var as undefined and then in the ancestor "init" method setting it to an empty object, then it all works correctly or I should say works as expected.
Ok there maybe be some obscure explanation for why this behavior is correct but at least its not obvious nor is it in line with what you would expect in other languages and could catch you out in building you own components so beware...
unless of course its a neat trick you would like to exploit...
Thursday, April 1, 2004
HTML and the standalone player
Ran into a quirky thing today, is it me or are the standalone player and the web player handling HTML slightly differently?
Trying making a movie that loads HTML using the XML object from an external file and insert it into a TextField(there is a sample app that does this in MX2004).
Running this in the web player and it works as you might expect but in the standalone player it seems that it recognises CRLF's in the text as well as BR tags. Thinking about it the problem could be in the XML object... is the XML object stripping CRLF's from the HTML that is being loaded in one version but not the other.
Ok so I guess the two players are different versions, I think from memory the standalone is 7014 and the web is 7019... have things changed?
Anyway if I am right, you need to be carefull about your HTML content if you think someone might be viewing using the standalone player as otherwise your pretty formatting will get screwed up.
Whilst we are talking about HTML and TextFields.. Since we can now load jpg's into the TexField and since these are usually being pulled over the web it can take some time to load. Wouldnt it be nice if there was some event to tell us the TextField had finished loading/rendering. As far as I know there isn't and the result is you must let the user watch your TextField rendering itself as the images are loaded one by one and so alter the layout.
Trying making a movie that loads HTML using the XML object from an external file and insert it into a TextField(there is a sample app that does this in MX2004).
Running this in the web player and it works as you might expect but in the standalone player it seems that it recognises CRLF's in the text as well as BR tags. Thinking about it the problem could be in the XML object... is the XML object stripping CRLF's from the HTML that is being loaded in one version but not the other.
Ok so I guess the two players are different versions, I think from memory the standalone is 7014 and the web is 7019... have things changed?
Anyway if I am right, you need to be carefull about your HTML content if you think someone might be viewing using the standalone player as otherwise your pretty formatting will get screwed up.
Whilst we are talking about HTML and TextFields.. Since we can now load jpg's into the TexField and since these are usually being pulled over the web it can take some time to load. Wouldnt it be nice if there was some event to tell us the TextField had finished loading/rendering. As far as I know there isn't and the result is you must let the user watch your TextField rendering itself as the images are loaded one by one and so alter the layout.
Sunday, February 22, 2004
Writing Documentation Sucks
As a few people noticed we were asking for beta testers for our XPComponents last week.
Well first we were stunned by the response, thought it would take weeks to get the people we wanted, instead it took hours!
Of course then we were caught wrong footed, the docs were not ready to start the beta!!
So this week has been a week of writing docs. Boy does it suck. You seem to write forever and still there is a mountain to climb.
Now I understand why MX2004 got released befor the docs were ready lol!!
I have to mention here JellyVision's ActionDoc it is a superb tool for building documentation for AS2 classes even though its still in an early beta phase.
If you havent got it ... get it now!
Actually, confession time, the last few months of building our components has given me a lot of understanding for WHY MM did certain things the way they did. Sometimes we would find after doing something we swore we wouldn't do that MM had done something quite similar, its like developing incrementally you can end up at a point where there is no way out but to do what at the outset you thought was unecessary
Having said that, it hasn't changed my views on the MM Framework, concept excellent, implemantation flawed, sorry for that!
Well first we were stunned by the response, thought it would take weeks to get the people we wanted, instead it took hours!
Of course then we were caught wrong footed, the docs were not ready to start the beta!!
So this week has been a week of writing docs. Boy does it suck. You seem to write forever and still there is a mountain to climb.
Now I understand why MX2004 got released befor the docs were ready lol!!
I have to mention here JellyVision's ActionDoc it is a superb tool for building documentation for AS2 classes even though its still in an early beta phase.
If you havent got it ... get it now!
Actually, confession time, the last few months of building our components has given me a lot of understanding for WHY MM did certain things the way they did. Sometimes we would find after doing something we swore we wouldn't do that MM had done something quite similar, its like developing incrementally you can end up at a point where there is no way out but to do what at the outset you thought was unecessary
Having said that, it hasn't changed my views on the MM Framework, concept excellent, implemantation flawed, sorry for that!
Inspectable Getters and Setters and Live Preview
I saw an interesting article over at Bit-101 about this subject.
Well its true, as they have found, the Live Preview in MX2004 is pretty screwed up (to use the correct technical term), leading to some convaluted and weird code trying to get things to work, we almost thought about knocking LivePreview on the head at one time!
The basic rule we have now settled on is that setters should never do anything except set an internal variable and then call invalidate(), nothing more... and you should never call draw() directly.
Regardless of how many times invalidate gets called in a frame it will only ever result in a single call to draw() on the NEXT frame, so the constructor, setters or whatever can fire as many times as they like in whatever order they like... and you just do your real work in the draw() function in the following frame.
This does away with the need to check for whether initialization is complete, and solves most of the problem cases.
For those complex situations that need more, there is also a boolean variable childrenCreated that tells you whether the initialisation has occured and you have passed through the creatChildren function. This can be used to allow you to abort functions when they are being called in the incorrect state.
We also decided in our own XPComponents (since were not using the MM framework we can do what we like) to add an initComplete() call to the end of construction process to help resolve one niggling problem, though I have noticed that in the last update to MX2004 they have now built in an _endInit() method which essentialy does the same thing. Except in an isolated case I am really sceptical of the need for this function.
There are a few other things that you should do that solve some other niggling issues that can drive you up the wall trying to resolve...
Place the getter first and put the metadata tag on the getter.
(Helps with getting the inspector to implicitly recognise non string props)
If you extend another class dont use the full path to the class you are extending, first import it using the full path and then extend using just the class name.
i.e
import com.mydomain.mycomp;
class newone extends mycomp{}
DONT do this
import com.mydomain.mycomp;
class newone extends com.mydomain.mycomp{}
(Helps with getting inherited props to be recognised by the inspector)
Well its true, as they have found, the Live Preview in MX2004 is pretty screwed up (to use the correct technical term), leading to some convaluted and weird code trying to get things to work, we almost thought about knocking LivePreview on the head at one time!
The basic rule we have now settled on is that setters should never do anything except set an internal variable and then call invalidate(), nothing more... and you should never call draw() directly.
Regardless of how many times invalidate gets called in a frame it will only ever result in a single call to draw() on the NEXT frame, so the constructor, setters or whatever can fire as many times as they like in whatever order they like... and you just do your real work in the draw() function in the following frame.
This does away with the need to check for whether initialization is complete, and solves most of the problem cases.
For those complex situations that need more, there is also a boolean variable childrenCreated that tells you whether the initialisation has occured and you have passed through the creatChildren function. This can be used to allow you to abort functions when they are being called in the incorrect state.
We also decided in our own XPComponents (since were not using the MM framework we can do what we like) to add an initComplete() call to the end of construction process to help resolve one niggling problem, though I have noticed that in the last update to MX2004 they have now built in an _endInit() method which essentialy does the same thing. Except in an isolated case I am really sceptical of the need for this function.
There are a few other things that you should do that solve some other niggling issues that can drive you up the wall trying to resolve...
Place the getter first and put the metadata tag on the getter.
(Helps with getting the inspector to implicitly recognise non string props)
If you extend another class dont use the full path to the class you are extending, first import it using the full path and then extend using just the class name.
i.e
import com.mydomain.mycomp;
class newone extends mycomp{}
DONT do this
import com.mydomain.mycomp;
class newone extends com.mydomain.mycomp{}
(Helps with getting inherited props to be recognised by the inspector)
Subscribe to:
Posts (Atom)