Re: possible win32lib bug
- Posted by petelomax Aug 19, 2019
- 1319 views
Supposedly, win32lib procedure closeApp() releases any system resources and closes down the application. It does do this in most cases; however, here it seems this does not happen. It's a race to the finish and win32lib loses! I think what happens here is line 474 is executed but euphoria doesn't wait until it is finished before executing line 475. Now Euphoria is a procedural language. It executes code one line at a time. In the above example Euphoria will happy continue executing statements after line 474 until a crash occurs or win32lib finally gets around to closing the application. If you insert an abort (0) between 474 and 475 all it good.
This bothersome on several levels. When one calls a procedure one expects it to be completely executed to the "end procedure" statement before returning control to the calling routine.
This is all closeApp() does:
global procedure closeApp() if mainWindow != 0 then closeWindow(mainWindow) end if end procedure
It will hide/destroy your main window and (eventually) cause your WinMain() call to return, that's all.
If you try to do anything with your mainWindow (or whatever you've called it, or any of the gui elements on it), you'll have problems.
The puts(1," ") will shift focus, and that way change what messages win32lib sends your application (hence why it sometimes helps).
An abort() is fine. Another idea is setting a flag and/or all your (local) win32lib handles to NULL, then if that flag is set in your ex.err,
don't be doing whatever caused the crash after you've done a closeApp(). HTH.
