Jump to content

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

Neil Pate

Recommended Posts

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 by Neil Pate
Link to comment

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 by dadreamer
  • Like 1
Link to comment
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.

Link to comment
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 by dadreamer
Link to comment
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 by dadreamer
Link to comment
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 by dadreamer
  • Like 1
Link to comment
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.

Link to comment

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 by ShaunR
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.