Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

COPY FILE in an Exe

Steve Meyerson

Programmer
Sep 17, 2020
339
US
I created a backup method using COPY FILE within the main form (Stock.scx/sct) of the project.

It will not copy Stock.scx because it is open of course.

But when I build the exe, close the project, quit VFP, and run the exe, it copies other files, but still will not copy Stock.scx. Msg: "File in Use"

Everything's in the same folder but I would think running the backup in the exe should copy the scx anyway because Stock.scx is on the hard drive, but NOT open.

What am I not seeing? Anyone?

Steve
 
There is one way to let VFP look away from the EXE content: File skeletons like *.*. VFP won't take that as concrete file name, of course, and not prioritize all files within the EXE over all files outside.

What remains is the question why a backup mechanism included in an EXE backing up it's own project would have any advantage over any other backup mechanism? Once VFP or just the project you build is closed, no file of it is open exclusive, nor is it open shared and you don't have any advantage of copying files with VFP over any other file copy mechanism you can use.

I mean for exclusively open files the only process that can copy its content is the process having that exclusive file access, but you see VFP even sabotages itself even only with scx open shared when they run.

I see wOOdy posted that you can do it, but the main ingredient is not having the full path but the * in the filename.
 
Woody,

Thanks, but it doesn't work because, as Chris said (in effect), that file is open in the exe no matter where it is physically located.

Steve
 
why a backup mechanism included in an EXE backing up it's own project would have any advantage over any other backup mechanism?
It really doesn't. The only reason I did it that way was to write a simple, quick method to back up immediately after a change in the project and continue working on the project without delay. I guess I might be saving only a click or 2 if I had another app of some kind handy.

Steve
 
to back up immediately after a change in the project and continue working on the project without delay.
Why would the exe serve that purpose? ou can have a prg inside the project you have at hand in the project manager and can run with the ! icon of the standard toolbar. Exlcuded from being built into the EXE, too.

If I'm programming I don't usually have the exe of the project running. I run the project sources during development.

If you're after live backups of anything you change look into creating a project hook and using its QueryModifyFile. There you can make a backup of the state before you modfiy it. I know, that's not after you made the change, but then you have a list of changed files and can backup them as aftermath, data driven.
And/or use the AfterBuild event and make your backup there.

Besides such backups are essentially source control and you use the source control mechanism foreseen for that.
 
As I said, it was a quick, simple way of saving files. Maybe not the best. If I were distributing this particular program, I would back up differently (if at all) as I have in other apps, but no one else will be running this one. Ok?

Steve
 
Okay, still the perfect solution for backing up a project right after build is the project hook AfterBuild event, not putting it into the EXE just because you use the "Run after build" option. The BeforeBuild may even be better, as it could save the state in case the build itself goes wrong and corrupts one of the project files. Plus iterating all project files you can see whether some of them are still open, because that's also problematic for the build itself. Or from the other persepctive: In the normal case you'll ensure everything is closed before you build and that's the perfect time to backup.

The exe is a strange place to backup, I would have been even stronger about it, if I wouldn't have noticed you're talking about a project you only do for yourself. A customer of a software would not benefit from such a backup inside the exe, as he'd not get the sources, just the EXE anyway.

There could be more misunderstandings underlying. Well, let's just say I hope you don't think that copying a running form - if it would work - would save its current state with all the data it displays (like stock data). It'll just backup the form as it is in the project. The saveasclass method could do part of that. Just saying, as it's clearly not what you're after but just the backup of your development. Well, bad idea, just put it away.
 
Last edited:
Chris,
True & true.
I guess I had never experienced before a need to copy or manipulate a disk file with the same name as one in the exe either in my own or in my distributed apps. Probably won't do it again. :(

BTW years ago I wrote a backup program in FP for almost all files in many directories on disk. Took a while to write, but took FOREVER to copy all the files. Gave up on that!

Steve
 

Part and Inventory Search

Sponsor

Back
Top