I've got a VFP9 app with a number of classlibs. In one
particular classlib, when I make edits to method code and
attempt to save the changes, the editor window scrolls
slightly and all of the changes I just made disappear.

When this happens, if I close the class editor and reopen the
class, the same thing happens when making edits.

If I, instead, shutdown VFP9, restart it, open the class
and make the edits, then the changes are correctly saved.

Has anyone seen this before? What causes it? What's the
workaround? It's frustrating to make a bunch of changes and
have them wiped out when trying to save them.

-- TRW
_______________________________________
t i m . w i t o r t
_______________________________________

--- news://freenews.netfront.net/ - complaints: news (AT) netfront (DOT) net ---

Sounds like you're working in Vista or Win7 and virtualization is
hitting you.

Dan

Tim Witort wrote :

Dan Freeman seemed to utter in news:ih5os3$svp$1 (AT) news (DOT) eternal-september.org:

This is being developed in XP Pro SP3. No virtualization
going on here. Also, this "disappearing changes" thing
doesn't happen after restarting VFP. It seems that upon
initial startup of VFP, the edits to the method code stay
when saving. But after running the form that contains an
instance of the class then closing the form, that's when
the method code changes don't stick.

Maybe I should try doing a CLEAR ALL after running the form
to see if something is in memory that is preventing the
change. Maybe some reference to an instance of the
class that was not released when the form closed?

-- TRW
_______________________________________
t i m . w i t o r t
_______________________________________

--- news://freenews.netfront.net/ - complaints: news (AT) netfront (DOT) net ---

Tim Witort seemed to utter in
news:Xns9E729EE505D95timwitortwrotethis (AT) 202 (DOT) 177.16.121:

Just played around with this a bit...

Doing a CLEAR ALL after running the form in question resulted
in subsequent edits of class method code to stay in place.

I examined memory before and after running the form to see if
some residual object reference was causing this... nothing.

I made a copy of the form in question and removed all the controls
from it and ran it. Still caused the disappearing code changes.

The form had no controls on it and no code that ran on
startup, so I was wondering what could possibly be causing
the odd editing glitch. The only thing left on the form
was a single free table that was being loaded in the DE.
I removed that, and voila! Running the form no longer resulted
in method code changes not being saved.

So I went back to the original form and removed the
free table from the DE and got the same result. Running
this form no longer causes the code changes to be undone
when saving.

Why the heck having a single free table in the Data Environment
would cause this makes no sense at all to me. I've worked
around it, but it's a bit disconcerting.

-- TRW
_______________________________________
t i m . w i t o r t
_______________________________________

--- news://freenews.netfront.net/ - complaints: news (AT) netfront (DOT) net ---

Tim Witort presented the following explanation :
I've never seen these symptoms before. Something else is in play.

Dan

Tim Witort brought next idea :
One thing that *might* cause your symptoms is being SUSPENDed, as in
the case of an error.

VFP can't save because the form is still open/running (technically).

What happens if you CANCEL before editing?

Dan