Re Pulldownmenu button bug on Windows
ambassador at fourthworld.com
Sat May 7 16:42:30 EDT 2022
It's definitely an inconsistency, but the bug's status as requiring
"EXPERT REVIEW" prompts us to consider why these differences exist, and
which, if any, should be considered "wrong" or "right". It may not be
as simple as it seems at first glance.
MetaCard (the engine we now call LiveCode) was born on Unix, later
ported to Windows, Linux, and then MacOS.
On all platforms menus are implemented as selector buttons, buttons
which provide the appearance and behavior of OS-provided menu objects.
And until the port to MacOS, all platforms behaved consistently.
So why the Mac change?
Mac is unique among popular GUI OSes in its use of a global menu bar,
attached to the top of the display; other OSes place the menu bar
attached to the top of the window.
Internally, LC menus are implemented as temporary
dynamically-instantiated nameless stacks, which may seem
counterintuitive until you realize that a menu is in essence a highly
specialized form of window, a viewport independent of other windows with
its own buffer, contents, and like all windows needs to use a common
compositor for rendering them all together. (Indeed you can even use
stacks as menus explicitly when you need a non-standard look, like a
graphical picker, but that's another topic).
So the engine's method of using a subclass of the stack object for
rendering menus worked well and consistently for a great many years -
until the port to MacOS.
The Mac global menubar required a deep rethink on how menus are handled,
not only in terms of detaching them from the window but also in terms of
the nuances of display and interaction.
So Dr Raney special-cased menus on MacOS, so the engine uses OS routines
to render those, fed by the menu button properties for things like the
menu name as parameters to those OS routines. On every other platform
you're interacting with a LiveCode object, but on Mac you're interacting
with a system object into which the engine has inserted some hooks to
tie it in with your scripting so you can at least know when an item has
This rewiring of properties and messages is no small feat, and has
pervasive effects. So from time to time you'll find Mac-specific things
needed to conform to that platform like adding an "About" item to a menu
that doesn't exist in your stack (the Mac's "Application" menu belongs
to the OS).
It's not surprising that messages related to menu objects also have some
inconsistencies along with everything else.
If we consider that on all other platforms the menu object we're
interacting with is a button, and the menus that appear are a stack, the
messaging you see with Windows and Linux is consistent with other button
object messaging: once the mouse leaves the control the mouseLeave
message is sent.
On Mac we have an exception to LC's normal button messaging because
we're not interacting with an LC button at all, but with a system
object, into which the engine devs have grafted just enough messaging to
trigger actions from scripts.
I have no opinion on qualitative labels like "right" or "wrong" on this;
that seems a matter of personal familiarity and taste. It may even be
somewhat philosophical: is a menu a single thing that expands, or two
things (menu and items) where one triggers the appearance of the other?
All I can do is help describe the under-the-hood parts to help makes
sense of how the difference came about.
Whether or not we prefer it, the menu architecture is what it is, at
least at the moment. Changing the behavior on all other platforms to be
like Mac, or Mac to be like all other platforms, would be a scope of
work that I'd guess the team would not be in a position to make a
priority any time soon, even if they felt strongly about this one way or
They have a lot on their plates, and for all the questions we see
regarding Mac-specific menu differences (like the auto-migration of the
"About", "Help" and "Preferences" items to system menus separate from
the menu objects where we're asked to put them), I can't recall seeing a
message here before about mouseLeave.
I'm not saying it isn't important. It might well be. But observably this
affects few; AFAIK this is the first such request in the 23 years I've
been using this engine and participating in its communities. Just the
same, let's roll up our sleeves and see what can be done:
Edge case or not, let's see what we can do to get a solution for you
sooner than the engine team would be able to even thinking about
revisions as sweeping as would be needed to satisfy the engine request.
What do you need from mouseLeave during a menu drop? What are you doing
in response to that message?
There are some clever people on this list. I'll bet we can find a
solution for your need once we more fully understand the goals.
Fourth World Systems
Neville Smythe wrote:
> The pulldownmenu bug I reported has been confirmed: bug 23693
> To remind the reader: On a Mac, when a user select a menu item from
> a pulldown menu button, the menuPick message is sent first followed
> by a mouseLeave message (generated as the mouse leaves the button
> rect to select the menu item). On Windows, the mouseLeave is sent
> immediately, followed by menuPick.
> The Mac order is correct, the mouseLeave should be delayed until the
> displayed menu is dismissed.
> Linux has the same incorrect behaviour as Windows.
> The same situation applies to popupmenus and option menu buttons:
> the Mac has the correct order, Windows and Linux incorrect.
> However for the combobox button, all three platforms give the wrong
> message order!
> And one last twist, although the Mac implementation gives the correct
> order for 3 menu buttons, it sends the mouseLeave message twice, once
> immediately after the menuPick, and then again when the mouse is
More information about the use-livecode