Is not a Visual Foxpro .exe file

[AndrewMozley]

I have a VFP application which has been running both on my development machine (DEV) and on another machine (USR) in my office (as well as on user’s sites at different locations).

From time to time I transfer the latest version acct.exe onto my other USR machine. I do this using a USB memory stick.

On machine USR there is a shortcut on the desktop which fires up acct.exe and starts the application in the appropriate folder where the data folder and other files are stored.

This has previously worked fine. But today, after transferring the latest acct.exe (4,430 MB) onto the USR machine, the shortcut failed. It invited me to navigate to the place where the file was held (C:\Program files\acct_fldr). And when I did that and confirmed that I wanted to run an .exe file, and that it was indeed acct.exe., this error message came up :

Acct.exe is not a Visual foxpro .EXE file.​

But I can run this file acct.exe as a shortcut on the DEV machine for two other sets of data files which happen to be set up on that machine. Both machines are running Windows 10.

I had wondered whether there might be something wrong with the USB drive. So I copied a slightly older version of acct.exe (4,422 MB) from the DEV machine onto the USB and transferred it onto the USR machine. This time it worked fine.

It almost seems as though I have included some extra stuff in the latest acct.exe file which the USR machine finds not satisfactory. But I think I have only made minor correction to a few forms, fixing bugs.

Grateful if anyone knows why this might be happening.

 

[AndrewMozley]

The problem appears to relate to my having removed deleted records from (PACKed) the .vcx/vct files which contain the form classes and control (textboxes, labels) which are used within the project.

This can be done by opening the relevant vcx file as a dbf (exclusively) and then packing what VFP regards as a dbf table,

I am pretty sure that I have done this several times over the years and it had not caused a problem. And on my own DEV machine that did not cause a problem : a shortcut to the resultant .exe file works fine.

But it appears that the USR target machine does not like the resultant .exe file created by invoking the Build command. I have recovered the .vcx files (complete with deleted records) and the resultant .exe file (about 200K bigger) will happily run on the USR machine. And packing these files, building again gives a file which repeats the error.

Thank you for your help.

 

[AndrewMozley]

However, if anyone elso has come across theis error message :

is not a Visual foxpro .EXE file.​

I would be interested to learn more.

 

[Nigel Gomm]

Andrew,

i had something similar a year or so ago where the built .exe was occasionally smaller than it should be.

Never really got to the bottom of it - a rebuild fixed and if memory serves i added "CLEAR RESOURCES" (to my script) before the build.

hth

n

 

[german12]

Andrew.
are both windows 10 build-versions identical (both with the latest updates?)

Klaus


Peace worldwide - it starts here...

 

[AndrewMozley]

Thank you Klaus.

The machines are broadly similar. Different memory, but both both machines have all the latest updates. For what it is worth they are both running the same Anti-virus : ESET._ _ DEV is running Office 365, USR is running Office 2016

Grateful for your help. This message :

acct.exe is not a Visual foxpro .EXE file​

When it happened to you, did you find out the cause?

Thanks. Andrew

 

[german12]

Hi Andrew,
sorry I could not answer earlier.

When it happened to you, did you find out the cause?

I didn't have the problem with a VFP program.
It was just a guess that a different version of Windows could be the cause.
It's been a very long time since I was able to upload to a program on computer # 1, but on computer # 2 it wouldn't.
I then found out on computer no. 2 that I had loaded the last Windows update, but something must have been incorrect in the transfer for this update. So I repeated the update for Windows on computer # 2 and all of a sudden
the program ran again (it was a Lotus 1-2-3 program).
Hence my guess, you could have a similar cause.

Best regards
Klaus

Peace worldwide - it starts here...