Announcement

Collapse
No announcement yet.

Finish a PB/Win program?

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

  • Finish a PB/Win program?

    Just a short question:

    Is there any way to finish a PB/Win 9 program (.exe) as it can be done with END in PB/CC 5?
    When we are in PBMAIN it is easy to EXIT the FUNCTION - but can it be done from a SUB?
    I am not using a DDT or SDK message pump - just Graphic Windows.

    I assume the answer is simply No, but one never knows ....

    Best rgds, Gert.
    Gert Voland

  • #2
    Code:
    DECLARE SUB      ExitProcess LIB "KERNEL32.DLL" ALIAS "ExitProcess" (BYVAL uExitCode AS LONG)

    Comment


    • #3
      Gert:

      I have read your interesting posts and codes about PBCC Graphic Windows, and I share your preferences for procedural programming. What I am using to terminate a Graphic Window program in any moment, either in PBWIN9 or PBCC5, is to include a pair of "GRAPHIC GET DC TO hvin / IF hvin=0 THEN EXIT LOOP" within every loop in the program. This way even if the graphic window is closed by clicking the window's close button, the process will take the program to its end.

      Regards,
      Last edited by Manuel Valdes; 26 Jul 2009, 11:33 AM.

      Comment


      • #4
        Ending a Graphic PBCC program

        I have also been using that technique.
        Before the 5.01 version, the #BREAK ON statement did not exist and if you used #CONSOLE OFF you could not get the program to end with the [x] button.
        I had to add a GRAPHIC WINDOW END command to enable closing the program with that button.
        Old QB45 Programmer

        Comment


        • #5
          , is to include a pair of "GRAPHIC GET DC TO hvin / IF hvin=0 THEN EXIT LOOP" within every loop in the program.
          Sounds like a MACRO begging to be written. (It's also ugly but that is highly subjective)


          and I share your preferences for procedural programming.
          You can fairly easily adapt to the event-driven model... but ... remember all that stuff you read about "using procedures" rather than coding lots of stuff "in line?" You pretty much need to do that to exit gracefully back to WinMain().
          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Mike,
            Code:
            DECLARE SUB      ExitProcess LIB "KERNEL32.DLL" ALIAS "ExitProcess" (BYVAL uExitCode AS LONG)
            thanks for the hint.

            What is the significance of "uExitCode". I don't find the Win32® Programmer's Reference very clear in this point.

            ExitProcess is described as "the preferred method of ending a process". Would it do the same as (or replace) END in PB/CC?

            Rgds, Gert.
            Gert Voland

            Comment


            • #7
              Yes, it would work the same as END.
              PowerBASIC issues the statement when it ends.
              I suppose the exitcode would be used by another process to see how your program ended?
              I never use it, but was introduced to it using SQLitening.
              If PowerBASIC needs to do more cleanup is unknown.
              Note: I'm only the messenger on this one.
              Last edited by Mike Doty; 26 Jul 2009, 09:52 AM.

              Comment


              • #8
                What is the significance of "uExitCode". I don't find the Win32® Programmer's Reference very clear in this point.
                We must be using different SDK references because this seems pretty clear to me:
                uExitCode
                [in] Exit code for the process and all threads terminated as a result of this call.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]
                http://www.talsystems.com

                Comment


                • #9
                  User defined

                  Code:
                  #COMPILE EXE 'c:\junk.bas
                  #DIM ALL
                  #INCLUDE "win32api.inc"
                  FUNCTION PBMAIN () AS LONG
                    ExitProcess 99
                    ? "This will not execute"
                    SLEEP 1000
                  END FUNCTION
                  Code:
                  #COMPILE EXE 'c:\junk2.bas
                  #DIM ALL
                  #INCLUDE "win32api.inc"
                  FUNCTION PBMAIN () AS LONG
                    LOCAL exitcode AS LONG
                    SHELL "c:\junk.exe", EXIT TO exitcode&
                    ? STR$(exitcode)
                    SLEEP 1000
                  END FUNCTION

                  Comment


                  • #10
                    suppose the exitcode would be used by another process to see how your program ended?
                    Code:
                    REM  runmyprog.cmd
                    MyProg.exe 
                    ECHO program myprog ended with Exit code %ERRORLEVEL%
                    echo end of job
                    Code:
                    C:\MYFOLDER> Start runmyprog.cmd

                    That's close, anyway.

                    MCM
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      I wonder whether those ways to end a program are really "by the books".

                      From the PBCC5 Help:


                      Normally, PowerBASIC programs are terminated when you exit the PBMAIN or WINMAIN() function. It should always be your goal to end programs in this fashion, so that the compiler and the operating system can do everything possible to leave things in an orderly state.

                      END is intended only for temporary use in converting DOS programs to Windows. You should convert it to the standard EXIT FUNCTION method as soon as possible. END must never be used in a program which uses COM access.

                      Comment


                      • #12
                        Mike,

                        Note: I'm only the messenger on this one.
                        Well, I will not hold you responsible for any unexpected consequences - promised.

                        Still, this is good news. I will use it in the library "GrButtons.inc" for an exceptional escape (i.e. finish the .exe),
                        when the main graphic window has been closed externally (e.g. by [X]) under PB/Win.
                        Thus, an application would behave in the same way as when the Console gets closed under PB/CC and all GWs also get destroyed.
                        Normally, the flow takes the user programs cleanly to the end of PBMAIN ...

                        Thanks again.
                        Gert.

                        PS: uExitCode seems to be the same as in END [nErrorLevel&] in PB/CC.
                        Gert Voland

                        Comment


                        • #13
                          >I wonder whether those ways to end a program are really "by the books".

                          You mean calling ExitProcess()? That's what the compiler does as the last thing before the end of the WinMain function.

                          But the reason you want to "flow back" to WinMain rather than call this yourself is, the compiler also handles its own internal cleanup before exiting. That's why you see the reference in the help file re COM objects. Certain COM libraries consume system resources "forever" unless explicitly release, and the compiler handles that.

                          Under Win 9x/ME, GDI objects were like that, too... they just ate up resources even though the process had ended.

                          MCM
                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            Michael:
                            I think you are right. My concern is whether an abrupt termination while the program flow of a procedural program is several levels low in nested DO/LOOP procedures, some implying FONT NEW, BITMAP NEW, XPRINT ATTACH and so on, is going to be a clean exit after an END statement or its equivalent. Being a practical man I have done some experiences, and verified that a process running nested in a DO/LOOP will continue running until the system reset, if the program is not properly ended.
                            Even though I am rather old (I am 66, and my first programs were written in GFA Basic running on an Atari 520 ST in the early eighties), my experience is mostly DOS (GFA Basic, Forth, Turbo Basic, Turbo Pascal, Clipper, Power Basic) and, in the Power Basic Pre-Window era, some Delphi and VB programs. So I do not have the knowledge or the experience to properly evaluate such issue. BTW sometimes I have felt scared or ashamed of giving opinions side by side with real professional programmers (my profession is that of a Mechanical Engineer), but getting every day a lot of knowledge from these forums, I feel is my duty to offer my modest experiences.
                            Best regards,

                            Comment


                            • #15
                              You can never go wrong forcing your program to reach its logical end.. that is, reach the "END FUNCTION" of PBMAIN(). Never.

                              You CAN go wrong terminating otherwise. You not necessarily WILL go wrong, but you CAN when you do this.
                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]
                              http://www.talsystems.com

                              Comment


                              • #16
                                > BTW sometimes I have felt scared or ashamed of giving opinions side by side with real professionnal programmers.

                                Manuel, welcome to the club
                                I am also a Mechanical Engineer and I learned programming by myself.
                                Following that Forum is a very good school indeed and I try to help others when I can.

                                I thought that the END command was foolproof but now, I will be more carefull.

                                BTW, I love the wines we import from your country.
                                Last edited by Guy Dombrowski; 27 Jul 2009, 10:58 AM.
                                Old QB45 Programmer

                                Comment


                                • #17
                                  >I am also a Mechanical Engineer and I learned programming by myself.

                                  Must be contagious....

                                  Michael C. Mattias
                                  BSME '72
                                  Milwaukee School of Engineering Milwaukee WI
                                  Michael Mattias
                                  Tal Systems (retired)
                                  Port Washington WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    <snicker>

                                    For the record, most of the CS majors I went to school with never worked in IT after more than 5 years out of school. With 1 exception - and he's installing medical equipment for Philips Electronics in hospitals - NOT programming.

                                    Everyone I know who does any programming either never went to college at all or has degrees in other fields.

                                    JS
                                    BS Chem Eng 1989
                                    MS Industrial Chemistry 1990
                                    MBA - 1993
                                    John,
                                    --------------------------------
                                    John Strasser
                                    Phone: 480 - 273 - 8798

                                    Comment


                                    • #19
                                      Well Michael,

                                      I guess that Engineers like procedural programming better than event driven one !
                                      Old QB45 Programmer

                                      Comment


                                      • #20
                                        > guess that Engineers like procedural programming better than event driven one !

                                        Real Engineers - and Programmers - can handle either with equal facility.

                                        Personally, I LOVE the 'event-driven' model. Windows handles all the low-level crap and one can concentrate on the application.

                                        MCM
                                        Michael Mattias
                                        Tal Systems (retired)
                                        Port Washington WI USA
                                        [email protected]
                                        http://www.talsystems.com

                                        Comment

                                        Working...
                                        X