Losing code saved in form methods

[JoeyDC]

Has anyone else experienced this? I have a form that I am trying to get it to do exactly what I want it to do. So I make lots of changes to it trying out various ways to accomplish what I want. After I change something in the form designer, I run the form. A dialog box asks me to save the form. I answer "yes." The form runs. I come back to the designer to check my code. My changes are no longer there. WHY? The .scx and .sct files are dated the same. Both are filed in the proper folder. This just started in the past few days but it's beginning top happen often.

If I had hair, I'd be pulling it out. Help!

 

[Olaf Doschke]

The closest thing, which happend to me is a form not having my changes only at runtime, because somehow I accidentally dragged the form into a neighbor VCX in project manager instead of openeing it with a click, therefore the class was copied and VFP used the unchanged class copy from the neighbor VCX instead of the one I edited. But in that scenario I saw my changes in the eidtor but not while debugging at runtime.

Well, first questions:

Is the readonly attribute of the SCX set?
Do you use any kind of version control/SCC?
Do you exclude VFP files from virus scanning?
Did you used process monitor to find out what's happening to the files and when (save time /start time)?

Bye, Olaf.

 

[Mike Lewis]

Joey, you asked if anyone else has seen this behaviour. I have.

I have occasionally seen exactly the behaviour you described. I can't explain it. I never found out how to recover the lost changes. It has taught be to do extra backups while I am making extensive changes to a form (or class or report).

But, more often, I've seen a behaviour which is similar to what you describe, but not exactly the same. In that case, the changed code is still present after you save the form, but it is never executed. Instead, it is the old code that gets executed, even if it has been deleted. This is a simple caching issue, and can be cured be issuing COMPILE FORM.

By the way, Olaf mentioned the possibility of the form being read-only. Unfortunately, that's not the solution. If a form is read-only, VFP won't let you make any changes to any of its methods. And if you make a change in the form designer, VFP will prompt you to save the form under a different name (this applies to VFP 9.0; I've not tried it in earlier versions).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Good point about read only, Mike. What remains is antivirus and the question about source safe or other version control software. A colleague reported it doing weird things to file attributes and contents. Virus scanners are known to cause trouble intercepting file changes.

I work with editor option to "compile before saving". That should be a good idea in your case to ensure your new code is not only saved, but also compiled and finally run.

Bye, Olaf.

 

[JoeyDC]

Thanks for your replies.
1. Read-only is not set.
2. I'm a one man operation so I don't think I need version control and don't use it.
3. I use MSIE for virus prevention, but it never was a problem before. I've used it a long time.
4. I don't know how to use process monitor.
I suspect, like Mike said, that it's a caching problem. I'll have to investigate and experiment further.

Thanks again

 

[Olaf Doschke]

Process monitor isn't that hard to use. For a developer it's self explanatory enough.

You can specify an EXE you want to monitor, for example. Or a file/folder. In this case the SCX and the SCT file would be relevant. When you start monitoring a log will fill up with events happening to these files and which process is doing something with them. You will expect VFP9.exe, but most probably also see MS Security Essentials. It's not just a guess, but a known fact Virus scanners can prevent changes to be applied to prgs, vvcxes, scxes. It started with Kaspersky, but I've seen reports from many, so I assume Kasperksy was just spotted first, because it's so widespread. It might just happen recently, though it never happened before, because your file grew or a certain signature is found within by chance. People, who reported similar problems to you also said, they didn't change their virus scanner recently, nevertheless it was the reason. What changes frequently is virus definitions, and so this thing can start happen suddenly, though you use a virus scanner for a long time already.

Bye, Olaf.

 

[craigber]

JoeyDC,

You are fooling yourself if you think you don't need version control. You've seen exactly one reason version control is useful. It helps in many other areas, such as:

- experimentation/bug fixing. Have you ever gone down a development path, making lots of changes and testing alot, only to find you need to go back three or four test versions and take a different path from there?

- rollback. What if you need to rollback to a specific version

- version control is cheap. Git and Subversion are free. An old machine can serve as your vcs server.

- provides a way to branch your development. Scenario: you do a release and start on the next version of the software. This requires major rework on a feature. Part way through, your customer finds a bug in that feature on the current release. It's easy to branch the code and fix it. Or even if the bug is in a different part of the code, version control provides a way to branch and fix bugs, add features, etc, making you feel safe you can get back to a stable version of the code. Just make sure you branch in a good way (hint: Most teams/people do it wrong).

http://www.youtube.com/watch?v=aX4nf5Co16Q

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Dan Freeman]

2. I'm a one man operation so I don't think I need version control and don't use it.

This is just plain wrong headed. Sorry.

Nobody has been a "single user" since the advent of Windows. It's WAY too easy to start a second copy of VFP and open the same SCX in both versions, trampling work being done in the other copy.

Source control is easy and free backup, easy rollback as Craig points out, and it also makes a decent change log (assuming you use check-in comments). How many times have you wondered "when did I change that?". You wouldn't have to wonder if you could look at your source control repository and find out.

 

[JoeyDC]

Gee, it's so nice to come here and get beat up. I really needed that. My wife just ain't big enough top pull it off. Thanks.

 

[Mike Lewis]

Joey,

I'm sure these guys didn't mean to "beat you up". They just wanted to suggest something they thought would help you.

