f



Method edits disappear on save

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@netfront.net ---
0
tim_witort
1/18/2011 7:12:44 PM
comp.databases.xbase.fox 802 articles. 0 followers. Post Follow

5 Replies
306 Views

Similar Articles

[PageSpeed] 21

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

Dan

Tim Witort wrote :
> 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@netfront.net ---


0
Dan
1/19/2011 4:21:11 AM
Dan Freeman seemed to utter in news:ih5os3$svp$1@news.eternal-september.org:

> Sounds like you're working in Vista or Win7 and virtualization is 
> hitting you.
> 
> Dan
> 
> Tim Witort wrote :
>> 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@netfront.net ---
> 

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@netfront.net ---
0
tim_witort
1/19/2011 11:35:52 PM
Tim Witort seemed to utter in
news:Xns9E729EE505D95timwitortwrotethis@202.177.16.121: 

> Dan Freeman seemed to utter in
> news:ih5os3$svp$1@news.eternal-september.org: 
> 
>> Sounds like you're working in Vista or Win7 and virtualization is 
>> hitting you.
>> 
>> Dan
>> 
>> Tim Witort wrote :
>>> 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@netfront.net ---
>> 
> 
> 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@netfront.net ---
> 

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@netfront.net ---
0
tim_witort
1/20/2011 12:25:09 AM
Tim Witort presented the following explanation :
> Tim Witort seemed to utter in
> news:Xns9E729EE505D95timwitortwrotethis@202.177.16.121: 
>
>> Dan Freeman seemed to utter in
>> news:ih5os3$svp$1@news.eternal-september.org: 
>> 
>>> Sounds like you're working in Vista or Win7 and virtualization is 
>>> hitting you.
>>> 
>>> Dan
>>> 
>>> Tim Witort wrote :
>>>> 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@netfront.net ---
>>> 
>> 
>> 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@netfront.net ---
>> 
>
> 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@netfront.net ---

I've never seen these symptoms before. Something else is in play.

Dan


0
Dan
1/20/2011 4:46:20 AM
Tim Witort brought next idea :
> Tim Witort seemed to utter in
> news:Xns9E729EE505D95timwitortwrotethis@202.177.16.121: 
>
>> Dan Freeman seemed to utter in
>> news:ih5os3$svp$1@news.eternal-september.org: 
>> 
>>> Sounds like you're working in Vista or Win7 and virtualization is 
>>> hitting you.
>>> 
>>> Dan
>>> 
>>> Tim Witort wrote :
>>>> 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@netfront.net ---
>>> 
>> 
>> 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@netfront.net ---
>> 
>
> 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@netfront.net ---

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


0
Dan
1/20/2011 4:48:20 AM
Reply: