1. win32lib bug?
- Posted by A Moore <amwerds at HOTMAIL.COM> Jan 22, 1999
- 500 views
I am trying to use onEvent to trap the opening of a menu (WM_INITPOPUPMENU, defined as 117 hex). However, the inclusion of the statement onEvent[WM_INITPOPUPMENU]=routine_id(my_routine) crashes the interpreter. I tried replacing the constant i had declared with the actual value, first #117, then 279 (the decimal equivalent) and still no luck. Then I started using lower numbers... the interpreter would allow numbers no higher than 6.. naturally, the event was never trapped. onEvent sends three atoms as parameters, and my code is prepared for this, but the onEvent[] assignment fails before the code ever runs. Help?
2. Re: win32lib bug?
- Posted by The AfterBeat <afterbeat at GEOCITIES.COM> Jan 22, 1999
- 506 views
Well, in Win32Lib, you can only use the event variables (such as onClose, onEvent, etc.) with handles returned by create(), because when the create() function is called, it allocates enough space to hold events by only that extra handle. Therefore, the win32lib event variables can't be used with Windows system messages. Here's an example to help clarify.. This assumes that no changes have been made to the event variables. I'll use onEvent in the example. 0 calls to create() - onEvent = {} 1 call to create() - onEvent = {-1} 5 calls to create() - onEvent = {-1, -1, -1, -1, -1} 50 calls to create() - onEvent = repeat(-1, 50) I hope that helps.. The AfterBeat A Moore wrote: > I am trying to use onEvent to trap the opening of a menu (WM_INITPOPUPMENU, > defined as 117 hex). However, the inclusion of the statement > > onEvent[WM_INITPOPUPMENU]=routine_id(my_routine) > > crashes the interpreter. I tried replacing the constant i had declared with > the actual value, first #117, then 279 (the decimal equivalent) and still > no luck. Then I started using lower numbers... the interpreter would allow > numbers no higher than 6.. naturally, the event was never trapped. > > onEvent sends three atoms as parameters, and my code is prepared for this, > but the onEvent[] assignment fails before the code ever runs. > > Help?
3. Re: win32lib bug?
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Jan 22, 1999
- 494 views
A Moore wrote: > I am trying to use onEvent to trap the opening of > a menu (WM_INITPOPUPMENU, defined as 117 hex). > However, the inclusion of the statement > > onEvent[WM_INITPOPUPMENU]=routine_id(my_routine) > > crashes the interpreter. The index to onEvent should be the id of the control being given the action - the value returned by create(): onEvent[MyControl] = routine_id("onEvent_MyControl") The onEvent handler receives all the events that are passed to that control. It's up to your routine to filter them out: procedure onEvent_MyMenu( atom msg, atom wParam, atom lParam ) -- only interested in WM_POPUPMENU event if msg = WM_POPUPMENU then -- your handler code here end if end procedure onEvent[MyMenu] = routine_id("onEvent_MyMenu") Hope this helps. -- David Cuny
4. Re: win32lib bug?
- Posted by A Moore <amwerds at HOTMAIL.COM> Jan 22, 1999
- 526 views
- Last edited Jan 23, 1999
> >A Moore wrote: > > >> I am trying to use onEvent to trap the opening of >> a menu (WM_INITPOPUPMENU, defined as 117 hex). >> However, the inclusion of the statement >> >> onEvent[WM_INITPOPUPMENU]=routine_id(my_routine) >> >> crashes the interpreter. > >The index to onEvent should be the id of the control being given the action >- the value returned by create(): > > onEvent[MyControl] = routine_id("onEvent_MyControl") > >The onEvent handler receives all the events that are passed to that control. >It's up to your routine to filter them out: > > procedure onEvent_MyMenu( atom msg, atom wParam, atom lParam ) > -- only interested in WM_POPUPMENU event > if msg = WM_POPUPMENU then > -- your handler code here > end if > end procedure > onEvent[MyMenu] = routine_id("onEvent_MyMenu") > >Hope this helps. > >-- David Cuny One of those times when I found the answer shortly after posting about it. Found out also the event message was sent to the Main Window (the one opened by WinInit() instead of the menu itself. But I'm sure you knew that already :) I drummed up a bit of code that you might be interested in: -- assumes open_dll("user32.dll") global constant MF_SEPARATOR = #800 AddSep=define_c_func(user32,"AppendMenuA", {C_INT,C_INT,C_INT,C_POINTER},C_INT) This function allows the addition of a horizontal line separator in Parent_Menu. The final two passed parameters are ignored. Returns a boolean for the success of the addition. Place this between create(MenuItem,...) calls of the items you wish the separator to go. The on-the-fly submenu thing I posted has been solved also, so dont bother with that one. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com