Re: Popup menu

new topic     » goto parent     » topic index » view thread      » older message » newer message

Pete Stoner wrote:
> 
> CChris wrote:
> > 
> > Pete Stoner wrote:
> > > 
> > > CChris wrote:
> > > > 
> > > > Pete Stoner wrote:
> > > > > 
> > > > > Hi Guys, 
> > > > > I have a win32lib prog with a hidden window that opens a popup menu at
> > > > > the
> > cursor</font></i>
> > > > > position, there's one last thing I am trying to get working... 
> > > > > 
> > > > > Is there a notification I can act on when the menu disappears? i.e.
> > > > > the user
> > > > > opens the popup menu then clicks elsewhere on the screen without
> > > > > selecting
> > any</font></i>
> > > > > menu item so the menu just 'goes away' and I want to be able to
> > > > > trigger a
> > routine</font></i>
> > > > > when this happens, but I haven't been able to find an event
> > > > > notification
> for</font></i>
> > > > > it.
> > > > > 
> > > > > Regards PeteS
> > > > 
> > > > This works in my modified version, by firing w32HCloseUp on the menu. So
> > > > far,
> > > > I had no signal from Derek on whether he plans to absorb this, and a few
> > > >
> > > > other, change into the official lib.
> > > > 
> > > > A quick fix would be to set a raw message handler for your hidden window
> > > >  listening for the WM_EXITMENULOOP message. As I understand it, your 
> > > > window only has one menu, so this could be the way to go. This trick
> > > > won't
> > > > tell you if submenus of your popup menu were closed, only the menu
> > > > itself.
> > > > 
> > > > CChris
> > > 
> > > Thanks Chris, this works
> > > }}}
<eucode>
> > > function PopupClose(integer pSource, atom hWnd, atom iMsg, atom wParam, 
> > > atom lParam)
> > >          ? 1
> > >          return {0}
> > >   end function
> > >   setWinMsgHandler( MainWin, WM_EXITMENULOOP, routine_id("PopupClose"))
> > > </eucode>
{{{

> > > 
> > > It triggers fine when the menu closes, but I just realised the routine I
> > > want
> > > to run when the menu closes will break the routines that run when an item
> > > is
> > > clicked (its a 'cleanup' routine which *must* run after any menu item
> > > routines
> > > have finished). I've tried setting a flag on the menuitem click event and
> > > checking
> > > that flag in the exitmenuloop routine but it looks like the exitmenuloop
> > > is
> > > triggered before the click so the flag doesn't work..
> > > 
> > > What I need is to be able to run the cleanup either if the user clicks
> > > elsewhere
> > > without selecting a menu item or *after* any menu click routines have
> > > finished.
> > > 
> > > Any ideas?
> > > 
> > > Regards PeteS
> > 
> > I didn't test this, but you'd need then to trap the WM_MENUSELECT message as
> >  well, or more precisely to monitor this message in a w32HAfterEvent handler
> >  for the hidden window.
> > 
> > If the high word of wParam is #FFFF and lParam is 0, the system closed the 
> > menu. See if this condition occurs after the w32HClicks were processed.
> > Don't set the return value, 0 (the default) is just fine.
> > Un general, wParam holds the id of the clicked item, if any.
> > 
> > If this works, try monitoring WM_EXITMENULOOP instead in the w32HAfterEvent,
> >  because the check will be simpler. I have no idea whether there's any
> >  guarantee of the messages being sent in the same sequence according to
> >  the various Windows versions.
> > 
> > HTH
> > CCChris
> 
> Chris, I've tried a few variations and it always seems to post the close
> before
> the click, I can't see anyway I can do what I want. I even tried the CloseUp
> event in your modified w32lib and that also posts the events with the close
> first..
> Unless someone can suggest anything?
> 
> PeteS

I checked the message queue on my system, and indeed WM_COMMAND (the message
 which triggers the w32HClick event) is sent by Windows after WM_MENUSELECT,
 WM_EXITMENULOOP and friends return. Hence, all the variations you may have
 thought of had the same outcome, and my w32HAfterEvent scheme as well.

The code below has the desired effect for me, see if iy works for you too.
On a slow machine, you may have to raise the timer threshhold a little.

Unfortunately, the lib doesn't store the timestamps; this could have help
 define the right timing.

Hopefully I understood your program logic right.

CChris

include win32lib.ew
constant
w=create(Window,"test",0,50,50,200,200,0),
p=create(Popup,"testing",w,10,10,180,180,0),
pi=create(MenuItem,"Button 1",p,10,10,140,30,0)

procedure p(integer id,integer event,sequence data)
?123
end procedure
setHandler(pi,w32HClick,routine_id("p"))

constant WM_EXITMENULOOP=#212

function f(integer s,atom h,atom msg,atom wparam,atom lparam)
setTimer(w,0,50)
return kMainMsg
end function
setWinMsgHandler(w,WM_EXITMENULOOP,routine_id("f"))

procedure q(integer id,integer event,sequence data)
    if data[1]=WM_RBUTTONDOWN then
        popup(p,data[2],data[3])
    end if
end procedure
setHandler(w,w32HMouse,routine_id("q"))

procedure q0(integer id,integer event,sequence data)
?456
killTimer(w,0)
end procedure
setHandler(w,w32HTimer,routine_id("q0"))

WinMain(w,Normal)


new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu