Hi Jacqueline, thank you for your time and your suggestion.
I figured out that also a move command corrects the mouseloc for the popup command. set the screenmouseloc to globalloc(the loc of btn 1) move me to the loc of me --(or move this stack to the loc of this stack) Then the popup menu pops up at the loc of btn 1 Regards, Wolfgang Am Sonntag, den 28.02.2010, 12:00 -0600 schrieb J. Landman Gay: > G.Wolfgang Gaich wrote: > > > I experimented a while with the mouseloc and realized that it's not true > > that the popup opens at the mouse location when you set the mouseloc > > with e.g. 'set the screenmouseloc to globalloc(the loc of btn "b")'. > > In the dictionary: > > If no location is specified, the menu's top left corner is at the mouse > > location. > > And I wondered why the popup command does not accept the new mouse > > location. > > I just did a quick test and it looks to me like the engine doesn't use > the new position until a user event occurs. This is what I did: > > on arrowkey pwhich > if pwhich = "right" then > set the screenmouseloc to globalloc(the loc of btn 1) > get the mouseloc > popup btn 1 > put the mouseloc && it > else > pass arrowkey > end if > end arrowkey > > Nothing appears in the message box until I close the menu (correct > behavior.) Then the message box contains two identical locations, both > where btn 1 is, but the menu was actually displayed at the old mouse > position, as you reported. But if I step through the handler in the > debugger, it works as you'd expect. I think that's because I'm > generating user events by stepping in the debugger. > _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
