OpenEuphoria

Re: Win32lib, bitmapped captions, David C.

• Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Sep 03, 1999
• 723 views

Hendrik Mundt wrote:

> i have included the following into your win32lib (v0.30)
> to enable the user to return the exit value of a message
> to windows when using the onEvent handler. i use this to
> return HTCAPTION after intercepting WM_NCHITTEST and testing
> the mouse position. this is used to have a bitmapped window
> caption. i am sure other people would be happy if you included
> these changes into win32lib.

Thanks for the suggestion. It points out a desgn flaw in Win32Lib that I
haven't addressed well. I chose to implement eventHandlers as procedures
because that was the way that it was implemented in Visual Basic. As tyou've
disconvered, this  runs into problems when the user wants to inform Windows
*not* to perform the default processing on an event.

An example of this (in addition to Hendrik's) is processing keystrokes. For
example, you might want your application to intercept keystrokes, and
convert tabs into spaces. This can't be done currently in Win32Lib, because
after onKeyDown is done processing the tab key, it's handed off to Windows
to process.

I'd implemented a solution like Hendirk's before, but there's a reason I
never posted it: it was buggy. Not in itself, but in conjunction with calls
to Windows. For example:

   globalVariable = 123
   sendMessage( ... )
   ? globalVariable

What value will be in globalVariable? You can't say, because sendMessage()
causes an immediate callback to WndProc, and there's no guarantee what's
been done to the global variable. I found this out the hard way tracking
down some bugs in Llama. And virtually any Win32Lib routine is a wrapper
around sendMessage(). This is why the getSelf() function is flakey.

So the global value returnFlag could get set, and then an Windows event
would be processed before the end of the routine, and the flag might
misinterpreted by the interrupting code, and be reset before returning.

The *proper* solution would be to convert all the event handling routines
from procedures to functions. This would break all the existing code, but be
consistant, and perhaps better in the long run. But I'm a bit reluctant to
force a 'return False' into every routine to accomodate a small percent of
code, although this is what Win32 and GTK+ do internally.

A less dramatic solution might be to just make onEvent() into a function.
The value that it passes back would go into a local variable, and not be
mangled by callbacks. This would still allow the sort of flexibility needed
to process low-level events, without impacting on existing code.

Comments?

-- David Cuny