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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
BUILD EXE
- Thread starter FBM357
- Start date
Read up about READ EVENTS.
The only reason your program works interactively is because the objects/menues you create still "live" after your program terminates and the command window becomes active, but in the .EXE, there is not command window to become active, so the whole VFP environment quits.
The only reason your program works interactively is because the objects/menues you create still "live" after your program terminates and the command window becomes active, but in the .EXE, there is not command window to become active, so the whole VFP environment quits.
- Thread starter
- #3
Sorry for being confusing:
(when running the EXE you really are still "in" VFP; in the VFP-runtime instead of the VFP-IDE)
READ EVENTS is the command that tells the VFP-runtime to enter the "event loop" that waits for input from the mouse and keyboard, and executes menu commands, etc, in response to that input.
In the IDE, the READ EVENTS event loop is not needed because the Command prompt is already an event loop. That is, the VFP-IDE doesn't exit when no program is running.
So, in your main program .PRG, after all the initialization code (which creates the menues, and perhaps displays in introductory window), you should add the command READ EVENTS.
When your .exe is run, VFP will "stop" on that statement and wait for (and respond to) user input. When you want your application to quit, issue the command "CLEAR EVENTS". Execution will resume with the statement after "READ EVENTS"
(alternatively, you can just issue "QUIT" which will exit VFP immediately)
If you don't have a main .PRG file, you could put the READ EVENTS into your main form's "Init" event code, at the end. I don't like this approach.
(when running the EXE you really are still "in" VFP; in the VFP-runtime instead of the VFP-IDE)
READ EVENTS is the command that tells the VFP-runtime to enter the "event loop" that waits for input from the mouse and keyboard, and executes menu commands, etc, in response to that input.
In the IDE, the READ EVENTS event loop is not needed because the Command prompt is already an event loop. That is, the VFP-IDE doesn't exit when no program is running.
So, in your main program .PRG, after all the initialization code (which creates the menues, and perhaps displays in introductory window), you should add the command READ EVENTS.
When your .exe is run, VFP will "stop" on that statement and wait for (and respond to) user input. When you want your application to quit, issue the command "CLEAR EVENTS". Execution will resume with the statement after "READ EVENTS"
(alternatively, you can just issue "QUIT" which will exit VFP immediately)
If you don't have a main .PRG file, you could put the READ EVENTS into your main form's "Init" event code, at the end. I don't like this approach.
- Thread starter
- #5
wgcs,
Thank you for being patient with me ..
I'm converting/writing a lot of Clipper apps into VFP and at times fall asleep only to be awakened by the nightmare...LOL
Thanks a lot! I'm sure I'll have more questions as they arise!
FBM
"If you want SQUARE work, you DON'T cut CORNERS!!!" ...
Thank you for being patient with me ..
I'm converting/writing a lot of Clipper apps into VFP and at times fall asleep only to be awakened by the nightmare...LOLThanks a lot! I'm sure I'll have more questions as they arise!
FBM
"If you want SQUARE work, you DON'T cut CORNERS!!!" ...
- Status
