Announcement

Collapse
No announcement yet.

Closing the console window with PBCC 5

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Closing the console window with PBCC 5

    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

  • #2
    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
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Use #BREAK ON

      Comment


      • #4
        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

        Comment


        • #5
          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.
          Michael Mattias
          Tal Systems Inc. (retired)
          Racine WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            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


            Code:
            #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

            Comment


            • #7
              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.
              Michael Mattias
              Tal Systems Inc. (retired)
              Racine WI USA
              [email protected]
              http://www.talsystems.com

              Comment


              • #8
                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?)
                Last edited by Mottel Gutnick; 16 Jan 2009, 05:59 AM.

                Comment


                • #9
                  >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
                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      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
                      Michael Mattias
                      Tal Systems Inc. (retired)
                      Racine WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment

                      Working...
                      X