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
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.
' 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
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:
App.ReturnValue = MyErrorCode
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:
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
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?
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.
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
NEVER use END. The correct way is to use FUNCTION = error level at the end of the WinMain function.
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.