How to Debug a compiled EXE or APP

[dantheinfoman]

Hi All,

I can't seem to figure out how to debug through our programs. I have all the project files, but the calling program is an EXE (this is the master project file), then it calls a bunch of different APP files, depending on which module you want to go into. At any rate, I've tried opening up the debugger directly with the EXE file and it says select a program from Application but they're all grayed out?!

So then I read about SET STEP ON, but this doesn't work, it just ignores this code.

Anyone have trouble with this or know a solution. We could get a lot more work done if we could debug instead of just using wait windows all the time in order to understand what's happening in the code.

Thanks for your time!

Dan

 

[Olaf Doschke]

You don't debug an EXE, not in VFP nor in .NET nor any other language, you debug source code.

Bye, Olaf.

 

[Mike Lewis]

Dan,

SET STEP ON is only supported when running directly in the development environment, because the debugger is part of that environment. The same is true of breakpoints, ASSERTs, and similar debugging tools.

If you really need to debug an APP or an EXE, the best you can do is to display messages to indicate what is happening in the program at any given time. Alternatively, write messages to a log file; these can indicate which point the program is at, the value of important variables, etc.

But it's really much better to do your debugging in the development environment, before you build the App or EXE.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

Run the EXE from the command window instead of from Windows Explorer. Your breakpoints, SET STEP, etc., should be respected and you can debug away.

I have a production app that has SET STEP ON left permanently in an invoicing routine that sometimes gets a little frisky. When users have a problem, it halts subsequent processing. I run the app in the IDE, alter the errant property when the SET STEP is hit, and RESUME.

Easy peasy.

 

[Mike Lewis]

Run the EXE from the command window instead of from Windows Explorer. Your breakpoints, SET STEP, etc., should be respected and you can debug away.

That's right. But don't forget to include debugging information in the compile (either by setting the Debug property .T., or selecting the appropriate option in the Project Info window).

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[dantheinfoman]

Hi All,

Quick update, thanks to all your responses and an older thread I found, I got this working. Here's what I had to do/know.
1. Had to go to project>Project Info and check the "Debug" checkbox and hit OK.
2. Then rebuild using the Build button. Note: the EXE and APP files with debug info included are like 10x as large (4mb turned into 40mb but worth it!)
3. You can't open the EXE or APP using windows explorer (a file folder), but in order to debug and utilize the SET STEP ON breakpoints, you must use the command window, such as
DO C:\mydirectory\myfile.EXE
In the command window. Then it will allow you to debug a compiled APP or EXE. Note: you must also have the project file (.pjx) or I don't believe it would trust that you have the right to see this info.

Thanks, you've made my life so much easier in the near future. No more never ending stream of WAIT WINDOWs!!

Yours

Dan

 

[Tore Bleken]

Wait Window should never be used for debugging! Use Debugout instead, which will show the result in the debug window. If the debugger isn't active, nothing happens and no slowdown occurs. This means that you don't have to remove any of your code after you have fixed the error.

 

[Mike Lewis]

Dan,

You'r pretty well spot on with your summary. And thanks for making the point about the large file sizes. That's the reason I almost never include debugging info in my compiles. On the other hand, including debugging info has the benefit that your error routine can log the actual line of code that fires an error - for what that's worth.

Tore,

I agree about using DEBUGOUT. For the same reason, ASSERT is a good choice in certain cases.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I never did DO C:\mydirectory\myfile.EXE, indeed you can also start DO main.prg IN myfile.EXE, even without debug info (you'll just not see any code in the trace window this way).

You can't remote debug, though, you can't start the debugger from an error message coming from the EXE for a customer, and you can't distribute the vfp9.exe for your customer to start an exe from there.

So the essential thing to have is an error handler logging error info, additional to what you find in the help topic on the ON ERROR trigger, which will teach you about ERROR(), MESSAGE(), LINENO() you also have AERROR(), some SYS() functions to get an alias name invovled in the error, SAVE TO to save variables and ASTACKINFO. Some of the info isn't available though, even with debug info included.

Notice, there is a difference in _VFP.Startmode when you startt the EXE normal or via DO EXE/DO main in EXE (which both use the VFP9.exe as runtime and work in your process including the debugger). You could react to that with several settings like SET ASSERT ON/OFF.

For your final product started normally without VFP9.exe unlike .NET you can't debug even with debug info in the EXE. In .NET you can have PDB files as separate info and attach to a process remotely (if certain ports allow you to). The debug info helps a bit so that the current line of code is given as MESSAGE(1), but ASTACKINFO will not fill in Array column 6 for all stack levels at least. There are limitations espeially with DBC trigger events or code (expressions) you put into properties running at class instanciation even before Load or Init the first time a class is loaded into memory.

Debugging the EXE isn't really debugging the EXE, it's like debuging in source code, as it does not involve the vfp9r.dll, it does run the same code you can directly run via starting main.prg from the project manager or command window, therefore you gain no further evidence your EXE is complete or error free testing it with DO EXE.

A framework I use has a staartup routine the main.prg also starts. You can start it with a parameter denoting which level of start you want and it can just setup all PATHs and SERT LIBRARY so you can start any class with CREATEOBJECT() or use the goApp application object. That also really helps testing even before compiling an EXE.

Bye, Olaf.

 

[dantheinfoman]

Thank you!

Dan