Re: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

Klaus wrote:

> Am 11.05.2022 um 20:27 schrieb Richard Gaskin wrote:
>> ... make sure the buttons you're using in the menu stack have
>> their autoArm set to true, ...
>
> Hint:
> that property "autoarm" did not make it into the inspector somehow,
> so you need to do this by script!

It's far from the only one.  LC objects have a LARGE number of 
properties we can work with. The Inspector shows only a subset of the 
most commonly-used ones.


Inspectors are great for consumer tools, but dev tools tend to provide 
Property Sheets so they can expose a much larger range of properties 
developers will want to work with.


LC attempts to straddle the space between consumer tool and dev tool, in 
both marketing and IDE design, and it sometimes leads to things one camp 
or the other may find confusing.


I threw together a quick Property Sheet a while back:
http://fourthworld.net/revnet/devolution/4W_Props.rev.gz

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Re Pulldownmenu button bug on Windows

[Klaus major-k via use-livecode]

Hi all,

> Am 11.05.2022 um 20:27 schrieb Richard Gaskin via use-livecode 
> :

> ... make sure the buttons you're using in the menu stack have their autoArm 
> set to true, ...

Hint:
that property "autoarm" did not make it into the inspector somehow, so you need 
to do this by script!

> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web

Best

Klaus

--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Re Pulldownmenu button bug on Windows

[Ben Rubinstein via use-livecode]

Ditto that. There should be a "Lifetime contribution" award for Livecode heroes.

Ben

On 09/05/2022 14:54, Craig Newman via use-livecode wrote:

Richard.

So glad to have you in this world.

Craig


On May 7, 2022, at 5:35 PM, Bob Sneidar via use-livecode 
 wrote:

Well put. I wonder what the real world effect of the order of messages is, and 
whether or not it could be compensated for by send in time?

Sent from my iPhone


On May 7, 2022, at 13:44, Richard Gaskin via use-livecode 
 wrote:

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.


Background:
--
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 been selected.

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.



The Here-And-Now:

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

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:



Looking Forward:
---

Re: Re Pulldownmenu button bug on Windows

[Bob Sneidar via use-livecode]

I'm going to have a look at that Richard. Thanks. 

Bob S


> On May 11, 2022, at 11:27 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Neville Smythe wrote:
> > Thanks again Richard
> >
> > In my case I don’t actually need a workaround. Once I had corrected
> > my own error, the only effect of the inconsistent event order is that
> > on Windows and Linux the colour coding of the selection turns off a
> > fraction of a second earlier than on a Mac. I am not so obsessive as
> > to need to fix that.
> 
> Glad you have a solution.
> 
> Hopefully the demo I posted will be of use to others. Using stacks as menus 
> are a poor substitute for text menus when all you need is text, but a wide 
> range of graphical pickers can be made which can be very attractive and 
> super-simple to make:
> 
> Set the menuName property of a menu button to the short name of the stack you 
> want to use as a menu, make sure the buttons you're using in the menu stack 
> have their autoArm set to true, and all the normal menu behaviors you'd 
> expect just work.
> 
> Imagine icons used to represent a set of templates, or sample report output, 
> or graphical effects, or anything else that lends itself well to a graphical 
> picker menu.
> 
> I just updated the example stack this morning to include a simple graphical 
> picker so folks could get a clearer idea of how it can be very useful:
> 
> http://fourthworld.net/lc/MenuMessaging.livecode
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

Neville Smythe wrote:
> Thanks again Richard
>
> In my case I don’t actually need a workaround. Once I had corrected
> my own error, the only effect of the inconsistent event order is that
> on Windows and Linux the colour coding of the selection turns off a
> fraction of a second earlier than on a Mac. I am not so obsessive as
> to need to fix that.

Glad you have a solution.

Hopefully the demo I posted will be of use to others. Using stacks as 
menus are a poor substitute for text menus when all you need is text, 
but a wide range of graphical pickers can be made which can be very 
attractive and super-simple to make:


Set the menuName property of a menu button to the short name of the 
stack you want to use as a menu, make sure the buttons you're using in 
the menu stack have their autoArm set to true, and all the normal menu 
behaviors you'd expect just work.


Imagine icons used to represent a set of templates, or sample report 
output, or graphical effects, or anything else that lends itself well to 
a graphical picker menu.


I just updated the example stack this morning to include a simple 
graphical picker so folks could get a clearer idea of how it can be very 
useful:


http://fourthworld.net/lc/MenuMessaging.livecode

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re Pulldownmenu button bug on Windows

[Neville Smythe via use-livecode]

