OpenEuphoria

1. Popup menu

• Posted by Pete Stoner <stoner.pete at gmail.com> Mar 19, 2007
• 573 views

Hi Guys, 
I have a win32lib prog with a hidden window that opens a popup menu at the
cursor 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
menu item so the menu just 'goes away' and I want to be able to trigger a routine
when this happens, but I haven't been able to find an event notification for it.

Regards PeteS

3. Re: Popup menu

• Posted by Pete Stoner <stoner.pete at gmail.com> Mar 19, 2007
• 551 views

CChris wrote:
> 
> Pete Stoner wrote:
> > 
> > Hi Guys, 
> > I have a win32lib prog with a hidden window that opens a popup menu at the
> > cursor
> > 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
> > menu item so the menu just 'goes away' and I want to be able to trigger a
> > routine
> > when this happens, but I haven't been able to find an event notification for
> > 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

function PopupClose(integer pSource, atom hWnd, atom iMsg, atom wParam,  atom
lParam)
         ? 1
         return {0}
  end function
  setWinMsgHandler( MainWin, WM_EXITMENULOOP, routine_id("PopupClose"))

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

5. Re: Popup menu

• Posted by Pete Stoner <stoner.pete at gmail.com> Mar 20, 2007
• 544 views

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
> > > > 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

7. Re: Popup menu

• Posted by Pete Stoner <stoner.pete at gmail.com> Mar 20, 2007
• 573 views
• Last edited Mar 21, 2007

CChris wrote:
> 
> 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</font></i>
> > > 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</font></i>
> > > > > > 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</font></i>
> > > 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,</font></i>
> > > > > 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
> </font></i>
> > > > > tell you if submenus of your popup menu were closed, only the menu
> > > > > itself.
> > > > > 
> > > > > CChris
> > > > 
> > > > snipped
> > 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
> 
> }}}
<eucode>
> 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)
> </eucode>
{{{


Thanks Chris, That works fine. In my real prog I kill the timer in the click
event (I have a central one for all the menu items) as I can run my cleanup after
those routines have run. The main thing I needed was to catch when the menu
closes without a selection. - I thought of having a delay after getting the close
but totally missed setting a timer, good call!

It even works with the timer interval set to 1, the close and click events may
be posted at the same time just in the wrong order...

Thanks again,
PeteS