1. possible win32lib bug

Windows 10 Euphoria 4.05 Win32Lib 0.70.20

Building GUI using win32lib. I have encountered a problem. Been bugging me for a long time because I don't understand it.
It has to do with graceful exits. Anytime the user makes a mistake the software detects it and throws up a MsgBox with an explanation. User clicks OK in MsgBox. If it is an unrecoverable fatal error, immediately upon returning from the MsgBox, I call closeApp() to terminate the program. One senario is when printing to a network printer. To print the user is asked via the win32lib getPrinter() utility to select a printer. If the user clicks CANCEL in the getPtinter() window the routine returns an empty string. I detect this empty string I report the problem using the MsgBox. User clicks MsgBox OK and program calls closeApp(). I get an error from win32lib and the program crashes.
Error Message:
Win32Lib AppWindow - Error Warning
Error code 436
getRect:GetObject for bitmap failed.

There is a workaround to prevent the crash. I print a single space <32> via puts(1, " ") to the console and then call closeApp(). Everything works as advertised.

if not printer_setup () then 
	puts(1, " ") 
	closeApp () 
	return 
end if 


This snippet includes the workaround. Take out the puts(1," ") and program crashes. I have explored win32Lib; however, the chances of me figuring this out are slim to none.
As I said, I think it's a bug in win32Lib
Anyone have any thoughts?

Thanks in advance for your patience.
regards,
jd

new topic     » topic index » view message » categorize

2. Re: possible win32lib bug

Does this create an ex.err file? If so, can you post the stack trace? Can you provide a minimum working example?

-Greg

new topic     » goto parent     » topic index » view message » categorize

3. Re: possible win32lib bug

Yes I can give you requested items. Send me your email address (to jed7@cox.net) and I will email you the stuff. Too big for forum post.
Regards,
jd

new topic     » goto parent     » topic index » view message » categorize

4. Re: possible win32lib bug

jessedavis said...

Yes I can give you requested items. Send me your email address (to jed7@cox.net) and I will email you the stuff. Too big for forum post.

You can send them to ghaberek@openeuphoria.org. But also, this is what our Pastey service is for.

-Greg

new topic     » goto parent     » topic index » view message » categorize

5. Re: possible win32lib bug

While writing a little note to point you to the problem I was mindlessly staring at the screen when an epiphany happened! Dangerous things those epiphanies. View the following code:

procedure pw_print_btn_onClick (integer self, integer event, sequence params) 
if not printer_setup () then 
	closeApp () 
	puts(1, "#1 after close app line 474\n") 
end if 
puts(1, "#2 after close app line 475\n") 
if equal(log_to_print,"docent") then 

line 474 [closeApp]: 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.

new topic     » goto parent     » topic index » view message » categorize

6. Re: possible win32lib bug

jessedavis said...

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.

new topic     » goto parent     » topic index » view message » categorize

7. Re: possible win32lib bug

petelomax said...

It will hide/destroy your main window and (eventually) cause your WinMain() call to return, that's all.

This is for Pete Lomax:

I apologize for my absence. Heart event - ended up in hospital.
Why this bothers me...
I execute the closeApp().
The main window is closed. When the main window is closed a signal is sent to the main loop to terminate.
VOID = sendMessage( id, WM_CLOSE, 0, 0 )
Unfortunately, while this message is rattling around Euphoria continues to execute at the next line. How long this takes probably depends on the task switcher. If one happens to hit this just as the system switches to a new task the delay can be considerable (100 ms at least).
Hence the problem and the crash.
The abort() is a ham fisted way to deal with this but is works.
I'm not very good at this stuff (especially system related stuff).

As always, thanks for your help.
Regards,
jd

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu