Definitive Flash MX 2004 Bug and Complaint List

[FPChris]

Hi Mike. Thanks for taking time to reply...



if you follow the guidelines Flash will throw an error ->


var num:Number = 3;
var str:String = "Hello";
num = str;


Throws this error:
Type mismatch in assignment statement: found String where Number is required.
num = str;

Am I missing something?



Yes. Understood, thats my point.
The whole point of error checking is to catch when
the user didn't follow the guideline rules...

var Num:Number = 3;
Str = "Hello";
Num = Str;

...should never compile.




21) Changes to .as window is not seen until you save all vs.
coding directly in the fla which see it without needing to
constantly save. No idication that changes aren't included.

I don't know what you mean. Are you referring to working with external .as files? And when you say "changes" do you mean the testing the FLA in the authoring environment doesn't reflect any changes made to the .as file until you've saved that .as file? If that's the case, welcome to IDEs. I can't imagine a workable alternative. It's not like clicking File > Save All before you test is hard... But correct me if I'm missing something...



I've spent years in C++ Builder which has a real IDE with
tabbed windows. I can have 30 windows open and no matter
what code window I'm in it will compile that change.
File->Save everytime IS a major annoyance in large projects.
This allows for testing without committing to that change as
well as assurance that the developer is seeing all changes.
In Builder I can also run the app from any window I'm current
coding in.

I realize Flash isn't Builder, just I'm letting you know what
other developers expect from their IDE since MM is going
in that direction.

What I meant in my previous post about 'several version to MX2004'
are well known bugs that remain after several versions.

---

Even with all the problems I have with MX2004 if that undo
issue wasn't there I probably suffer through. That's the
real workflow killer I can't get around.

Again, thanks for your time.

Chris

[FPChris]

Mike, update... the undo now is completely linear.

You can undo changes inside a symbol but not in a
non-linear fashion that we're used to.

I really hope this gets changed back soon.
You yourself notice what cool feature that was.

Thanks again.

Chris

[senocular]

I seriously doubt thats going to change. Given the nature of the history panel and how the history and undos are now handled, its just not feasible. A seperation would completely break any multi-scoped action you would want to save as a new command - one of the advantages the history panel allows for.

[FPChris]

Sad, truely sad. IMO I'd rather sacrifice having a list
in favor superior functionality.

Chris

[epowder]

Originally posted by senocular
I seriously doubt thats going to change. Given the nature of the history panel and how the history and undos are now handled, its just not feasible. A seperation would completely break any multi-scoped action you would want to save as a new command - one of the advantages the history panel allows for.

Commands are stored independently based on editing steps. Any command can be used in any instance.
If every instance had its history list, then things would be just the same as before. And you would have commands


epowder

edit: commands seem to be available/working only for instances of the symbol it was created on. Test it and you will see. An extra reason to have seperate history list for every symbol/instance.

another edit: the commands i'm talking about in edit1 are commands on multi leveled clips. 'Simple' commands work for any 'simple' object.

[MikeDowney]

Originally posted by FPChris

Yes. Understood, thats my point.
The whole point of error checking is to catch when
the user didn't follow the guideline rules...

var Num:Number = 3;
Str = "Hello";
Num = Str;

...should never compile.

Update: feedback from the product team is that enforcing strict type casting would have caused problems for those wanting to use AS2 yet publish to Flash Player 6, which does not support any type of type casting (but does support AS2). So it was a decision involving maintaining backwards compatibility.

Regards,
MD

[PAlexC]

I agree 100% on the timeline effects.

I have to build my movies assuming I will need to make changes in the future. I want to work on the timeline, not have an interface that edits the properties of some Flash-generated MC that just puts more crap in my library.

[MikeDowney]

Originally posted by PAlexC
I agree 100% on the timeline effects.

I have to build my movies assuming I will need to make changes in the future. I want to work on the timeline, not have an interface that edits the properties of some Flash-generated MC that just puts more crap in my library.

Yeah, I agree with you. Timeline effects were created - IMHO - for two reasons: 1) To make Flash more approachable to completely new users and allow them to create *simple* animations quickly and 2) to allow traditional Flash users a very *quick* and *simple* way to create basic animations.

Personally, I don't think I'll use them very often, if at all (except for demonstrations). But I know many new users will find comfort in having them available.

One other thing to consider is that the timeline effects included with Flash are just the start. Flash MX 2004 has a whole new extensibility architecture that will allow developers and 3rd parties to write extensions - like timeline effects. My hunch is that some Flash genius will figure out a way to make even more impressive timeline effects that even seasoned pros will want to use.

That's my hope, at least. :-)

Regards,
MD

[PAlexC]

Good news is that the Flash Player 7 now auto-updates itself so when we do find bugs (with the help of our VERY SPECIFIC users :- ) we can update the player and push it out rather transparently.

Here's a timely question then. What about corporate users behind firewalls? What about the version that the plug-in that corporate IT approves and deploys inside their organization? It's possible they would want a version that doesn't auto-update because they don't want to mess with their standard builds, don't approve ANYTHING until it's been thorougly tested, or just see it as a potential security threat.

Corporate IT is seriously picky.

ALL of my content goes to corporate clients. I can't rely on an auto-update to occur in order for my content to function.

Oh, and how long until Authorware officially dies?

[MikeDowney]

Good question. Let me look into it. Stay tuned...

[FPChris]

Originally posted by MikeDowney
Update: feedback from the product team is that enforcing strict type casting would have caused problems for those wanting to use AS2 yet publish to Flash Player 6, which does not support any type of type casting (but does support AS2). So it was a decision involving maintaining backwards compatibility.

Regards,
MD

If I wrote something in AS2 and wanted to publish to Player 6
I realize AS2 gets converted to AS1 during the compile.
If MM is error checking only after AS2 is converted to AS1
then yes, what you say stands true and strict casting would fail.

However. If they placed error checking before the AS2 to AS1
conversion how could that cause any backward compatibility issues?
It simply couldn't. Telling the programmer "Hey, dummy, you're
assigning a string to a number here." is not a version issue.

The programmer would be notified of the error.
The code would be corrected and still convert to AS1 properly.
And all would be right with the world.

Thanks all the same. I long for the day when AS2 is a
brutally strict as C++. It make for easier bug tracking
and forces the programmer to get it right.
I guess we're just not there yet.

Chris

[PAlexC]

Originally posted by MikeDowney
Good question. Let me look into it. Stay tuned...

Appreciate it. If you do get specifics around auto update and what it means to corporate IT, drop me a PM or e-mail. It's kind of a big issue in my field.

[MikeDowney]

Originally posted by FPChris
However. If they placed error checking before the AS2 to AS1
conversion how could that cause any backward compatibility issues?
It simply couldn't. Telling the programmer "Hey, dummy, you're
assigning a string to a number here." is not a version issue.

The programmer would be notified of the error.
The code would be corrected and still convert to AS1 properly.
And all would be right with the world.

Yeah, you're kind of beyond my realm of expertise here. I'm sure the engineer that worked on this feature would spew a bunch of technical reasons why this couldn't happen. Or there's always the possibility that it was just something that couldn't fit into the schedule. Though I doubt it w/ this specific issue.

Maybe in the next release. ;-)

[FPChris]

Ok. Thanks Mike ... Also thanks for sticking around and taking
the heat as well.

And please tell your guys that the undo system was way
better before and put to it back! Don't fix what isn't broken.

Chris

[senocular]

I wasn't going to say anything about this, but its been eating me so Ill just go out with it.

Nothing new; just a rant, so dont take my attitude to heart

Originally posted by MikeDowney
Timeline effects were created - IMHO - for two reasons: 1) To make Flash more approachable to completely new users and allow them to create *simple* animations quickly and 2) to allow traditional Flash users a very *quick* and *simple* way to create basic animations.

Ok thats fine. Yes, quick and EASY is good. Yes, help the new users. Fine idea! The concepts are basic and usable for probably only a few of Flash beginners who want to cheat their way through getting things done without actually knowing how to use the program, but hey. Can't hurt, right? Besides, In all honesty, in support of the feature, I can certainly see how this can some tedious tasks go a little smoother. Anyway, the point was for ease, right? Keep that in mind.

Originally posted by MikeDowney
I think Normal Mode just wasn't going to work with the new improvements in ActionScript 2.0. It's not that we had an engineer glaring over his cubicle wall with an evil grin going "Wooo-ha-ha-ha, I'll just take their Normal Mode away!" ;-) We found that most experienced Flash users were probably going to be OK with transitioning to hand coding their scripts.

Hmmm yes. Apparently now only experienced users do any kind of coding in Flash? Oh wait, Im sorry, this is because of ActionScript 2.0. Yes, ActionScript 2.0, the scripting language in Flash that is not scripted in the actions panel but rather in the External ActionScript File Editor of the Pro version of Flash MX 2004 (or desired third party app). Well there, sure it makes perfect sense that such developers would not need access to normal mode. Being in the Pro version, they should be expected to be beyond that, at least when coding AS 2.0. Makes sense.

But what about company employee 238, little Miss Sally-Jane who uses the corporate Flash app for her presentations and short animations. She still needs actionscript but shes not doing anything remotely close to class development in AS2.0. No sir, shes sticking to the Actions panel for simple AS to drive the simple interactivity needed in her simple projects.

With Flash MX2004, however, no simple normal mode for her. Sure, she can use timeline effects now. Woopee. Not like shed needs them as Flash for her is primarily an animation tool anyway - with advantages in simple interactivity. Timeline effects are not her thing. No big deal. No one says she has to use them as shes perfectly fine with the timeline all by herself. All she needs is just a little help with the Actions in her simple interactivity. Shes keeping it simple, but now if she needs to add a simple play(); action to a button, she now can't simply go

[+] > Actions > Movie Control > Stop()

And Boom be done like she could in MX with normal mode. Nope, she has to dig in that crazy long [+] list and find

[+] > Global Functions > Movie Clip Control > on

(which is real intuitive being on a button) then selecting release for the event, and then manually move her cursor within the on block and then find and insert stop(); She can either do that or type it out her self as if shes the developer shes not. Clicking is her thing, not typing.

Quick and easy this is not.

So why then is one added and probably rarely used feature so important to ease and productivity (timeline effects) when the other more important feature (normal mode) is not? Taking it out certainly doesn't make things easier or faster for anyone. It has no effect on those who didnt use it (and this meaning positive effects at that) but it does severely hurt those who did use it. Im still having trouble seeing justification.

Now, seeings how the actions panel itself is pretty much solely for AS1.0 (with the tiny exception of using it to export AS2.0 script which would be a pain and illogical) there should be no AS2.0 relevance to it being removed. And even if there were confliction, which I wouldn't doubt, then people would know better to use expert mode for AS2.0. Is not AS2.0 more or less an expert mode of AS1.0? ... directed to programmers? ... programmers who wouldn't dare touch normal mode in the first place? Thats not very supportive of the normal mode removal. So what is?



Personally, I don't care since I never use the thing. But I know people who do - people very much fitting the 'Sally-Jane' character I conjured above - who will just hate the fact that normal is gone (admittedly I haven't discussed it with anyone of them). Still, it means theres only that much more they have to learn to be competent with Flash as if the transition to a new version wasn't bad enough.

Note to Mike: This isn't directed to you personally, I understand your position in all this Im just using your quotes as a reference

[senocular]

... Mike, don't feel obligated to reply... I doubt I can stop that now but it wasn't meant for rebuttal, just to vent

[MikeDowney]

Hi Senocular -

Your sarcasm was pretty thick there, but I'm a pretty sarcastic guy myself so I won't take it personally.

I think we may be misunderstanding each other a little. Let me see if I can clear a few of these things up so we can all see the sunshine.

