COPY FILE in an Exe

[Steve Meyerson]

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

 

[Chriss Miller]

Have you closed VFP before running the EXE?

 

[igorsandler]

It is open, has to be. Check Task Manager. What is .scx anyway?

 

[Steve Meyerson]

Yes. I even checked Process & Services in the Task Manager for "Stocks.." or "MicrosoftVisua..". Nothing.

I even copy/pasted Stocks.scx to my backup folder while the exe was running. It copied ok. So that indicates it was not open.

I put it in a TRY/CATCH/ENDTRY. Still wouldnt copy but at least no message,

 

[Steve Meyerson]

Igor,

.scx is the extension of a form's file name. It's normally accompanied by a .sct file which has the same stem of the form's file name, but having .sct as its extension. I think the .sct file is like a 'memo' file. Both are really same structure as dbf/dbt files.

Clear? (as mud?)

 

[Chriss Miller]

I think it is because within the EXE the stock.scx will be referring to the running scx that's within the EXE.

I tried a reproduction of the problem and succeeded.
In a main.scx form I put a button that has this in its click:

Copy File another.scx To backup\another.scx
Copy File another.sct To backup\another.sct
Copy File some.scx to backup\some.scx
Copy File some.sct to backup\some.sct
Copy File main.scx to backup\main.scx
Copy File main.sct to backup\main.sct

Well, and as you can guess from that code I also have some.scx and another.scx in the project:

As you can see another.scx is excluded from the exe building, some.scx is included and main.scx is the main form. I made it modal, too and have no main.prg, for having these three different things.

After building, closing VFP and running the EXE I ge the same error for main.scx - "File is Open" in the line that copies the main.scx

And then I saw this in the folder:

It turns out that's still neither a new VFP bug nor a new Windows feature hindering VFP from working, it is due to a cloud storage I use with a sync feature for the whole tek-tips directory.

Anyway, I can also get the same error (FIle is open error, not the conflicted in the file name) when I wait for the sync to have finished and it's due to VFP referring to the main.scx within the EXE as it's searched and found first there.

As continuation of the experiment I did change some.scx and another.scx to have a label - the original scxes were just empty forms. I now did not rebuild the exe, so it's internal some.scx is still empty, the external some.scx has a label. there is no internal another.scx, only the external one. Now restarting the exe I still get the same error - didn't expect anything else.

But looking into the backup folder I see another.scx has the new label in it - it was overwritten from the changed original file. The some.scx that's included in the EXE without label can be found in the backup unchanged, so the internal some.scx is copied. The external some.scx was not copied over. Actually the some.scx and sct also were overwritten (safety messages popped up, whether I want to overwrite and I confirmed all 4 of them with yes). But the some.scx/sct were overwritten with the same old unlabeled some.scx form the files that still exist in the EXE as I didn't rebuilt it, the changed some.scx ws not copied.

So, in short: When using COPY FILE you don't necessarily copy files as found on disk, you also - and with priority if found inside the EXE - copy files from within the EXE.

I remembered this did not effect all file related commands and thought only FILETOSTR() could read from inside the exe, besides image files I told about in a not so recent thread are also taken from inside an exe from image controls picture properties. Anyway, it's obviously also effecting COPY FILE.

So to not copy from within your backup tool EXE you either use Windows API functions like MoveFileEx instead of VFPs COPY FILE or you ensure whatever you want to copy has no name as can also be found in your EXE.

 

[Steve Meyerson]

When using COPY FILE you don't necessarily copy files as found on disk, you also - and with priority if found inside the EXE - copy files from within the EXE.,

That explains it! I guess the file itself is actually inside the exe (or at least VFP treats it as such).

The example you created duplicates nearly exactly what I actually have, i.e. I have another scx (not the Main) which is not active during backup. It copies fine in the exe. I suppose if it were active it would also not copy.

I guess I had not run into this before. In any case, I don't distribute this app so I can back up the file manually or rely on my Acronis timed (once a day) backup. I figured it was just more convenient to do it in one click in my program.

Thanks Chris for your help. And also for your insight and expertise!

Steve

 

[Steve Meyerson]

Chris - FYI

The project files (pjx/pjt) copied fine in the exe!

Steve

 

[EinTerraner]

