Closing the console window with PBCC 5

[Arie Verheul]

With PBCC 4 the normal behaviour of the console is, that closing the console
window with the system menu automatically terminates the process.
In my view this is the proper behaviour, and most of my console applications
rely on it.

I recently changed to PBCC 5 where this seems to be different.
For me (Win XP, SP3), an attempt to close the console window no longer terminates
the process but causes a Windows error "Windows cannot terminate ..".

Are others experiencing the same problem, and are there any suggestions for a cure ?

Arie Verheul

[Michael Mattias]

I would think the CC5 behavior is far superior, as it prevents terminating a process accidentally.

If you really want "terminate on close" you can handle this by setting up Console Event Handler (SetConsoleCtrlHandler() WinAPI function) and effecting an orderly termination of your program in your callback procedure.

(There's probably a way to do it with intrinsic functions, too).

MCM

[Bob Zale]

Use #BREAK ON

[Arie Verheul]

Thanks

Thanks Bob, that works, i would not easily have guessed that myself.

This time i disagree with you Michael. If there is a system menu button available,
it should be legitimate to use it, and not produce an error.
If a programmer wants to prevent that the application is closed accidentally,
it would be more appropriate to disable the button, which can be done easily using
GetSystemMenu() and DeleteMenu().

Arie Verheul

[Michael Mattias]

I don't disagree with the behavior of the generated code, I just think it's a crummy way to design a program.

Thou shouldst "END" as gracefully as thou wouldst "START UP."

Then again, it may be moot. Code not shown.

[Arie Verheul]

Well, here's the example

Michael, i normally organise applications as shown below, and use a variable to jump out of a loop
if a certain condition is met.
But still, one should consider the option that the console window is closed with the X in the system menu,
as the button is simply there, and someone might use it.

This example does run without generating an error with #Break On, but produces an error with #Break Off,
if the window is closed with the system menu.
For certain types of use it could make sense to set default #Break On.
I changed the file template to do this.

Arie Verheul

#Compile Exe
#Dim All
#Break On

'--------------------------------

Function PBMain () As Long
    
    Global ExitVar As Long

    Do
        SomeTask
        
    Loop Until ExitVar

End Function

'--------------------------------

Sub SomeTask
    
    ' Task goes here
End Sub

[Michael Mattias]

Basically I believe no program has ended correctly until it reaches the end of WinMain (PBMAIN). However...

normally organise applications as shown below, and use a variable to jump out of a loop if a certain condition is met.

This speaks volumes and explains all.

[Mottel Gutnick]

What's wrong with that?

This speaks volumes and explains all.

What do you mean Michael?

Every (conditional) loop terminates on some exit condition. (Unless of course the condition can never occur, such as "loop until 1=2", which is effectively an UNconditional loop.) But there is no indication that Arie is doing the latter. Presumably, his ExitVar will at some stage become true and his program WILL reach the end of PBMain. (Unless a user pre-empts this and closes the Window prematurely. As to whether this should be allowable or not, see end of this post.)

Surely you don't suspect Arie of having trapped the system event generated when a user clicks the close-window button and that is what is setting ExitVar to true? If so: (a) he wouldn't have posted his question, and (b) his program would end gracefully and Windows would not object. That message "Windows cannot end this program. ..." (not really an error) only comes up if the program is still busy. (In any case, it includes an override "end now" button, so the user can force it to terminate if he so wishes.)

In my case (Win XP, SP3, PBCC 3.04), I wish the console window would NOT close when the program ends, and I don't see any system setting (at least not one settable in the shortcut) to prevent this. (.PIF shortcuts have a "close on exit" checkbox in the Program tab to let a user dictate this behaviour for each program individually, but .LNK shortcuts have no such checkbox, and the window closes as soon as the program ends, even if it ends normally.

Of course you can prevent this by inserting a waitkey$ loop at the end of PBMain. But this is far from ideal. For a program that interacts with the user, the whole program runs within a loop (as in Arie's example) and once the user triggers the exit condition, it makes sense for the program to end and for the console window to close immediately. That is, the program keeps doing stuff (a, b or c, depending on what key was pressed), then waits for another keypress ... until the user decides to quit by, say, pressing Esc, and the loop then ends. (This is probably the kind of loop in Arie's example.)

But sometimes I want to run just a single, non-iterating, linear process, display a result, end, and the window to stay open so I can read the final result, then close it manually. It should not be necessary to keep the window open by putting a waitkey$ loop at the end. It is a needless drain on system resources to keep the program looping just to prevent the window closing.

In both types of program, I agree with Arie that the user should be able to shut it down prematurely if he really wants to, by simply closing the console window. But if the user didn't write the program, he doesn't know if doing so might be dangerous. He might just be interrupting a waitkey$ loop, but on the other hand, he might be interrupting a disk write. Windows only knows that the program is busy; it doesn't differentiate as to what it is busy with. But the programmer knows how safe it is for this to happen. So if the programmer can now use a compiler setting (#break) to dictate Windows' response to a close console-window click (which is what I understood Bob Zale's reply to convey), I think it's an improvement.

I am assuming that for a program compiled with CC 5 with #break on, Windows will just shut up and close the console window (old behaviour) upon such a system event, but with $break off (which sounds like the default), Windows will issue the above warning if the program is still running.

I am also assuming that if the program ended normally, the console window now stays open and has to be closed manually, but in such a case, Windows will close it without complaint, regardless of the #break setting (since there is no breaking being done). Is this assumption correct?

(Is this really the main purpose of the #break directive, or is it mainly there to dictate what happens in the event of a Ctrl-break keypress?)

[Michael Mattias]

>But the programmer knows how safe it is for [pre-emptive program termination] to happen.

Yes, he does; but we don't; code not shown.

On the other thing: I am a well-known critic of "controlling program flow by looping on a variable's value" for various and sundry reasons with which I shall not bore you today.

Perhaps this is an option worth exploring for console programs which must display a final result, but must also operate in "if nobody's looking, end after a reasonable amount of time" mode: Wait for key, click or clock for PB/WIN and PB/CC

MCM

[Arie Verheul]

What actions does Windows actually take to terminate a process ?

Instead of making this a philosophical question, it would be interesting to
understand what Windows internally does with a request to terminate a process.
My understanding is that Windows keeps a very precise account of all resources assigned to a process.
Terminating a process would in that case mean that Windows takes its list and simply clears everything
associated with the specific process.

If this picture is correct, it would make no difference for the system whether the termination
was triggered by a program reaching its end, or by some other break mechanism.
If this picture is wrong, please correct me.

A different issue is that it could make a difference to the application if it is terminated
improperly and there is still data to be saved or processed, but i think it is up to the
programmer to handle that.

Again a different issue is that applications might be communicating with each other, in which case the
termination of one application might lock up the others, but this is here not the case.

Arie Verheul

[Michael Mattias]

it would make no difference for the system ...
A different issue is that it could make a difference to the application ..

Give that gentleman one of the big stuffed teddy bears for his little lady friend, since he has hit the target square for fair!

MCM