Thanks again Richard

In my case I don’t actually need a workaround. Once I had corrected my own 
error, the only effect of the inconsistent event order is that on Windows and 
Linux the colour coding of the selection turns off a fraction of a second 
earlier than on a Mac. I am not so obsessive as to need to fix that.

Nevertheless it is conceivable, if unlikely, that someone might want to do 
something more significant in the mouseLeave handler, so I continue to call the 
inconsistency a bug. The fact that the combobox menu button behaves in the same 
way on all 3 platforms does seem to indicate that the inconsistency could be 
resolved (in favour of the Windows event order). 

But I am also not so obsessive as to expect the LC team to do a major 
architectural reset to address the issue. I have added a note to my bug 
submission suggesting a small note in the documentation for the 3 anomalous 
buttons noting how they behave slightly differently on a Mac, thus turning a 
hidden bug into a documented feature.

Neville


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

What a very kind thing of you to say. Thank you.

After 30 years as a recipient of so much wisdom and lore shared with me, 
I've felt compelled to share some of that forward. In recent years most 
of what I write seems ignored, so I've been spending my time elsewhere. 
Your encouragement may see me checking in on LC stuff more often. Thank you.


--
 Richard Gaskin
 Fourth World Systems


Craig Newman wrote:


Richard.

So glad to have you in this world.

Craig


On May 7, 2022, at 5:35 PM, Bob Sneidar via use-livecode  wrote:

Well put. I wonder what the real world effect of the order of messages is, and 
whether or not it could be compensated for by send in time?

Sent from my iPhone


On May 7, 2022, at 13:44, Richard Gaskin via use-livecode  wrote:

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.


Background:
--
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 been selected.

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.



The Here-And-Now:

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

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 

Re: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

Neville Smythe wrote:

> My use-case was as follows. I have a pulldownmenu, not an application-
> wide menu, which applied to only certain selected items in a field.
> On mouseEnter, the selection changed colour, as a visual cue to the
> user that these menu items could be applied to the selection. On
> mouseLeave the colour changed back. At some point I inadvertently
> added a line of code to the mouseLeave handler which had the effect
> of killing the selection; this line was supposed to go into the
> menuPick handler. On my Mac the app continued to work as intended,
> but on a user's Windows PC the effect was to change a very minor
> cosmetic difference into a major bug because the menu no longer
> did anything. This was quite difficult to track down.

Thank you for that description.  Just to make sure I understand this, 
the menu button in question is on the card and does not appear in the 
menu bar, is that correct?


I think what you're seeing there is a side effect of the special 
handling LC uses for Mac menus, using OS routines rather than internal 
routines which emulate menus from temporary stacks. On Mac it seems the 
engine is suspending other mouse messages while it lets the OS handle 
the popped up menu, whereas on other platforms the normal mouseLeave is 
happening as soon as the mouse leaves the menu button.


At the moment the only solution I can think of is a bit kludgy, but 
seems to work:


Use stack menus on all platforms, with a timer to track when the menu 
stack has been closed.


It takes more to explain than to demonstrate, so here's a demo - feel 
free to ask any follow-up questions:


http://fourthworld.net/lc/MenuMessaging.livecode


If you want to make the stack menu look less kludgy you could embrace 
the kludge: add a preview pane or other elements that clearly show this 
is a non-standard menu, but in a good way. :)


I sometimes use stack menus for graphical pickers. They're kinda nice 
when you need 'em.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Re Pulldownmenu button bug on Windows

[Craig Newman via use-livecode]

Richard.

So glad to have you in this world.

Craig

> On May 7, 2022, at 5:35 PM, Bob Sneidar via use-livecode 
>  wrote:
> 
> Well put. I wonder what the real world effect of the order of messages is, 
> and whether or not it could be compensated for by send in time?
> 
> Sent from my iPhone
> 
>> On May 7, 2022, at 13:44, Richard Gaskin via use-livecode 
>>  wrote:
>> 
>> 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.
>> 
>> 
>> Background:
>> --
>> 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 been selected.
>> 
>> 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.
>> 
>> 
>> 
>> The Here-And-Now:
>> 
>> 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 another.
>> 
>> 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 

Re: Re Pulldownmenu button bug on Windows

[Neville Smythe via use-livecode]

Thanks Richard for your wise observations.

As cross-platform developers we do indeed need to be aware of differences that 
will arise in standalones because of GUI differences in the operating systems – 
different placement of menus, different text string lengths, some features not 
even being available. These things are largely well-known and documented with 
warnings. 

