• getItemAt()
• removeItemAt()
• addItemAt()
• replaceItemAt()

and the selectedIndex property. you can do a lot with a bit of action script:

and an update on the illegal ActionScript error, you can't use any of the restricted keywords even in AS comments. "//new delete" will also throw that error.

i've been struggling for a week now trying to work with the xml that cftree needs if you use it via remoting (and who wouldn't these days with flash forms in cf7)--yes you have to feed it xml rather than a cfquery, cfform like cfdocument, hides rather a lot complexity from us poor coldfusiuon developers. one of the things i'm trying to do was locate a given node in a cftree. while plowing thru the flex documentation i noticed methods to determine if a node was a branch (had nodes under it) and if that branch was open or closed. what you can programatically get at depends on whether a branch is open or closed. don't take my word, put up a ctree w/a button that does a

and see what you get as you open and close nodes in the tree. to make a long story short, while trying to figure out a way to traverse a cftree i stumbled on a method to open or close a cftree via some simple ActionScript.

you can see a simple example here. i imagine you could adapt this to open/close any bits you needed.

• __proto__
• import
• createTextField
• loadMovie
• attachMovie
• Delete
• New
• createChild
• duplicateMovieClip
• registerClass

this is all documented in Creating Forms in Macromedia Flash/Using ActionScript in Flash forms section of cfdocs. but what the docs aren't saying is that you can potentially use AS in some (to me) strange places. two of the strangest places are in alert message text and tooltips. the tooltips nearly drove me mad trying to figure out why i was getting illegal AS errors in my flash form when none of my injected AS was using any of the restricted keywords. it turns out i had a couple of buttons with the seemingly innocent "delete" word in their tooltips.

so, pay attention. if you're getting seemingly insane illegal AS errors, look to your tooltips and/or your alert messages instead of head-butting your monitor (or bombarding mike nimer with emails).

update: look to your injected ActionScript comments as well.

one of the things that took some time for me to catch on to was that the ActionScript we were injecting into our flash forms, wasn't quite "live". for example, what would the following alert show if injected into a form button that some cranked up monkey was taught to push once a minute for an hour?

while i suppose pretty much everyone else knew the correct answer (2), it took me almost an hour to figure that out. if you wanted to have that var updated you'd need to store it's values outside that snippet (which is re-run exactly as is whenever that crazy monkey mashed down it's button), the usual suspect being one flavor or other of cfinput. even in moderately complex apps this inevitably leads to a plethora of cfinputs named (in our naming scheme) like cheesyFolderHolder, cheesyServerStatus, cheesyIMAPserver, cheesyGrabBag, etc. the relationships and interactions between these can get kind of hairy for a cf developer more used to the seemingly cleaner environment of the back-end (well it seemed kind of by-the-seat-of-your-pants to me anyway).

luckily one of the more interesting bits of ActionScript that cfform does allow is sharedObject (you flash developers can avert your eyes while i try to explain this to my fellow cf developers, it's kind of like a cookie, ok you flash developers can look now). so you can do things like:

which makes the info contained in the data part of that "imapClient" sharedObject available to other ActionScript snippets:

one downside is that users can turn this functionality off like cookies in a browser, so you'd need to test for this and fallback accordingly (though i think this means the data won't be saved locally but still available between snippets).

thanks to seth duffy for suggesting this idea.