MouseColor working incorrectly in standalone

[thatkeith]

I have a very simple LC tool that uses mouseColor to tell me the precise RGB colour (and then works out the hex value) of what I point at. This works as expected running as a stack in LiveCode (9.6.13 and 10.0.1 RC3), but when I generate a standalone that gives me quite different results.

The relevant code is very straightforward:

Code: Select all

put the mouseColor into tSampledColor
set the backgroundColor of me to tSampledColor

Any thoughts?



k

[dunbarx]

Hi.

I am not sure what you mean.How is the mouseColor function invoked? What changes or fails in the standalone?

I made a stack with some colored controls, and used the "mouseMove" message to track the mouseColor. Works, no surprise, just fine in both environments. But I am sure you are doing it differently.

Craig

[thatkeith]

I'm doing it very simply: I put the mouseColor into a variable, then set the backgroundColor of the card to the variable. (Slotting it into RGB values and the hex calculation come afterwards so that's not relevant.)

It does work as a stack in LiveCode but not when run as a standalone. Did you try that?

[Klaus]

Hi Keith,

I'm doing it very simply: I put the mouseColor into a variable, then set the backgroundColor of the card to the variable.

yes, we can see that from your first post.

What Craig wanted to know is, when/how do you "get" the mousecolor?
"on mousemove/mouseup/mouseenter/mousedown"?

There are currently three bug reports concerning "mousecolor", maybe one applies to your problem?
https://quality.livecode.com/buglist.cg ... _id=112479

Best

Klaus

[thatkeith]

Ah, yes, thanks Klaus. I was in a coffee shop and read the post rather quickly. Mea culpa! I hope this clarifies things...

It's very interesting reading those old bug reports (and seeing my comments in there) but this doesn't seem to be quite the same thing: it works correctly in the LC environment but not in a standalone environment, at least given my specific case. Here's how I'd using it:

Code: Select all

on idle
   if the optionKey is down then
      put the mouseColor into tSampledColor
      set the backgroundColor of me to tSampledColor

It's not exactly a serious bug in stability terms, but that there's this right/wrong behaviour difference between the LC and standalone environments is still a tad concerning. I will try the mouseMove method for troubleshooting (thanks @Craig!) but at the moment it's not quite how I'd like this to work in the long run.

[dunbarx]

OK.

Thank you, Klaus

I made a stack with a colored button. I put your handler into the card script. Works fine. I made a standalone. Works fine there as well.

So, Hmmmm.

It has long been said that the "idle" message, oftentimes useful in HC where it originated, shout NEVER be used in LC unless it REALLY is necessary to. Without actually fixing your issue, can you change? Might the "mouseMove" message work, assuming that the cursor is not truly static and simply pressing the optionKey is what you require.

Another, likely better way is this. No message is sent when simply pressing the optionKey. But perhaps you could switch to, say, a function key. In that case a keyDown or rawKeyDown message would be sent, and a modified handler just like you already have would fire.

Craig

[thatkeith]

I think I found the problem!
It's a curious one, and to me it definitely looks like a bug, although a weird one...

When running as a stack in LiveCode, the mouseColor returns the colour of the pixel under the pointer. Note: the colour of the pixel that is VISIBLY under the pointer, whatever window that might be.

When running as a standalone app, the mouseColor returns the colour of the pixel from the DESKTOP IMAGE that's under the pointer. Note: this is regardless of what windows might be visibly in front of the desktop and directly under the pointer.

This means that it's effectively not working as presumably intended: for getting the colour value of anything that is shown on the screen.

Weirdly, when I get the colour of the macOS menu bar it returns what seems to be correct, BUT the only menubar items that are detected are the Apple logo and the app name itself (and presumably other app menu titles if there were any). All the items on the right of the menubar are ignored, just like app windows are ignored.

Could someone please sanity-check me? I would much rather be wrong here.

[thatkeith]

Another, likely better way is this. No message is sent when simply pressing the optionKey. But perhaps you could switch to, say, a function key. In that case a keyDown or rawKeyDown message would be sent, and a modified handler just like you already have would fire.

Thanks Craig! I am indeed an old fart that started with HyperCard in the 80s, then SuperCard for a long time. I generally avoid using idle for anything significant and often consider changing the idleTicks to reduce the load when I do use it. I still think that the option/alt key feels more natural in this slightly unusual use case, but I've changed the method to rawKeyDown and the Return key. That seems fine in my brief tests, and I do appreciate the nudge towards better (more responsible?) coding.

k

[thatkeith]

SOLVED: it's about permissions, specifically the app needs to be added to the 'Screen & System Audio Recording' list in System Settings > Privacy & Security. LiveCode is there, which is why mouseColor works for me in development.

Weirdly (or rather, logically but opaquely), because I had multiple copies of the app, even though it's in the list the one macOS considered to be authorised WASN'T the one I was trying to use! This got really confusing; I only got to the bottom of this when I deleted all apps, generated a new standalone, and went through the process again.

I suggested in the bug report follow-up comments that a note in the Dictionary about this might well be worth adding, given that it's been a frustrating head-scratcher for me for quite some time.