OK, I agree that the language was a little strong ("plain wrong headed" ... "fooling yourself"). Slap them on the wrist for that, by all means. But don't dismiss the advice they are giving you. And don't let it put you off coming here next time you have a question or you want to contribute to a discussion.

I've had the same problem with lost code that you had. And I also have very little stuff left at the top of my head to pull out.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[craigber]

Sorry you feel offended, but that was somewhat what I wanted. I've been speaking on developer best practices for years, most recently on Version Control Branching practices, and have heard your argument over and over. The fact is, VCS, is for everyone, even the lone wolf programmer. It doesn't solve the issue of VFP losing your code, but it becomes your safety net.

I really need to follow up with the publisher I talked to earlier this year about writing a book on this and other best practices.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[TamarGranor]

FWIW, I'm also a solo developer and, like you, thought that version control was overkill for my situation. Then I saw a conference session on Mercurial and, for the first time, felt like I could have version control without it being painful.

This white paper by Rick Borup made it easy to get started:

http://www.ita-software.com/papers/Borup_Mercurial_Published.pdf

It's now a year and a half later and I find I'm keeping more and more things (like websites) in Mercurial, because the ability to go back and see what I've done is so useful.

If you go with Mercurial, I strongly recommend setting up Beyond Compare (with Frank Perez's VFP add-in) as your comparison tool.

Tamar

 

[craigber]

Good to hear Tamar. And you're finding out that everything can go in Version Control (which is why I don't call it Source Control), including design documents, meeting notes, images, mockups, conference presentations, whitepapers, etc)

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[GriffMG]

What is a design document ? B-)

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Dan Freeman]

I did say I was sorry right in my post so I say it again.

I know it's a tough message to hear. I was there (when dirt was new).

Good luck finding an answer to this. I've never seen one so I hope someday someone finds the magic pill.

 

[Olaf Doschke]

magic pill",

Well, indeed it might be the bitter pill of not doing FoxPro any more. That thought isn't that dark anymore.

Well, now I'll get beat up, perhaps. But I'd also apologize for saying "For a developer it's self explanatory enough."
If you have a detail question other than "I don't know how to use process monitor.", then I am willing to answer.

If that is just saying "I don't know how to use a software I never used", then my first answer would be: Install and start it and see for yourself. I was in the same situation once and found it not the most intuitive, but easy enough to figure out with the help of google, blogs etc. and it's online help, of course.

You could also refer to my suggestion and ask, how to monitor files or folders, if you don't find out on your own.

I can understand, that you invested some time already and your nerves are blank. The answers show you there is someone having had the same problem (Mike), but unfortunately has no easy fix. I only had a similar problem with a totally easy to understand root cause of having the same class twice in the project, that's not it, perhaps.

Most probably there isn't any easy fix, but one thing is for sure: This isn't normal VFP behavior. And so if time is of the essence, the easy and fast solution would be moving to a new computer and see if the problem persist with setting up VFP from scratch and work on your project there. You may setup a virtual machine for that matter, can reinstall XP, Vista, Win7, whatever and not activate it for the grace period MS allows. You can install VFP on a many computers you like, so you don't even have to break any license and legal issue to test that. At least that would answer that very important question if it's the computer, virus scanner, any other environmental thing, or your sources. Of course that also takes time, but you can also continue to "investigate and experiment further" in hope of finding a solution within minutes for das or weeks.

I was asking for source control, as I know this bad behavior of source safe 6, to be more specific. If you don't use it, that rules that out. Establishing source control right now won't solve anything, because you don't get your new code saved, as it seems, but would of course have helped to get back to a version of the form not having that problem. If you do backups, you might also "manually" go back, of course, and see if the problem is buried in the scx file.

Rejecting to turn off VFP file types virus scanning is rejecting a possible solution. I assume you reject that, when you it has worked before so it must continue. Let's compare that to a situation hardware doesn't work, which had worked before, for years. And so? It must continnue to work, if it worked before, mustn't it? Could we call that ill logic, perhaps?

Please, now don't get upset, but this is really shortsighted, isn't it? I don't see how that helps and how that is cooperative. Besides I only know MSIE as short for MS Internet Explorer, so what virus scanner is called MSIE?

Bye, Olaf.

 

[Mike Lewis]

I would like to say - as someone who has suffered the same problem as in the original post:

1. I am fully 100 percent in favour of version control.

2. But that in itself wouldn't have avoided the original problem. If you check out a form, modify the code, then immediately lose your changes, a version control system won't get them back for you.

3. My defence against the original problem has always been to (i) save the form often; (ii) keep an extra on-the-fly backup during the course of the day, if I am making extensive or complex changes that might be difficult to reconstruct.

4. Don't worry about it too much. The problem is rare (in my experience), and not a total disaster when it happens.

5. Repeating that I am totally in favour of version control, I can understand that it is not the answer that Joey was looking for. He wanted to know how common the problem was, and if there was any easy way of fixing it. I hope the somewhat negative tone in a couple of the replies hasn't put him off coming back and rejoining the discussion.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Koen Piller]

Hi,

Backup? Grrr VFP natively has only one simple backup procedure for .prg files (bak) back from dBaseII (i suppose)
Andy Kramek c.s. have constructed a similar backup for the other files (SCX,VCX,RPT and the like) which you can find in the '1001 Things etc' book. Printed copy not available anymore, but I believe you can still get a downloaded copy from the publisher.

This procedure, when not working under source control, has saved my live several times.

Regards,

Koen