I have a desktop that I'm trying to run two different networked VFP9 apps on. When I launch the one exe it loads fine. When I launch the second one it does not load at all and gives no error message, etc. This second app works fine on 30 other networked computers, just not this specific one. It is not the screen on / off problem because it does not load at all. I even copied the network folder to this local hard drive and it still doesn't load. Any suggestions?
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 derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
VFP exe wont load
- Thread starter KarenJB
- Start date
Doesn't it load at all? Or doesn't it show any UI? Maybe it is seeking for a resource on startup before putting up any UI and you are thinking that it doesn't run at all?
Check task manager\Processes tab if it is there or not. If it is there, then likely it is trying to show up a messages like "Open File" or anything similar.
One other possibility (unlikely but happened to me) it is running on multiple monitors and the UI position is currently off the screen ( from your message I get it as if you are doing remote desktop - it might be working on the one you don't see ).
A return for any reason before 'read events' would also cause the application to startup and immediately shut down.
Yet another reason is faulty PATH environment variable (but as far as I remember that shows a message).
Cetin Basoz
MS Foxpro MVP, MCP
Check task manager\Processes tab if it is there or not. If it is there, then likely it is trying to show up a messages like "Open File" or anything similar.
One other possibility (unlikely but happened to me) it is running on multiple monitors and the UI position is currently off the screen ( from your message I get it as if you are doing remote desktop - it might be working on the one you don't see ).
A return for any reason before 'read events' would also cause the application to startup and immediately shut down.
Yet another reason is faulty PATH environment variable (but as far as I remember that shows a message).
Cetin Basoz
MS Foxpro MVP, MCP
- Thread starter
- #3
I would start by adding some WAIT WINDOW ... messages in the main prg, load event, init event, error handling routine and so on, and maybe rename the config.vfp file to backup if you're using one. It may at least give you a clue where the app is prematurely quitting.
-Dave Summers-
![[cheers]](/data/assets/smilies/cheers.gif "[cheers] [cheers]")
Even more Fox stuff at:
-Dave Summers-
Even more Fox stuff at:
Karen,
Do you have the source code?
It could be such a variety of things, it's hard to know where to start.
I would check the workstation with problems against one which works and look for drive mappings that are different, and for printers that are not installed/available.
I would also try changing my access rights locally to ensure they are similar.
After that, you need the source to make good guesses.
Martin
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
Do you have the source code?
It could be such a variety of things, it's hard to know where to start.
I would check the workstation with problems against one which works and look for drive mappings that are different, and for printers that are not installed/available.
I would also try changing my access rights locally to ensure they are similar.
After that, you need the source to make good guesses.
Martin
Regards
Griff
Keep [Smile]ing
There are 10 kinds of people in the world, those who understand binary and those who don't.
- Thread starter
- #6
This almost has to be machine dependent. It works every place else. This is the first computer that won't load it. I just thought maybe somebody has run in to this thing before. And with another app running fine on this pc it makes it all the more bewildering. Thanks for your input though, I appreciate it. If I ever do figure it out I will post the solution.
Mike Lewis
Programmer
Karen,
One of the items you might check is the Config.FPW file, if any. It might be present as a free-standing file in the same directory as the main executable. If such a file does exist, check that the one on the bad machine is identical to all the others.
The reason I specifically mention this file is that it has the ability to make the application invisible (_SCREEN = OFF). This is somethimes done during the startup process to prevent VFP's main window flashing on the screen. It wouldn't completely explain the behaviour you are seeing, but it's worth taking a moment to check it.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
One of the items you might check is the Config.FPW file, if any. It might be present as a free-standing file in the same directory as the main executable. If such a file does exist, check that the one on the bad machine is identical to all the others.
The reason I specifically mention this file is that it has the ability to make the application invisible (_SCREEN = OFF). This is somethimes done during the startup process to prevent VFP's main window flashing on the screen. It wouldn't completely explain the behaviour you are seeing, but it's worth taking a moment to check it.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
- Thread starter
- #8
Mike,
Once you start the app with a _SCREEN=OFF in the config file you still can see the app running in the taskmanager though? It seems Karen checked the processes.
In my app I sometimes make use of a simply dummy textfile at a certain disk location (mostly just C:\). The excistence of that textfile unlocks some debug features like showing messageboxes at several places inside my prg's.
telling me what happens and where we are in the code. But also such a file might contain data to stop the app from starting up further.
So I would suggest as others done before to bring the code in here. Than we can have a more specific look at the problem.
-Bart
Once you start the app with a _SCREEN=OFF in the config file you still can see the app running in the taskmanager though? It seems Karen checked the processes.
In my app I sometimes make use of a simply dummy textfile at a certain disk location (mostly just C:\). The excistence of that textfile unlocks some debug features like showing messageboxes at several places inside my prg's.
telling me what happens and where we are in the code. But also such a file might contain data to stop the app from starting up further.
So I would suggest as others done before to bring the code in here. Than we can have a more specific look at the problem.
-Bart
Mike Lewis
Programmer
Bart,
Yes, I know. It was a bit of a long shot.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
Yes, I know. It was a bit of a long shot.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
Olaf Doschke
Programmer
Is there any start code, that would quit the exe, if it doesn't find it's database? That's what I'd assume of a "non-starting" EXE. If you eg check existance of a configured DBC with FILE(), that might report .F./file does not exist if indeed it does, but it's hidden to some users or they doen't have access rights.
I don't know any reason why an (VFP) EXE really won't start other than missing resource/runtime files, so I assume it's such a reason.
More unlikely is a virus scanner killing the process.
You should perhaps use the Processmonitor tool ( and let it look at actions from or to your EXE.
I assume the EXE does start but also does quit or is killed so fast, that you won't see it in the processes tab of the task manager, but Process monitor will be able to log actions.
Bye, Olaf.
I don't know any reason why an (VFP) EXE really won't start other than missing resource/runtime files, so I assume it's such a reason.
More unlikely is a virus scanner killing the process.
You should perhaps use the Processmonitor tool ( and let it look at actions from or to your EXE.
I assume the EXE does start but also does quit or is killed so fast, that you won't see it in the processes tab of the task manager, but Process monitor will be able to log actions.
Bye, Olaf.
- Thread starter
- #13
I finally resolved this issue by placing the 2 vfp dlls that are needed to run VFP apps right in the folder where the exe resides. I have always put them in the windows\system32 folder and it's always worked before. I did check and this pc had a path to c:\windows\system32. Oh well, it works this way but it was very baffling. Thanks for all your responses to my issue, this website is the best there is for Foxpro support!
Mike Lewis
Programmer
Karen,
As you say, it's baffling. I would have thought the absence of the DLLs would have caused an error message at the very least.
Still, it's good to hear that you've solved the problem. Thanks for letting us know.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
As you say, it's baffling. I would have thought the absence of the DLLs would have caused an error message at the very least.
Still, it's good to hear that you've solved the problem. Thanks for letting us know.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
Olaf Doschke
Programmer
Yes Mike,
I would expect an error message complaining about the missing runtime/resource files too. Perhaps if the resource file containing the error messages is missing even displaying that error message fails.
That could be tested in a (Virtual) pc having no vfp or vfp runtime installed whatsoever. But I assume an error for the missing runtime files really is embedded into each vfp exe, you should have an error message. Would be worth to test that.
Bye, Olaf.
I would expect an error message complaining about the missing runtime/resource files too. Perhaps if the resource file containing the error messages is missing even displaying that error message fails.
That could be tested in a (Virtual) pc having no vfp or vfp runtime installed whatsoever. But I assume an error for the missing runtime files really is embedded into each vfp exe, you should have an error message. Would be worth to test that.
Bye, Olaf.
Mike Lewis
Programmer
Good point, Olaf.
It would be good to test it. I assumed that the message (regardling the absence of the runtime) would be issued by Windows, but maybe not.
Maybe I should get Virtual PC for cases like this.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
It would be good to test it. I assumed that the message (regardling the absence of the runtime) would be issued by Windows, but maybe not.
Maybe I should get Virtual PC for cases like this.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro tips, advice, training, consultancy
Custom software for your business
I have found that VFP 9 - unlike earlier versions, doesn't give any sort of error message if the runtimes are not installed. The apps just don't run.
The puzzle here though is why even though they were installed on that machine in the system folder, the app still failed. Maybe they weren't registered properly due to a rights issue?
Were they in the c:\Windows\system32 instead of the c:\windows\syswow64 folder or vice-versa?
-Dave Summers-
Even more Fox stuff at:
The puzzle here though is why even though they were installed on that machine in the system folder, the app still failed. Maybe they weren't registered properly due to a rights issue?
Were they in the c:\Windows\system32 instead of the c:\windows\syswow64 folder or vice-versa?
-Dave Summers-
Even more Fox stuff at:
- Thread starter
- #18
- Status
