Starting EXE on Windows server 2012 foundation results in a file locator dialog

[Dan Olsson]

This happens ONLY on 3 places out of about 40 and those 3 are the only ones tha uses the server OS above. The file locator has the texst "DO" and has *.fxp as default file filter. If I changes to "All files" and then chooses the same EXE as was already in the shortcut everything is OK.

Any thoughts? As I said, it works everywhere else on anything from XP, W7, W8 (and W10) to Windows 2003/2008 server. /Dan

 

[Olaf Doschke]

Are there any OLE PUBLIC classes in the project of the EXE?
Try to start VFP9.exe as Administrator, then compile the EXE and deploy the new build result.

Bye, Olaf.

 

[Dan Olsson]

No there are not any OLE PUBLIC classes.
Do you mean that IF there where it could make a difference to start VFP9.exe as Administrator or do you mean that it could make a difference anyhow?

 

[Olaf Doschke]

Atually you neve ned to starthe IDE with administrator elevation. If yo do OLEPUBLIC csss can be reistered (or reregistered) by the buil process itself.
I only once had the effect you se and the reason seemed very obviously an olepublic class, as the behaviour was repeatable:

Every time I rebuilt the PJX from scratch and made a first compile the final EXE worked. Only secondary compilations showed the file open dialog when starting. And that can be explained as in a project with olepublic classes those are only known and seen in the servers tab of project info. The build process needs to discover olepublic classes in its first run. The final EXE then works, but after secondary build not. Removing olepublic classes from the project the built EXE works everytime.

I assume the build does something else to an exe after being able to register olepublic servers, maybe something about the XML manufest embedding, that was the last thing added to VFP9s build process.

Bye, Olaf.

 

[GriffMG]

I have seen this behaviour from time to time, usually I just recompile and copy the new exe file over
the old one and it works - my assumption has been that the initial copying process was flawed in some way and
the original .exe file was slightly corrupted. The recompile is probably unnecessary, but it gives a new date/time
to the target, so it is easier to identify

Regards

Griff
Keep [Smile]ing

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

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​

 

[Dan Olsson]

The EXE can't be corrupted for at least two reasons:
1. As I said, the same EXE is run on several other Sites/OS:s without problems.
2. A VPF-exe runs a selfcheck on itself when starting up and refuses to start if tampered with.

 

[GriffMG]

DrD

While I do bow to your greater knowledge, a VFP .exe can indeed be corrupted and still run, in fact it can be deliberately altered
and still run - I just did a little experiment and 'mucked about' with a VFP .exe to see if that were true.

And when I have noticed the behaviour you describe - which happens a few times a year - all I have to do is replace the
.exe with either a recompiled one or a known good one from another machine.

Regards

Griff
Keep [Smile]ing

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

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are not good for you. ​