What happened to my PRG???

[dmusicant]

I have a PRG I use daily (probably averaging over 1/2 dozen times daily) that's over 3500 lines. Yesterday, it stopped working. Today I see that the program had shrunk to under 2900 lines, it seems some subroutines were simply not there after mid-morning yesterday (when Windows said the program was last modified). Today, I had the time to look into it. VFP 9 had recompiled the program (well, I assume it was VFP, what else could have done it?) and parts of it were not found, well, a particular procedure within it (that was the error: <procedure buildcomm not found>). Fortunately I had backed up the PRG and I restored it. I had not modified the program. Other errors may well have happened besides not being able to execute the call to procedure buildcomm, but it broke on that call.

I do have a compiled version (EXE), but I don't ordinarily run it, I run VFP 9.0 and the PRG within that. I certainly did not open nor modify the program yesterday. What could have caused this head scratcher?

Dan

 

[Mike Lewis]

Dan,

Just to be clear: Are you sure it was the PRG that has been damaged, not the FXP? The PRG is the source program - the one that you edit and which contains the actual program commands. The FXP is the compiled version - the binary file that VFP actually executes (my apoligies if this is stating the obvious).

If it is the PRG, then you will be aware that the compilation process does not alter this file in any way. The only way it can be altered in VFP would be if you opened it in an editing window and made the changes yourself. It's conceivable that some rogue process, or perhaps even a virus, has mucked it up in some way, but that seems unlikely.

In other words, I can't think of anything that might have caused the problem you are seeing. Let's hope it was a one-off situation. But if it happens regularly, I can only suggest that you make the file read-only. That way, you might at least see an error-message the next time it happens, and that might help you track down the cause.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dmusicant]

Thanks, Mike. Actually, the first thing I did when the problem came up and persisted was open the PRG and search for "buildcomm" -- there was only one instance, being the call. I didn't remember for sure if I'd put procedure buildcomm in the PRG itself, it was conceivable that it was in a procedure file. A look at my last saved version of the PRG revealed that indeed PROCEDURE buildcomm was written into the PRG. It simply had been deleted from the current version, which showed a modification date of yesterday morning. I had NOT opened, much less modified the file. It's a total mystery to me. I've been using various versions of FoxPro since the 2.6 days and never seen anything like this happen. Yes, the notion that the problem was caused by a virus occurred to me today. Seems unlikely, but what does??? Fortunately, I make a habit of backing up my source code and data on a fairly regular basis.

 

[Dan Freeman]

Since you mention the line count being reduced I suspect we can assume something happened to the PRG itself and not some compiled form of it.

Note that PRG is one of those extensions that some anti-virus programs mess with, but that should only be an issue if the prg itself is being written -- i.e. if you've changed something and you're saving the result. The only time VFP writes anything to a PRG file is when it is being saved.

But just for a point of clarity: VFP *never* runs a PRG directly. Even if you open a PRG and click the RUN button on the toolbar, VFP compiles the program and runs the compiled version. (Even if it does this entirely in memory, it is never running the PRG directly.)

Also, 3500 lines in a single PRG for why? We had those monsters in the FoxBase+ days when the product shipped with a program called FoxBind.com that was provided to combine multiple PRGs into one for compiling. But since then, not so much.

 

[Mike Lewis]

It seems particularly odd that it was a specific procedure that was deleted. If it was a virus or some other rogue process, you'd expect any modification to be random in nature.

It's a puzzle, right enough.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

If you are backing up the source regularly, do you have any oher versions which don't have that procedure in them?

Regards

Griff
Keep [Smile]ing

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

 

[NasibKalsi]

It may be user has hit Esc char repeatedly to stop the process and/or error arrived and somehow user deleted this by mistake.

 

[dmusicant]

I'm looking at the code right now. The mysteriously altered PRG was truncated to 2904 lines. The last line is:

RETU

All my procedures end with:

RETURN

