Yes, it's on our list of things to do for a future release of Edge Animate.
I guess we'll use this thread to add our Feature Requests as we come across Edge Feature that could use betterment... or should a formal "Wishlist for Edge Animate" be posted as a place to collect future feedback about feature requests? In the meantime I'll post here mine...
Keep the current status of live edit view at all times.
When publishing to do a quick preview, Edge Animate will reset to Stage view, even if the last "status view" was several "levels" deep into nested symbols. This makes for an extremely tedious and frustrating workflow especially when needed to do frequent test-publish to preview results of applied changes in code or live edit views. Each time upon returning from the browser to Edge, the user will have to drill in live view going into the level he/she was prior to issuing a publish. Doing this each and every time after a test preview publish can create cases of boldness as users will go nuts and will rip all the hair off their head... (nothing bad with boldness but should not be caused by shortcomings of applications where time should be spent being creative not getting mad )
I hope issue described above will make sense, if not ask away (I am referring to keeping the live view state, not to ripping one's hair off obviously ).
Implement a more intuitive and UI driven way to add "targets" in code view.
It's quite time consuming to have to find out why "targets" (nested symbols or elements) aren't "responding" to code being written in the form of absolute targeting as in something like:
I have a case of this right now which makes absolutely no sense and it's driving me nuts... but eventually I'll figure it out and perhaps it'll be a simple "can't do that in Edge yet" explanation as it happened in the past
Of course with more involved nesting and more complex interactions the whole thing could become very quickly a nightmarish clusterFunk to work with, not to mention that in such cases where one needs to publish frequently to check results, having the previously described shortcoming in the workflow, just accelerates the aforementioned case of forced hair loss
Thanks... I keep coming back to the second one "Implement a more intuitive and UI driven way to add "targets" in code view" http://forums.adobe.com/ideas/2145 as I miss the features that came always handy in flash/flex, intelliJIdea, FDT and similar IDEs that use autocomplete in very smart ways where even custom classes (and their contained objects) defined within a project, got picked up by the IDE and would then be presented as an option to choose while writing code.