I've been working professionally with Flash MX 2004 Pro since the day it was
released.
The way I work is:

1) open "projectname_X.fla" file
2) make changes
3) press ctrl+s to save
4) press ctrl+enter to preview
5) file...save as..."projectname_X+1.fla"

As I work I preview frequently to verify that my minor changes will work
succesfully. I've developed a habit to automatically hit ctrl+s right before I
hit ctrl+enter, so I'm always saving. I only save as the next iteration when
I've made a significant change to the file.

I've been using this method for many years with no problems. I didn't notice
any problems with Flash IDE 7.0's saving, but with 7.0.1 I've been noticing a
very big problem.

Almost every morning now, when I load up my latest revision of the file I'm
working on, I notice that some of the changes I made from the night before are
gone. It's as if I didn't even make them. So I'm forced to redo some of my work
from the previous night. It seems to be mostly changes to the ActionScript, I
don't recall if it has lost changes to anything else.

I'm not sure what's going on. But my PC is new and fully functional, so I
don't believe it to be a problem with faulty hardware. So here are my ideas:

1) For some reason after using the Flash IDE all day as I do, saving many
times and following my behavior patterns, it just simply stops saving correctly
to the local drive at some point?

2) The undo seems erratic. There was a time recently when I was moving between
many nested MCs, making changes to the graphic elements, as well as AS
scattered all over... and somehow this caused the undo to freak out... when I
would press ctrl+z it wouldn't undo the last action I did, instead it began
acting very strange and I was forced to restart Flash. I hit ctrl+z sometimes
to undo a change I made to the AS, so perhaps sometimes at the end of the day
when I hit ctrl+z it undoes more than I wanted it to, and then I save.

3) I'm going senile and am dreaming that I am working on my Flash projects,
when in fact it is just a dream. I then wake up, thinking I made progress, and
find things missing... because of course, they were only done in my mind while
I slept.

I'm not really sure what the problem is, but since this has been happening
repeatedly every morning I'm going to assume that it's not #3 (I hope!). #2 I'm
not sure, that was just a wild guess based on how the undo feature can act
funny now and then. If the problem is #1, then that is a big problem indeed.

If anyone has any ideas I'd like to hear them. I am getting tired of redoing
my work. :)

Windows XP
Flash MX 2004 Pro 7.0.1
Brand new SATA HDD
.FLA Filesize is currently 3,705KB

Thank you for your reply!

I was going to feel like a real idiot if no one knew what I was talking about.
I'll try using your suggested method.

The help file says, "When you save a document using the Save command, Flash
performs a quick save, which appends new information to the existing file. When
you save using the Save As command, Flash arranges the new information into the
file, creating a smaller file on disk."

So if you have to save to a completely new file to make sure it saves
correctly then ther might be a problem with the way it's appending the new
changes.

I also share your disappointment with the software. Although Macromedia
regained some respect with their point release upgrade, there are still many
issues that need to be worked out. But since I've been happy with Flash in the
past, I'm willing to give them an opportunity to make it up to me. I just hope
that Flash 8 is super polished, and doesn't have anymore useless fluff.

snap!
I save in the same way and have the same problem.
I work around it by saving the last copy to the desktop as a completely new
filename last thing before I stop, using save and compact.
When I start again next morning I rename the file to the last version I was
workin on and put it back in my project folder.

Seems to work ok.

(I thought I was going senile too!)
IMO: don't know how MM can charge so much for software that is so full of
bugs - it stinks!

Ed

--
nospam AT edmassey DOT co DOT uk

Yes. We aren't all crazy. The problem being that Flash doesn't write the
file exactly when asked to, but seems to buffer it and tries to save it
incrementally. I've noticed that I'll only lose ActionScript for the
frame/layer/object I've just been editing inside the 'Actions' module.

I tend to work in a similar manner as the poster when I code. I would make a
small change and test it. Maybe if I learn the debugger a little better, I
can work more efficiently. But, I fear that that's buggy also. This problem
especially hurts my productivity when I make a large change to my
ActionScript, but my code has a bug that makes it run in one of those
'infinite' loops, where it pops up that message box that will ask you to
stop running the script. When this occurs inside 'Test Movie' I usually can
press the button to stop running the script, but sometimes when I switch to
another window and when I switch back, Flash has froze and I don't have
access to the message box to press the stop the script, so I've got to 'end
process' in Task Manager, which leaves my code _unsaved_ due to the bug
outlined above.

Anyways, my workaround includes making a small change to the code in another
Frame/Layer/Object in Actions. I've experimented with making changes in
other windows that didn't really have any changes in ActionScript, which
tricks ActionScript into saving for another Frame/Layer/Object, and _really_
saves the one before that to disk.

If you have the same problem above (the one with the 'stop running script'
message box) the best way I've found to deal with it is previewing it in a
browser rather than using Control->Test Movie inside the Flash IDE.

Hope this helps someone.

Jason Reposa
http://www.reposagroup.com/

So it's not only my imagination :P Indeed I've seen this happen more than
once in MX2004 (and only there), this should be one of the most incredibly
stupid bugs I've seen - not being able to save a FLA properly and reverting
to old code :P

[quoted text, click to view]

[quoted text, click to view]

I'm using the same fix now (instead of simply save, save and compact, or
save as new file).
Maybe they are appending the new fixes but wrongly referencing old ones in
the FLA.

So if you happen to get it again by forgetting to save and compact, I
suggest opening the FLA in a HEX editor and looking for the new script
there, if they were long and big changes, might save some time.

[quoted text, click to view]

Yes, it's incredible that a software can't even save its own format properly
:P Such a shame.
I heard something about second patch coming, I personally doubt it but who
knows really...

I don't see how Flash 8 can be superpolished etc. though - unless they have
enough new shiny features to sell to newbies and Java/C++ developers,
they'll have bad sales...
Slightly ironic, given that this is their current philosophy (bloated
features, tons of bugs) and their sales ain't that good...

I think if Macromedia would do this, it can keep the sloppy programming
style and still be much better:

1. Release the first version as a public beta with a certain price discount
(so at least bugs are collected and fixed before it goes official).
2. Regular patches fixing all important known bugs and performance issues
each, say, 5-6 months, free for existing customers. Even once 8-9 months
would do if users can see a clear roadmap of the service packs.

Of course it'd be better to loose the sloppy coding though ;)

I did couple of tests (now that I see I'm not mad and imagining I do changes
and save them) and my doubts have confirmed that it has to do with the
multi-script binding feature - new to MX2004.

When you change a script, a flag is set in Flash that the script in that
frame/symbol is new and needs to be appended to the FLA on save.

However if you make the changes to a binded tab, that flag is not always
set, so flash never gets to save the changes to the FLA at all.

To avoid the save bug you have two major solutions:

A: NEVER EVER bind scripts

B: Always use "Save And Compact" or "Save As" new filename.

I'd like to ask the other users who found this bug to confirm they were in
fact using the script binding actively in the projects where the problem
occured.

I hope an MM employee is reading this.. :P

In article <c6hs3b$jun$1@forums.macromedia.com>,
webforumsuser@macromedia.com says...
[quoted text, click to view]

Sure. Have you also submitted it as a bug to the product team via the
bug/wish form? If not, please do so- they don't usually frequent the
forums:
http://www.macromedia.com/go/wish/