Of course, Foxpro in many circumstances provides the "RN"

In the unaltered version of the PRG that line is:

RETURN && changttl

That procedure has only 5 lines, one of them a comment, it's FUNCTION changttl

The entire unchanged PRG is 3711 lines.

To explain Dan Freeman's question about why this PRG is so long. Well, it started as the most modest of programs. I was working at Micromega Systems, their support specialist for Foxfire! report writer at the time (about 1998 or so). I used to do a lot of command window stuff and I wrote a tiny PRG to run to save me a few seconds. It incrementally increased over time. It searched a table where we kept support issues for the program. I built in the capability to search other tables. Then I built in a sort or organizing principle, where the tables could be grouped. On top of that I built in maintenance functions such as the ability to create or change tables. It took on a life of its own. There's a screen and the PRG, some tables that are metadata. The PRG includes all the subroutines except for some that are embedded in the screen, which is written in FPW 2.6a for Windows. The search functionality lets me search for up to 3 strings (usually I just search on one or two), in an all or any basis, my choice. I pick a table, then enter the string(s) to search on and am returned a filtered version of a table, or if one hit, I'm in the memo field that contains the string(s). It's an information management system, basically, and I use it a ton.

Well, looking, I count 10 subroutines that were mysteriously deleted from the PRG, including PROCEDURE buildcomm, the one the program broke on.

 

[Olaf Doschke]

Indeed VFP does not error on commands abbreviated to aat least 4 letters, with the only exception of LOCA, because it could mean LOCATE or LOCAL.

If your PRG was truncated on line 2904 and the 10 missing subroutines are in further lines, this truncation can simply be due to VFP choking on writing a change to the PRG. It's a good thing to have backups and in case you directly detect that truncation it's good to set the option to create BAK files for each PRG change.

Could also have been a HDD or OS moment. VFP does not write changes to PRG, it rewrites the whole file and of course when that is interrupted you get a truncated PRG. If that truncation happens at such a line, you don't even get a compile error, as ENDPROC or ENDFUNC are optional and RETU is sufficient to comppile to RETURN.

So while that is a weird case, it could happen to anyone at any time. Nothing is 100% reliable all the time, not even storage to SSD.

Bye, Olaf.

 

[dmusicant]

Indeed VFP does not error on commands abbreviated to aat least 4 letters, with the only exception of LOCA, because it could mean LOCATE or LOCAL.

If your PRG was truncated on line 2904 and the 10 missing subroutines are in further lines, this truncation can simply be due to VFP choking on writing a change to the PRG. It's a good thing to have backups and in case you directly detect that truncation it's good to set the option to create BAK files for each PRG change.

Could also have been a HDD or OS moment. VFP does not write changes to PRG, it rewrites the whole file and of course when that is interrupted you get a truncated PRG. If that truncation happens at such a line, you don't even get a compile error, as ENDPROC or ENDFUNC are optional and RETU is sufficient to comppile to RETURN.

So while that is a weird case, it could happen to anyone at any time. Nothing is 100% reliable all the time, not even storage to SSD.

Bye, Olaf.

Hmm, I'm not seeing a way to edit one of my previous posts. Am I missing something or is that not supported here?

An OS moment, well conceivably. I keep my programs and data on a USB connected 2TB HD that's attached to my server machine. The server machine is running Windows XP, it's a laptop. What the problem occurred, access was wirelessly. The data is on the same USB HD. Performance is not stellar, but not too bad usually.

There should have been nothing trying to change that PRG. I have no code that does that. However, I suppose VFP does check the PRG for changes before trying to run the compiled version (i.e. the FXP). Maybe something squirrely happened at that point.

 

[Mike Lewis]

Hmm, I'm not seeing a way to edit one of my previous posts. Am I missing something or is that not supported here?

No, editing is not available here. You need to get into the habit of reading your posts carefully before you hit the Submit button. You can also use the Preview button to see how the formatting comes out. But once it's posted, it's posted.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

