Hi Viktor,
It seems that returning EXCEPTION_EXECUTE_HANDLER (instead of
EXCEPTION_CONTINUE_SEARCH) suppresses the Windows GPF dialog and
allows the app to exit immediately.
Regards,
Randy.
At 02:34 PM 9/23/2008, you wrote:
Hi Randy,
Hi all,
I suggest the following changes to EXTAP.C:
Hi Randy,
What you say is probably possible to control by
the return value of the exception handler.
I'd feel a Set() to be too early to control such
an isolated, moreover platform-dependent detail in
Harbour, but if we can somehow broaden the context
this may also be an option.
For the time be
...or is it Harbour that is telling Windows that a GPF occurred? If
so, we should make this optional and just allow the EXE to exit.
Hi Viktor,
What would also be great would be if you could optionally (eg.
_SET_FORCE_FATER_TERMINATION) force the app to close instead of being
held open by the
Hi Viktor,
What would also be great would be if you could optionally (eg.
_SET_FORCE_FATER_TERMINATION) force the app to close instead of being
held open by the O/S GPF alert message. For example, a server
application that runs into a GPF, is held open/running since Windows
attempts to displa
Hi Randy,
Hi all,
I suggest the following changes to EXTAP.C:
1. The log should be closed BEFORE any alert messages are displayed.
True and thanks, I'll commit this ASAP.
2. There needs to be a way to suppress any alert messages (ie.
create log and exit) for applications that do not req