SCX and SCT-Files are actually same like a DBF and its FPT.
You can access those FORM-Files like any table

USE Stock.SCX alias CopyStock in 0 shared again
COPY TO <YourDestination>.SCX
USE IN SELECT CopyStock

 

[Steve Meyerson]

Ein,

Tried it in exe with all else closed. First line gives "File is in use." message.

Just realized you were probably addressing Igors post.

Steve

 

[Chriss Miller]

Chris - FYI

The project files (pjx/pjt) copied fine in the exe!

Steve

You closed VFP, didn't you? So? No surprise. The PJX/PJT files don't go into an EXE, they just organize all files within the project - but themselves.

Just like skin contains all tissue, organs and bones making up a human, but doesn't contain itself (unless you're picky and say the outer skin layers contain the inner ones - yes, of course).

PJX/PJT are even less than a physical container, they just maintain a list of project item files - not themselves, though. But you don't find the actual SCX/SCT in them, these form files are still separate files.

So you could also say the EXE becomes the PJX, just that the EXE is a real container, all the project itmes that are not set to excluded are actually put into the EXE file and are physically in it, the EXE becomes a physical container, like a ZIP, just that files are not compressed in it.

The inclusion or exclusion is set by sensible defaults. Forms, programs, all project itmes related to code are by default not excluded (so included), data files are excluded as normally you would like to modify data with your exe and couldn't, if it was included and thus would become static and read only. You can indeed also set dbfs included, but then could only read data from it.

Since the pjx/pjt are not themselves project items, you even don't have the chance of including them in a build into the EXE. they always remain separate files.

During a VFP session modifying a project the PJX/PJT files are open exclusive, that's when you can't copy them. But that's a totlaly different reason. Maybe you remeber having that difficulty. But it's erroring different, you don't just get "file is in use" error about that.

For files within an EXE you only get the "is in use" error. For the stock.scx as it's running and therefore in use. You can copy files from within an EXE that are not in use currently. You observed that yourself, as you said:

Steve Meyerson: "I have another scx (not the Main) which is not active during backup. It copies fine in the exe. I suppose if it were active it would also not copy."

So VFP treats included files as it would treat excluded files: Errors arise depending on their used or exclusively opened state. The problem that arises is not the containment within an EXE, the problem that arises is due to prioritizing finding files in an EXE first (even if you specify them with a path clearly outside the EXE) VFP looks at the included files of the EXE only, then, it overlooks outside files of the same name. Window API functions don't have that point of view and couldn't even look inside a VFP exe to see files in it, that's all just VFP internal.

PJX files are just a table, too, with those specific file extensions. There's one help topic "spilling the beans" that almost all VFP specific files for anything are just DBF tables. The topic describing the DBF file structure: "Table File Structure (.dbc, .dbf, .frx, .lbx, .mnx, .pjx, .scx, .vcx)" So all these are DBFs and their partner files (typically with t instead of x) are the FTP files of a DBF.

Each has their specific field schema and specific records for specific parts, and some of that is also described. For example, there are reports that print out how frx/frt report tables are structured and what data in their fileds means.

 

[Chriss Miller]

I don't distribute this app so I can back up the file manually or rely on my Acronis timed (once a day) backup. I figured it was just more convenient to do it in one click in my program.

That indicates you have this feature not for backup of data, but of the whole project itself. Why? Self backup is nothing with a big virtue, is it? You could make one backup exe that could make backups of all you projects, or even just a batch/cmd file doing that. Obviously best done when you closed VFP. Why the hassle of self backup?

There's even a good reason to not self backup, even if you conveniently go through all _vfp.activeproject.items collection to backup each item and thus have a general backup routine for all projects inside each project: Project directories (at least for me and I guess also for you) also contain files you don't add to the pjx. I typically have pjx outside a project folder containing all project items and more and thus could easily just copy that project folder with all its content - even from within a VFP session having that PJX open, curently. Because the PJX is not in that project folder itself, as most do it.

But even then backing up the project folders is easiest done with an xcopy or robocopy also recursively copying subfolders. Besides I already mentioned most cloud drives have a syncing application that starts with your computer and when you maintain all your projects in one root folder that's all you need to configure to backup with sync to a cloud drive.