DMusicant - I think Dan's question was why all that was in a single PRG. It's more common to use a bunch of different files. I prefer one routine per PRG, as do many others. Forms are in their own files, and so forth.

Tamar

 

[dmusicant]

DMusicant - I think Dan's question was why all that was in a single PRG. It's more common to use a bunch of different files. I prefer one routine per PRG, as do many others. Forms are in their own files, and so forth.

Tamar

Thank you, Tamar. Well, there are probably dozens of functions that are called. Some of the functions are just a line or two, some are hundreds of lines. If I had a separate file for each one I'd have to open the file to have a look at it or change it. Having them all in one place (except for the screen code) makes it easy to get to the procedural code just using the search function while editing the main function, of which the others are subroutines. I suppose it's unorthodox to do so, but isn't it easier the way I'm doing it? Or am I missing something?

 

[Olaf Doschke]

No, I think a prg with many functions or procedures is just fine for the reason of editing all in one file. You also can't prevent a similar bundling of methods inside of DEFINE CLASS...ENDDEFINE. The Document view also gives you a nice list of procedure/fucntion/classes/methods and you're there in a click.

Aside of that ideology question the truncation of the PRG must have happened at any incidence of you editing it. As Mike pointed out the ccompiling of a prg merely reads it.

The PRG could have been damage for quite a while without noticing, if you don't recompile all, the FXP might have included the now missing function until you made another change. It's a bad choice to work via Wifi. I do modify projects located in the LAN, but only wired LAN. Even pure txt file writing can be interrupted and truncate through Wifi, and then a file ands at the stage it was, when an outage happened.

You're safe from harm, even not with pure text files. That's the way it is.

Bye, Olaf.

 

[Dan Freeman]

You should put each individual PRG in a project and use that as a portal into the code. It isn't any easier either way, but when everything is in one file the whole thing is mucked up when one little thing happens to the whole (as you've just experienced).

There are times, mostly related to call stack precedence, when having functions all in one file for a specific procedure is actually needed. But most of the time, it's just an unwieldy block of code to drag around. But if you're going to have everything in one file, do yourself a favor and familiarize yourself with the document view for jumping around the whole blob.

Personally, I distrust code that doesn't fit completely on a single screen. I'll accept (grudgingly) a PGDN or PGUP, but not more than one or two. When I see that much code in one place I start wondering about unnecessary complexity or a lack of organization and it distracts me from the task at hand.

Just my opinion.

 

[dmusicant]

Dan, I'll have to check out document view. At the time I started this, now a mighty tree (but at the beginning it was a mere seed), I was (as I said) the support specialist for Foxfire! Report Writer, working in the offices of Micromega Systems in Corte Madera, CA. I never met the original developers (they departed just before I was brought on board by Chick Bornheim), but did have a conversation by phone with the principal coder one day, Barry Chertov, IIRC (the conversation was nothing deep). Foxfire! FoxPro code is split off into individual PRGs, a great many, some very very tiny indeed. However, some of the bigger PRGs are absolutely huge. So, I had no aversion to working with even huge PRGs. Some of you may have had your noses in Foxfire! code, I don't think it is now AFAIK, but the developer version back in the late 1990's was supplied with the source code and developers were free to modify the code (subject to certain restrictions, I suppose) and recompile the entire application. I have done a fair bit of that myself.

 

[dmusicant]

Although I have a project for this and have created an EXE for it, I don't normally use the project because the entire thing is composed of

1. one PRG with internal functions and procedures
2. one screen, with embedded code
3. many tables of metadata (around 30)
4. many searchable tables (about 385 right now)
5. some of the tables have an associated PRG that usually resides in the same folder as the table. That PRG runs (unless flagged not to run) after the table is accessed. Those PRGs are custom created at my discretion, their existence and location are stored in metadata, indicated and accessible from the screen.