DOS ErrorLevel value

[Mark Strickland]

Is it possible to pass the ErrorLevel value from a FF program back to a calling batch file?

The PowerBASIC END statement has an optional parameter, that if used, will return the ErrorLevel to the calling program or batch file.  I just don't know exactly where to find the END statement and is there some built in FF method to pass a value?

There are other ways to accomplish what I need but this would be the most elegant.

Thanks,

Mark

[Eddy Van Esch]

From the looks of the FF generated source code, you have to give a value to FF's standard global variable 'App.ReturnValue' before closing your program.

Code Select Expand


' Common info that the programmer can access via the global APP variable.
Type APP_TYPE
   Comments        As Asciiz * %MAX_PATH   ' Comments
   CompanyName     As Asciiz * %MAX_PATH   ' Company Name
   EXEName         As Asciiz * %MAX_PATH   ' EXE name of program
   FileDescription As Asciiz * %MAX_PATH   ' File Description
   hInstance       As Long                 ' Instance handle of the program
   Path            As Asciiz * %MAX_PATH   ' Current Path to the EXE
   ProductName     As Asciiz * %MAX_PATH   ' Product Name
   LegalCopyright  As Asciiz * %MAX_PATH   ' Legal Copyright
   LegalTrademarks As Asciiz * %MAX_PATH   ' Legal Trademarks
   ProductMajor    As Long                 ' Product Major number   
   ProductMinor    As Long                 ' Product Minor number   
   ProductRevision As Long                 ' Product Revision number
   ProductBuild    As Long                 ' Product Build number   
   FileMajor       As Long                 ' File Major number     
   FileMinor       As Long                 ' File Minor number     
   FileRevision    As Long                 ' File Revision number 
   FileBuild       As Long                 ' File Build number     
   ReturnValue     As Long                 ' User value returned from FF_FormClose
End Type
Global App As APP_TYPE


Code Select Expand


Function WinMain( ByVal hInstance     As Dword, _
                  ByVal hPrevInstance As Dword, _
                  ByVal lpCmdLine     As ASCIIZ Ptr, _
                  ByVal iCmdShow      As Long _
                  ) As Long
.......
    Function = App.ReturnValue
End Function


So, all you have to do before closing your main form is:

Code Select Expand

App.ReturnValue = MyErrorCode

[Mark Strickland]

That does look correct .... BUT ....

I set the value in the form destroy event and it always returns zero.

I looked at the generated code for the only form in the project and I found this as part of the generated code:

Code Select Expand


Function FORM1_FORMPROCEDURE( ByVal hWndForm As Dword, _
                                      ByVal wMsg As Dword, _
                                      ByVal wParam As Long, _
                                      ByVal lParam As Long _
                                      ) As Long

...... some distance down in this function ......

         ' // Clear the optional UserData
         App.ReturnValue = 0



It appears that setting the value to zero occurs in a CASE statement when the form is created.

I may try to modify that line of code and recompile the generated code to see what happens.

More soon.

Thanks, Mark

[Mark Strickland]

I have not had any luck re-compiling the program directly with PB10.  I guess I don't have all of the paths correct.

BUT #1 -- I put an END statement in the Form Destroy event and it ends immediately and DOES pass the ErrorLevel.

BUT #2  -- Is this a good practice that will cause other problems?

[Paul Squires]

I have a feeling that at some point I added that code to reset the App.ReturnValue thinking that it could cause problems if people were displaying, closing, and re-displaying the same Form over and over. When I switched to Jose's CWindow code I started using the App.ReturnValue to hold the "lParam" user data that the programmer could pass in the Form's WM_CREATE message.

Putting an END in WM_DESTROY if you absolutely know that you want your program to end should be okay. However, as MCM would say, "you will lose style points"    It is generally accepted that the programmer should clean up allocated memory, etc prior to their program ending and in all my programs I make it a habit to ensure that anything that I have allocated will be deallocated upon the program ending.

The PB Help file also states that terminating when COM objects are active could be a problem. Windows itself doesn't care because when a program is terminated it will eventually reallocate all of that program's memory anyway.

END also has an optional parameter to pass an ErrorLevel back to the operating system, so in your situation that is kind of a bonus.

My thoughts are that in older, more finiky operating systems like Windows 95 or 98 then maybe sudden termination of a program could cause problems but these days everything should get released (memory, GDI objects, etc).

Interesting what other people's thoughts are on this.

[Mark Strickland]

YEP .... "No style points" .... but without this little trick I don't even get to "jump off of the diving board".   

This is a fairly simple program so putting this in the only window DESTROY event is probably OK.  If I find otherwise I will let you know.  I might even test for memory leaks by launching and killing this a few hundred times.

Paul .... Thanks for the feedback.

Mark

[José Roca]

NEVER use END. The correct way is to use FUNCTION = error level at the end of the WinMain function.

[Paul Squires]

The problem is that Mark doesn't have access to the end of WinMain from within FireFly. In the past, a FF user would normally be able to assign their ErrorLevel to App.ReturnValue and FF would pass this back to the O/S upon termination. However, I screwed that up when I added code generation to reset that value to zero when the Form is destroyed. I need to update FF to make the code generation correction.