CommandLineHelloWorld run crashes Dolphin

Hi,

I was looking into a way to run external commands and found the above
example. Unfortunately it didn't react to the <enter> and when I closed the
window an exception was raised (without closing the command window):

16:44:55, 24 November 2000: '#onCloseConsole is the responsibility of the
subclass'
DevelopmentSessionManager(Object)>>subclassResponsibility
DevelopmentSessionManager(GUISessionManager)>>onCloseConsole
DevelopmentSessionManager(SessionManager)>>onConsoleCtrl:
MessageCallback>>valueWithArgumentsAt:
ExternalCallback class>>callback:withArgumentsAt:
[] in ProcessorScheduler>>callback:withArgumentsAt:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:withArgumentsAt:cookie:
InputState>>isInputReady:
InputState>>loopWhile:
InputState>>mainLoop
[] in InputState>>forkMain
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in BlockClosure>>newProcess

A couple of seconds later Windows NT informs that the application cannot
respond to the End Task request. Closing that window makes Dolphin crash.

Dolphin 4.0 on NT 4 pl 5

It looks like it's missing the #onCloseConsole somewhere. More serious IMHO
is the way it crashes.

Thanks,

Ted

Ted

You wrote in message news:8vm6km$4vuon$[hidden email]...
>
> I was looking into a way to run external commands and found the above
> example. Unfortunately it didn't react to the <enter> ....

I think you'll find that it did (respond to the enter), as otherwise control
would not have been regained to raise that walkback.

The console window is not expected to close when you press enter, although
it can be programmatically closed. When you evaluate '<ConsoleSessionManager
subclass> run'  you are using a test/debug capability intended for
developing console applications (all this will be explained in the
forthcoming update to the Education Centre). These are run under the
auspices of the current session manager, which in the IDE is obviously the
development session manager. The console is left open when the "console app"
terminates you can still see the output.

The console window is not a normal window. If the user attempts to close it
(in the normal way), then Windows interprets this as a request to shut down
the entire application, and it will pop up the "not responding" dialog box
in 5 seconds if the application does not exit within that time. There seems
to be no way to prevent this, unless anyone knows differently. I quote from
Microsofts documentation on SetConsoleCtrlHandler() (the routine that allows
one to set a callback to receive notable control events from the console):
-------------------
"The CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT signals
give the process an opportunity to clean up before termination. A
HandlerRoutine called to handle any of these signals can do one of the
following after performing any cleanup operations:

Call the ExitProcess> function to terminate the process.

Return FALSE. If none of the registered handler functions returns TRUE, the
default handler terminates the process.

Return TRUE. In this case, no other handler functions are called, and the
system displays a pop-up dialog box that asks the user whether to terminate
the process. The system also displays the dialog box if the process does not
respond within a certain time-out period (5 seconds for CTRL_CLOSE_EVENT,
and 20 seconds for CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT). "

---------------------

The event that one receives when the close button is clicked is the
CTRL_CLOSE_EVENT, which as you can see the only options are to return FALSE,
in which case the OS immediately terminates the process, return TRUE, in
which case it displays a dialog, or not return at all but shutdown under
ones own steam. In the latter case if the process does not shutdown in 5
seconds, then the the dialog is display anyway. The latter is what is
expected to happen when a console opened by the Dolphin IDE is closed,
but....
IMHO
> is the way it crashes.

Actually the problem is an excess of #onCloseConsole implementations :-).
The implementation in GUISessionManager should not be there at all (the
implementation in the base class of SessionManager is correct for GUI apps).
You can delete it, or wait for the next LiveUpdate to do so. The only
possible response to closure of the console window in a GUI app. appears to
be to initiate a shutdown, which is what the SessionManager implementation
of #onCloseConsole does.

What Dolphin is intended to do is to pop its normal exit confirmation
message box, that asks if you want to save the image, of course the DNU you
mention prevents that happening. Even when it does do that you will find
that the OS will probably display an "End Task" dialog because 5 seconds is
not really sufficient time for the user to respond, even if he or she has
noticed the message box. I don't think this is very satisfactory, but it is,
as far as I can tell, not something that we can work around: Windows treats
close of the console as a request to close the app., and I haven't found any
way to change its mind. Attempting to close the console window doesn't work,
because Windows is expecting the application to exit, and will still prompt
with the end task dialog. This does reduce the utility of the console to GUI
apps, it must be said, but it is very useful in the IDE for debugging and
testing console applications.

I wish the console did not behave like that, but it does. If you want to run
external non-GUI processes from GUI apps, it is probably best to do so
silently without a console, as that way that dangerous "close" button (which
is really exactly the same as hitting the End Process button in the task
manager) won't be available for users to press. See
CRTLibrary>>spawnForOutput:.

I'm surprised you say that closing the "End Task" dialog crashes Dolphin.
Cancelling it should leave Dolphin up, and closing it is the same as
cancelling. OK'ing it cause the OS to forcibly shutdown Dolphin. I suppose
the latter could be interpreted as a "crash" :-).

Please try again with GUISessionManager>>onCloseConsole deleted to see what
is supposed to happen, even if it is not ideal. If anyone knows a way to do
better, I'd be very glad to here about it.

Regards

Blair

Ted

I wrote in message
news:dyzT5.8668$[hidden email]...
>
> I wish the console did not behave like that, but it does. ... If anyone
knows a way to do
> better, I'd be very glad to here about it.

Actually I've just had an idea myself. I see that it is possible to get the
handle of the console window, in which case it may be possible to intercept
the original close command and prevent it raising the console control
event....watch this space.

Blair

Hi Blair,

>
> Actually I've just had an idea myself. I see that it is possible to get
the
> handle of the console window, in which case it may be possible to
intercept
> the original close command and prevent it raising the console control
> event....watch this space.
>

Please let me know how to get hold of that handle, that might solve my
problem with that Java interface.

Thanks,

> Blair
>
>

Ted

Ted

You wrote in message news:8vtbhv$5khf6$[hidden email]...
> ...
> Please let me know how to get hold of that handle, that might solve my
> problem with that Java interface.

HWND GetConsoleWindow()

It's a kernel library function. You'll have to open the console before
spawning the Java app, and you might need to read up a bit on MSDN to see
how to get it to share the console if it doesn't do that automatically. Try
it first though.

Regards

Blair