But I contend this problem is something different. Here the order of processing 
user events from an LC object is different. Although this may indeed be an 
artefact of the way the LC button menu objects are implemented, I don’t think 
the developer could be  expected to expect this, and to my mind that makes it a 
definite bug. If it occurred with more common event pairs, LC coding would be 
much more difficult.

I am not actually fussed which processing order is accepted as “correct”: 
although I expressed an IMO preference for the order as implemented on a Mac, 
the case for the opposite order is at least as strong.

My use-case was as follows. I have a pulldownmenu, not an application-wide 
menu, which applied to only certain selected items in a field. On mouseEnter, 
the selection changed colour, as a visual cue to the user that these menu items 
could be applied to the selection. On mouseLeave the colour changed back. At 
some point I inadvertently added a line of code to the mouseLeave handler which 
had the effect of killing the selection; this line was supposed to go into the 
menuPick handler. On my Mac the app continued to work as intended, but on a 
user's Windows PC the effect was to change a very minor cosmetic difference 
into a major bug because the menu no longer did anything. This was quite 
difficult to track down.

As to the priority of the bug: very low. Unless it turns to be easy to fix I 
don’t expect the inconsistency will ever be fixed even if the expert review 
agrees that it is actually a bug. Consistency of event order across platforms 
is clearly of very high importance, but this is a pretty extreme edge case, 
which only cropped up for me because of my own coding mistake. I reported it 
here because it caused me grief and I thought it of general interest. If anyone 
else is bitten and is looking for documentation, it is probably sufficient that 
the matter is now on record at least for readers of this list and in the bug 
submission.

Neville
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Re Pulldownmenu button bug on Windows

[Bob Sneidar via use-livecode]

Well put. I wonder what the real world effect of the order of messages is, and 
whether or not it could be compensated for by send in time?

Sent from my iPhone

> On May 7, 2022, at 13:44, Richard Gaskin via use-livecode 
>  wrote:
> 
> 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.
> 
> 
> Background:
> --
> 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 been selected.
> 
> 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.
> 
> 
> 
> The Here-And-Now:
> 
> 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 another.
> 
> 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:
> 
> 
> 
> Looking Forward:
> ---
> Edge case or not, let's see what we can do to get a solution for 

Re: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

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.



Background:
--
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 
been selected.


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.




The Here-And-Now:

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


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:




Looking Forward:
---
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.


--
 Richard Gaskin
 Fourth 

Re Pulldownmenu button bug on Windows

[Neville Smythe via use-livecode]

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

Neville
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Pulldownmenu button bug on Windows

[Craig Newman via use-livecode]

Hi.

I will say again that the format of the forum is so much easier to work with.

I made a pulldown and two fields, with these two handlers in the button script:

on menuPick pItemName

put pItemname into fld 1

end menuPick


on mouseleave

put random(999) into fld 2

end mouseleave


On my Mac ( I will never voluntarily use Windows) the menuItem is always nicely 
placed into fld 1 after being selected. A random number appears in fld 2 nicely 
as well.

The mouseLeave handler fires immediately if I just enter the button rect and 
leave it without ever clicking the mouse to invoke a menu. Makes sense.

What I found interesting is that when the cursor is below the actual button, 
"within" the pulldown menu space, that handler fires after an ordinary menu 
selection,. It is as if the mouse has “left” the button rect by virtue of the 
menu “space” disappearing after a selection is made. Either that or LC “sees” 
the entirety of the button and the menu space as its rect.

Whatever. But that is how the Mac works. I apologize, but I see that I have 
been of no help to you at all.

Craig

> On Apr 28, 2022, at 11:25 PM, Neville Smythe via use-livecode 
>  wrote:
> 
> I have a pulldown menu button which has a menupick script and also a 
> mouseLeave script.
> 
> On a Mac, when a user brings up the menu and drags the mouse down  to select 
> a menu item (leaving the button rect but within the pulldown menu), the 
> menupick handler is invoked, and then the mouseleave handler is called. This 
> is what I expected.
> 
> However on Windows, the mouseleave script is called immediately the mouse 
> leaves the button while the user is still in the process of making the 
> selection, and then menupick is called if the user actually makes the 
> selection.
> 
> Which means standalones behave quite differently (in my app, the menupick did 
> something to a selection in a field, and mouseleave did something else to the 
> selection: the order is thus critical).
> 
> They can’t both be right, so certainly one is a bug. The Mac order is IMO 
> correct since the pulldown menu has been started by the user so the app 
> should be in a modal state until the menu selection is resolved.
> 
> Neville
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode