Bug: Set active palette tool on graph does not update cursor icon until mouse move

[thols]

When the active palette tool is set on a graph and the mouse hovers over the graph, the icon is not updated until the mouse moves.

1. That's a bug right?

2. What is a better workaround than mine? I set the mouse position with user32.dll.

The attached VI demonstrates this by alternating the active palette tool. If the mouse is still, the cursor icon is not updated, but if I move the cursor, the icon updates. My workaround is activated from an enum:

I tried DeferFP updates as a workaround but it did nothing. I tried setting some other properties on the graph too to have it update, but the icon did not update.

[raphschru]

I had exactly the same problem and also ended up using user32's function "mouse_event" to force a cursor refresh.

Definitely a bug !

[l.hovs]

Hi  thols,

I tried to open your VI and run it, when workaround is set to set mouse pos cursor is changing its icon by every second, but in other cases cursor doesn't change its icon until mouse will move. If you can't reach this result, then i think it might be connected with version of LabVIEW or drivers. 

Regards)

[thols]

---

@l.hovs wrote:

Hi  thols,

I tried to open your VI and run it, when workaround is set to set mouse pos cursor is changing its icon by every second, but in other cases cursor doesn't change its icon until mouse will move. If you can't reach this result, then i think it might be connected with version of LabVIEW or drivers. 

Regards)

---

That is the expected result of the workaround. But I would expect LabVIEW to work like that without the workaround. 

[l.hovs]

Then why you still keeping the workaround Enum and case structure? You just need to remove them and keep only the set mouse pos case code. Did you try this way?

Regards)

[thols]

---

@l.hovs wrote:

Then why you still keeping the workaround Enum and case structure? You just need to remove them and keep only the set mouse pos case code. Did you try this way?

Regards)

---

The code shows the bug and a workaround for the bug. I made it like that for your convenience. It is a minimized example to show the bug in action. That's what the code is for. I already explained that I have a workaround but think that the workaround should not be needed and asked if anyone had a better one.

[altenbach]

I agree that this looks like a limitation, but it is probably avoiding a performance penalty this way. Can you explain a use case where the workaround is actually needed?

[thols]

---

@altenbach wrote:

I agree that this looks like a limitation, but it is probably avoiding a performance penalty this way. Can you explain a use case where the workaround is actually needed?

---

Yes. I have made keyboard shortcuts for the most common zoom tools, and I want the user to get the feedback that the tool is selected directly when the key is pressed. I could have extracted that code and made an example of that but wanted to make it as minimal as possible and also show that it was not related to the KeyDown-event. I'm OK with my workaround though, just wanted to see if anyone had a better one, and also post my own if anyone should come across this issue.

[raphschru]

I have a similar use case where my user can select one or several portion(s) of a curve in a graph:

By default, the user has the horizontal zoom tool to search for a specific zone of the curve.

The user can also maintain ctrl to go in a "multi-select" mode and select multiple portions (displayed in red) of the curve.

To allow the user to "click and drag" on the graph, I must switch to the selection tool.

This is where the cursor is not updated correctly.