1. Win32lib, bitmapped captions, David C.
Hello Euphoria Programmers, hello David Cuny,
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.
here is the code (changes ending with --HM):
--------------- snip snap -------------------------------------------
[...]
-- HM990830 now user can return the exit value of an event in an --HM
-- onEvent handler using returnValue( value ) --HM
atom message_return, exitValue --HM
global procedure returnValue( integer value ) --HM
message_return = 1 --HM
exitValue = value --HM
end procedure --HM
-- -- --HM
global function WndProc(atom hWnd, atom iMsg, atom wParam, atom lParam)
-- callback routine to handle Window class
-- This routine processes messages sent by Windows
-- NEW! 0.15 renamed "pointer" to "action"; "action" to "event"
integer id, event, action, mouseX, mouseY
sequence parms
object result
-- find the control
-- NEW! 0.20d replaced find( hWnd, window_handle ) with getId( lParam )
id = getId( hWnd )
-- save the id for getSelf()
myId = id
-- not one of mine?
if id = 0 then
-- default processing
return c_func( xDefWindowProc, { hWnd, iMsg, wParam, lParam } )
end if
-- user can process events that Win32Lib doesn't have handlers for.
-- HM990830 now user can return the event's exit value using --HM
-- returnValue() --HM
if onEvent[ id ] > 0 then
message_return = 0 --HM
-- call routine
call_proc( onEvent[ id ], {iMsg, wParam, lParam} )
-- return an exit value --HM
if message_return then --HM
return exitValue --HM
end if --HM
end if
[...]
--------------- snip snap -------------------------------------------
Best regards,
Hendrik Mundt
mailto:hm-1704 at gmx.de
2. Re: Win32lib, bitmapped captions, David C.
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
3. Re: Win32lib, bitmapped captions, David C.
- Posted by JJProg at CYBERBURY.NET
Sep 03, 1999
EU>I'd implemented a solution like Hendirk's before, but there's a reason I
EU>never posted it: it was buggy. Not in itself, but in conjunction with calls
EU>to Windows. For example:
EU> globalVariable = 123
EU> sendMessage( ... )
EU> ? globalVariable
EU>What value will be in globalVariable? You can't say, because sendMessage()
EU>causes an immediate callback to WndProc, and there's no guarantee what's
EU>been done to the global variable. I found this out the hard way tracking
EU>down some bugs in Llama. And virtually any Win32Lib routine is a wrapper
EU>around sendMessage(). This is why the getSelf() function is flakey.
EU>Comments?
EU>-- David Cuny
What if globalVariable was a sequence - like a stack. For example:
sequence returnStack
integer returnStackIndex
returnStackIndex = 0
returnStack = {}
global procedure setReturnValue(atom value)
returnStack[returnStackIndex] = value
end procedure
global procedue WndProc(...)
atom returnValue
...
returnStack &= 0
returnStackIndex += 1
call_proc(eventhandler,{...})
returnValue = returnStack[returnStackIndex]
returnStackIndex -= 1
returnStack = returnStack[1..length(returnStack)-1]
end procedure
Jeffrey Fielding
JJProg at cyberbury.net
http://members.tripod.com/~JJProg/
4. Re: Win32lib, bitmapped captions, David C.
Jeffrey Fielding wrote:
> What if globalVariable was a sequence - like a stack.
Yeah, that occured to me a minute after posting. It would also take care of
the problem with getSelf(), so I should probably implement it.
Thanks!
-- David Cuny
