Event on Colour Change while widget is open, is this possible?

[Neil Pate]

I think the answer is no, but I ask anyway. Does anyone know if it is possible to access an event or some other thing that returns the colour that is currently being "selected" by the mouse cursor when this colour picker widget is open? I mean getting a new value when the user moves their mouse around while the widget is open and has focus? I suspect this is all deep in C++ land but would love to be wrong here.

Edited October 10, 2022 by Neil Pate

[dadreamer]

Even though this Color Picker window is created by the OS API, it does not expose any properties or methods to the programmer. All the window handling is done in the LV core entirely. I won't suggest using ChooseColor or its .NET wrapper as I'm pretty unsure how to accomplish the task of mouse tracking there (maybe LPCCHOOKPROC callback function could be of some use, but it would require writing a DLL anyway). It would be much easier to create your own color picker SubVI with some means of interaction with the main VI. You can find some color chooser examples on NI forums, e.g. this one.

Edited October 11, 2022 by dadreamer

[hooovahh]

I've never thought about adding this feature to my software but it seems so obvious now.  It would be nice to know the color the mouse is over as the user moves it, so it can change the color of some object as the user does it.  This almost seems like it should be an idea exchange so I made one.

[Neil Pate]

@dadreamerthis sounds like the perfect use case for some low level OS API trickery, like reading the value directly from memory. If only there was someone who was good at stuff like this 😉 

[ShaunR]

3 hours ago, Neil Pate said:

this sounds like the perfect use case for some low level OS API trickery

I disagree. There are other native solutions that won't crash LabVIEW, are cross platform and you could probably make it look much better than the LabVIEW native control.

[dadreamer]

On 10/11/2022 at 7:01 PM, Neil Pate said:

this sounds like the perfect use case for some low level OS API trickery, like reading the value directly from memory. If only there was someone who was good at stuff like this 😉 

This is possible, but totally unreliable. The Color Picker code changes the colors of the cosmetic, that is a part of the FP object (the Blinking property does that too).

VI Scripting doesn't provide a way to obtain the ref's to the cosmetic. Ok, we could use that Refnum to Pointer trick to get the object's data space pointer, but we can't go further without using constant offsets. First, we need to find the cosmetic address, second, we need to find the colors addresses. Having those we could read out the colors. It would work only if the object data space structure does not change. But it is known to change with a 100% guarantee between different LabVIEW versions (incl. patches and service packs), RTE's, bitnesses, platforms, sun and moon phases or whatever. Besides, you would have to adapt that hacky technique between the objects with different types (such as Color Box and Boolean), because their data spaces are different and the offsets wouldn't work anymore. Due to that I personally dislike to base software on internal tricks. It's often unstable and very difficult to support.

There exists an easier and documented way to get the color while the Picker is on. Just grab the object picture with the Get Image method and compare it against some initial picture to determine whether the changes are in effect.

Edited October 13, 2022 by dadreamer

[Neil Pate]

Thanks. It was just a thought.

How would I use Refnum to Pointer on the colour picker widget though? Is it even possible to get a reference to that little popup window?

 

 

[dadreamer]

49 minutes ago, Neil Pate said:

How would I use Refnum to Pointer on the colour picker widget though?

No, not on the widget, you use Refnum to Pointer on the ColorBox control reference. After that you attach a debugger and study the memory dump to find out the cosmetics pointers in the data space (if you decide to go this route).

49 minutes ago, Neil Pate said:

Is it even possible to get a reference to that little popup window?

You can get its HWND, but it's of no real use here.

Edited October 13, 2022 by dadreamer

[Neil Pate]

Yeah but I want to grab the colour while the widget is open. 

[Neil Pate]

1 minute ago, Neil Pate said:

Yeah but I want to grab the colour while the widget is open. 

Wait, does the underlying colour box update while the widget is open? 

[dadreamer]

43 minutes ago, Neil Pate said:

Wait, does the underlying colour box update while the widget is open? 

Its value remains constant (until you press the color of your liking), but its cosmetic color does update, that's why the Get Image method works, for instance, so it's possible to "catch" the moment, when the color changes, if the appropriate logic is implemented in the VI.

Basic example.

ColorBox Tracking.vi

Edited October 13, 2022 by dadreamer

[Neil Pate]

Super surprised at this result.

Run the VI and change the colour using the colour picker widget, while the widget is open the top loop which uses a property node works fine (Color Box 2 updates in real-time)!

The bottom loop does not show this same behaviour, the value is only updated to Color Box 4 when you exit the widget.

Colourbox.vi

[Neil Pate]

 

Just what I wanted, thanks for the inspiration.2022-10-13 20-30-18.mkv

Edited October 13, 2022 by Neil Pate

[dadreamer]

18 minutes ago, Neil Pate said:

while the widget is open the top loop which uses a property node works fine

Seems like a feature really 🙂 I prefer not to use PN's without a serious need, as they run in UI thread, so have not tested that. It looks much like in this case the value is copied out of the DDO instead of the intermediate buffer. One way or another... it's working.

[Gribo]

Now, some ray tracing..

[MikaelH]

 I would make my own popup, so it looks better, something this:

[bjustice]

How much to bribe you for sharing this code?

Very pretty, and cool to see good usage of the channel wire

[MikaelH]

I just have to implement it first 🙂
Not sure which UI style would be the best

[MikaelH]

Here is a start of the color selection, can someone see if we can make it faster?

ColorPicker_GUI_DrawColorRectangle.vi

[ShaunR]

The intensity graph is usually an order of magnitude faster for this sort of thing as it has in-built interpolation. Not sure it would particularly easy with the mouse-over circle, though, since you wouldn't be able to draw on it and it would be very difficult to implement non-rectangle colour maps.

Edited October 17, 2022 by ShaunR

[mcduff]

Here's a start to a speedier solution starting and after selecting a new color.

ColorPicker_GUI_DrawColorRectangle_mcduff_MODS.vi