Control key vs right mouse click: Pros & cons?

[stam]

I say uncommon because i suspect the vast majority of 'normal' mac users wouldn't even know you can do this, let alone how to.
And if you the demographic you describe then the consequences should be clear, so again it's a non-issue...

Personally i don't bother - i use multiple platforms out of necessity and have never felt the need to remap control and command. My biggest issue is the actual key mapping (in particular the @ and " are on opposite keys on UK Mac keyboard vs Windows keyboard - ie shift-2 on Mac gives me @, but on windows gives me ", and what gives me " on mac gives me @ on Windows). That always catches me out when i start using a particular platform, but again i can't be bothered remapping the whole keyboard for things like this...

[richmond62]

UK Mac keyboard vs Windows keyboard

Indeed; I stick to US keyboard layouts for everything.

[jacque]

Just from a UX point of view, I can't remember many times when right-clicking produced anything other than a contextual menu. I do remember apps that would change button labels when a keyboard key was held down, and that gave the user visual clues that something different would happen. Without a visual cue, or at least an intentional extra step like depressing a key, the user may experience something unexpected.

There's something to be said for standardized behaviors.

[RCozens]

Thank you all for sharing your thoughts.

My first mouse was attached to a Mac. I didn't own a multiple-button mouse until about three years ago, and have never used the right mouse button except to rename a file in Windows. So I wanted to tap others' experience before committing. Having now converted six button scripts with control key options to right click options, I am happy with the result.

Some of you asked what my objective was. I wanted a means of allowing the user to modify a button's response to a mouse click. Example: when a user selects Serendipity Editor's "Mask Color" & "Pen Color" buttons with the left mouse button, the Ask Color dialog is displayed. If the button is selected with the right mouse button, the script waits for mouseDown and sets the color to the color of the pixel under the mouse.

One further note: an example script posted was triggered by mouseUp. I could not get this to work. I have to capture and store the button(3) status on mouseDown and check that status on mouseUp. That seems logical to me: you can't check if the mouse is down on mouseUp. This makes scripting a little more complicated than checking eventControl status on mouseUp but simplifies the user action required to accomplish the task.

Cheers!

[stam]

One further note: an example script posted was triggered by mouseUp. I could not get this to work. I have to capture and store the button(3) status on mouseDown and check that status on mouseUp. That seems logical to me: you can't check if the mouse is down on mouseUp. This makes scripting a little more complicated than checking eventControl status on mouseUp but simplifies the user action required to accomplish the task.

Cheers!

Except that’s not quite right

The parameter you get is tracked by LiveCode, you do not need to use the mouseDown handler to register the mouse button.

The handler listed above is correct. You may not have access to autocomplete, but it’s the default autocompletion form of mouseUp.

See here:
https://livecode.fandom.com/wiki/MouseUp

[RCozens]

I see the light!

Had I read the examples more closely I would have realized LiveCode passed the button number with the mouseUp message. Thanks for correcting me.

[RCozens]

Morning All,

I have one more thought to offer. When I set out to change my handlers to capture right button status ("RBS") at mouseUp, I realized that, in my present design, it was better to capture it on mouseDown.

Most of my buttons do little more than send a message somewhere else (the card for the Image Editor and the pixel display group for the Icon Editor). So were I to capture RBS on mouseUp, I would need to modify all the handlers that check RBS to recognize a new argument,

My conclusion: If one's mouseUp handler does all the work then capture RBS on mouseUp; if, as in my case, the real work is done in another handler then capture it on mouseDown. This only happens for buttons whose actions are modified based on RBS, and if the mouse is dragged off the button before mouseUp no harm is done because the next mouseDown on a button that checks RBS will reset the status variable before initiating the handler that checks RBS.