To be clear in regards to 'binding scripts', did you really mean
*pinned* scripts (i.e. clicking the 'pin' icon by the script's tab, so
that script stays persistent in the AS editor, regardless of the frame
you're on)? Just want to make sure everyone's talking the same
language...


-Scott

Okay, I was originally going to reply to Stan and say that I never used data
binding on this project. Data binding is a feature of the components, and I'm
not using any. But after reading Scott's post, it seems as though he is right
and you are referring to the AS editor's pinning feature.

Yes, I have edited scripts while they were pinned. Though to be honest, I've
never done it intentionally. I haven't completely figured out how the pinning
works. All I know is sometimes when I click on a frame and press F9 I'm
confused wondering why I'm not seeing the right code, then I realize that pin
icon is pinned down.

Earlier today I decided that the best solution for now would be to use JSFL to
create a command that would Save As to the same file I'm working on. Then I
could map Ctrl+S to that command, and it'd feel the same, but it'd be using
Save As rather than Save. But after spending many hours exploring the
intricacies of JSFL, I decided it wouldn't be possible to do directly.

If you Save As to the same filename, Flash automatically uses the Save method.
So I tried many workarounds. One method was to try and Save As to a temporary
filename, then Save As back to the original, but that didn't work since using
more than one Save command in one script behaved screwy. I looked at all the
commands available, and I couldn't find one that'd update the correct
information to allow it to work.

I couldn't even Save As to a temp file, close all the files, reload the temp
file, Save As to the original file, and reload it. The way it dealt with it
required the script to execute first, using only 1 File Saving command before
it'd refresh everything.

So instead I scrapped that idea and used a different approach. I've created
three scripts.

[L=http://www.kauldron.com/source/]http://www.kauldron.com/source/[/L]

1) Save as current version

This script will use the Save As method as far as I can tell. Here's how it
works... Let's say you start a new file and add a few things, you then select
this command and it pops up the Save As dialog as it normally would if you hit
Save. You save to a file called, "superman.com.fla". Okay, now you add a little
drawing of superman, and then you hit this command again and it automatically
saves to, "superman.com_001_a.fla". Then you realize his cape was blue, so you
change it to red, and hit the command again, and now you are automatically
saved to, "superman.com_001_b.fla". If you save again it will be back to _a,
and so on. By saving between these two files, _a/_b, it seems to use the Save
As method instead of Save. So a new file will be written, it will have a
smaller filesize if you deleted something from your movie, and it shouldn't
lose data from the bug like Save does.

2) Save as current version then preview

Same as above, except after saving it will automatically preview your new file

3) Save as next version

The first script is used to save minor changes as you work, to make sure you
don't lose them. But this script is handy for saving big changes. Let's say I'm
done drawing my superman, and have now animated him flying around. This is a
pretty big change, so I run this command, and my file that once said,
"superman.com_001_b.fla", is now saved as, "superman.com_002.fla". I'm now
ready to close Flash and go to sleep, in the morning I can load up 002, and
start using the first command as I make small changes.


I haven't used these scripts in a production environment yet. But I've tested
them out and fixed any bugs I found. If someone finds them useful, I suggest
that you first test them on temporary files before applying them to your
important material. If they somehow mess up and you lose data, I don't want to
be responsible.

I used 3 digit numbering so that it can be used for 999 versions. If this
isn't ridiculous enough, after you reach 1000 it will append _001 to 1000 and
start all over again. :) If you prefer 2 digits the script is easy enough to
modify to do just that.

After you copy the .jsfl files into your Commands directory they will show up
in the Commands menu. Then if you go into your Keyboard Shortcuts you can
change your Ctrl+S shortcut to run the, "Save as current version", and maybe
change Ctrl+Enter to, "Save as current version then preview".

A few notes about using the commands... After saving with them, the * next to
the filename doesn't disappear. So it looks like you didn't save, but if you
close the file and re-open it then you can see that it did save. Also, make
sure you save using the command before you close Flash. When you close Flash it
will then warn you about not saving, and you should click no to keep it from
appending to the file. As long as you saved before exiting then there's no data
loss.

I'll be using this setup for working on my projects, so if there are any
problems I'll probably find them and I'll upload revised versions of the JSFL
files.

If anyone knows of a way to use Save As to save to the same file you are
working on using JSFL, then I'd be interested to know. That might be a cleaner
approach than alternating between _a and _b.

Assuming Save As isn't affected by the bug, and that these scripts I made are
truly using Save As, then I should be able to hit Ctrl+S like normal, without
consciously going out of my way to work around the bug.

Sometimes I wonder if the reason why Macromedia decided to create JSFL was so
that they could rely on the users to build work arounds for bugs, or things
they left out. :)

[quoted text, click to view]

Well binding - pinning ;) Hehe, sorry. Pinning indeed.

BTW, Mike Chambers let us know on the figleaf maillists MM knows about the
issue and will fix it in the next update.
So at least they know and we can be calm they've fixed it. It's only matter
of telling your friends and partners who use MX2004 to be carefull with it
until then (because if you don't know, it you'll think you're going nuts,
and having to redo lots of work).

Thanks very much for the scripts! I personally would check them out
immediately.

Sorry, terms messed up ;)

Pinning indeed.

[quoted text, click to view]

In article <c6l3k7$4uq$1@forums.macromedia.com>,
webforumsuser@macromedia.com says...
[quoted text, click to view]

Cool- that's what I suspected. And yes, I've seen this happen myself-
many times, in fact. ;)

Dear all,
This bug is a big problem for me. It's really a nuisance to move around mc without pinning the scripts in a large progect!

Dear All,

We've got the same problem at work, we all thought we were going mad!! It's
good to know we're not alone but it doesn't solve the potential problem that
any files already created and saved (ctrl-s) may fall back to older versions if
we need to revise something as simple as a text change!!!

We're working on a massive e-learning project, loading separate screen swfs
into an interface and the potential for lost time on this project because of
this issue is vast.

What we'd like to hear on this thread is a response from Macromedia
apologizing for the fact that this bug made it through the testing to a release
version plus a timescale stating how and when they'll be dealing with this
issue.


Bourne Training

There used to be a similar issue with versions 4 and 5 of Flash when they were
released. Back then, I used to find very often that when working on a file and
saving, it would save as an empty 0k file and I'd lose everything. I ended up
saving each significant change to a new numbered file.

Just thought I'd put my 5p's worth in.

In late April I created some JSFL scripts that would prevent data loss when
saving .fla files within MX2004 Pro. After testing it in a production
environment for about a month, I decided to package it according to Macromedia
specs and get it up on the Flash Exchange in an effort to help all the other
developers out there who were suffering data loss.

On May 22nd, 2004 I spent a considerable amount of time modifying the script
and its packaging in order to adhere to the Exchange guidelines. I then
submitted it to Macromedia Exchange using the quickest method of QA testing,
which I believe said it'd take around 2 weeks to be posted.

Two months later I received an e-mail about a bug that wasn't a bug. After
explaining why it wasn''t a bug, the exchange item was finally approved by QA
and was posted to the Exchange today.

I would like to apologize for Macromedias huge delay in posting these scripts.
My intentions were to help the community by providing a fix for an incredible
bug. I was able to help myself, since I've been using these JSFL scripts for 3
months now and have created many projects without any data loss. But
unfortunately for the public my efforts won't do much good. The reason is
because on July 26th, 2 days ago, the Flash MX2004 7.2 was released. This
includes the fix for the save bug:

"79819 : File Save loses actionscript changes when script navigator was used."

A fellow developer and I discussed how there would be no way Macromedia
would've accepted my Exchange Item, since it would be admitting to having such
a huge bug. After the estimated 2 weeks or whatever period of time it was
supposed to take to approve an Exchange item, I told him that Macromedia was
playing a game. I said that they wouldn't outright deny my Item, since there
was no technical reason why they could. So instead their plan would be to delay
the approval until after they released Ellipsis, thus rendering my efforts
completely useless. While I'm unsure of any conscious planning to do this, this
is exactly what happened.

So the JSFL files are now useless. I will use this as a learning experience. I
now know never to submit anything through the official Macromedia channels.
They are slow and mucky with the stench of corporate waste.


http://www.macromedia.com/cfusion/exchange/index.cfm#view=sn111&viewName=Flash%2
0Extension&loc=en_us&authorid=0&page=0&scrollPos=0&subcatid=0&snid=sn111&itemnum
ber=-1&extid=1015083&catid=0

http://www.macromedia.com/software/flash/special/7_2updater/

We certainly apologize for the unfortunate timing, but I can assure you that
Macromedia did not intentionally keep your scripts off the Exchange.
Macromedia has been very forthcoming about bugs and issues relating to Flash MX
2004, and therefore would have nothing to gain by delaying the release of your
work. The reality is that the people who review projects for the Exchange are
often very backed up, and sometimes can't turn them around during the estimated
two-week time period.

Christian