Regarding features for new users
First, to address the scenario with "Little Miss Sally-Jane" as you put it. It is for this stereotypical user that we created the "Behaviors" panel. If a *new* user wants to do simple ActionScript interactivity - the same that you mention - he/she can do so with the behaviors panel quite easily. Now it's not perfect, but to me, it's a lot easier than before. There's really - IMHO - not THAT big of a difference between "Normal Mode" and "Expert Mode". You can still add scripts the same way you did before, but now you have to know a little more about what the script is doing if you don't want to use the behaviors panel.

Keep in mind that Flash is a professional's tool. Contribute is an example of one of our "Information Convenience" apps that are targeted at average business users. It's designed to be incredibly simple. These new features - timeline effects and behaviors - are really intended to help new users get productive quickly and actually do something. I think we kind of expect many of the new users to ultimately learn and develop their Flash skills to a point where they transition to the more advanced workflows.

I do think these convenience features are important though. Trust me, I've tought thousands of new users how to use Flash for Macromedia over the years and quite often people just sit there and stare at a blank stage. Flash is very *strange* for many that have never used anything like it before. It's not that ActionScript is going to indefinitely confound them, it's just that there is a LOT to take in when you first get started - now matter how technical you are. For that reason we decided to go the direction that we did w/ Flash. During development we had two big groups of potential customers - new users who found Flash too difficult to get started with, and pro users who thought Flash didn't have enough advanced features for them. Sure there are still a lot in the middle, but when you work in product development, you really have to focus on your biggest potential customer base.

Now I agree, missing Normal Mode is going to be a problem for some and I *think* it's removal was just a business decision that was judged to be in the best interests of the platform. I'm sure there are a variety of both technical and strategic reasons for the decision, but that's the decision the product team came to.

However, there is a solution for the scenario that you described. In fact, I am of the opinion that it is even easier for *new* users to build real-world Flash projects now. We can just agree to disagree on that one.

Regarding ActionScript 2.0
I think there's been some misunderstanding here as well. First of all, you absolutely can - and should - use the built-in ActionScript editor for writing AS2 code. I don't know how you got the impression that you couldn't. Now, *can* you write your code in external AS files and even venture into using Classes? Absolutely, but that's only a small piece of what's new in AS2. Nothing's changed as far as where you use it, just how you use it. You can still construct your scripts the same way you did with AS1, only now you have a lot more programmer-friendly capabilities like improvements in variable typing, event handling, etc.

Also, there is nothing that you can't do with ActionScript 2.0 in Flash MX 2004 that you can in Flash MX Professional 2004. The two versions are identical, except that Flash Pro has additional features and capabilities. Flash Pro has the "Screens" API, many more components, data integration, pro video capabilities, and a host of other additional "Pro" features.

I hope this helps clear things up for everyone. This is why I find it so important for me to be monitoring these threads and responding to concerns and issues.

Thanks,
MD

[FPChris]

Mike, Why did they restrict 'class' in AS2 for external scripts
only? I can think of a zillion places I'd like to code classes
that are not component related. That bummed me out a bit.

Chris

[MikeDowney]

Originally posted by FPChris
I can think of a zillion places I'd like to code classes
that are not component related.

Classes aren't limited to components.

Create your Class, save it, go to File > Publish Settings and click the "Flash" tab. Now click on "Settings" next to ActionScript 2.0. You can add the class path to the .as file here and instantiate your objects defined in the class from right within frame 1 of your FLA if you wish. It's actually pretty cool.

[MG315]

just wanted to say thanks mike for keeping up with all the questions/problems people have brought up. i gotta say this is probably the best customer support i've seen from a company (most would only respond to emails sent to tech support). You've come here, where many of the professionals reside, to help them transition from MX to MX2004, and I thank you.


anyway, this isn't really a problem, just a small annoyance. I'm working with dual monitors, and i expanded the actual flash application so it stretches across both (I tried keeping it in only one monitor for just the stage and placing the panels in the other monitor but they wouldn't dock without me extending it across both). Now whenever I open a flash file or make a new file, it expands all the way across (and only one monitor has the stage visible, the other is full with the panels). So I have to go window>hide panels, then resize the flash window and then show the panels again. Is there a way I can set it to open in one monitor (or 1/2 screen if you think of both monitors as fullscreen) as default?