Finish a PB/Win program?

[Gert Voland]

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.

[Mike Doty]

DECLARE SUB      ExitProcess LIB "KERNEL32.DLL" ALIAS "ExitProcess" (BYVAL uExitCode AS LONG)

[Manuel Valdes]

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,

[Guy Dombrowski]

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.

[Michael Mattias]

, 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().

[Gert Voland]

Mike,

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.

[Mike Doty]

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.

[Michael Mattias]

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.

[Mike Doty]

User defined

#COMPILE EXE 'c:\junk.bas
#DIM ALL
#INCLUDE "win32api.inc"
FUNCTION PBMAIN () AS LONG
  ExitProcess 99
  ? "This will not execute"
  SLEEP 1000
END FUNCTION

#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

[Michael Mattias]

suppose the exitcode would be used by another process to see how your program ended?

REM  runmyprog.cmd
MyProg.exe 
ECHO program myprog ended with Exit code %ERRORLEVEL%
echo end of job

C:\MYFOLDER> Start runmyprog.cmd

That's close, anyway.

MCM

[Manuel Valdes]

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.

[Gert Voland]

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.

[Michael Mattias]

>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

[Manuel Valdes]

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,

[Michael Mattias]

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.

[Guy Dombrowski]

> 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.

[Michael Mattias]

>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

[John Strasser]

<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

[Guy Dombrowski]

Well Michael,

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

[Michael Mattias]

> 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