[Bug Report] Cannot Set the Cursor Position in a Graph Precisely Enough

[X.]

I am pretty sure that what I am reporting as a bug will be re-qualified as a feature but it is disturbing to new users.

Take a graph (like the one created in the attached VI) with a plot which has too many points within the visible area to reallistically expect all of them to be identifiable/plotted (e.g. use autoscale X once), and try to navigate the curve using the cursor navigation arrows: this should work fine if you are not too nervous. The cursor will move in 0.025 increments.

If you have autoscaled the graph though, the plot should have 2000 data points displayed over an area covering 415 pixels. If you are careful enough, you will notice that occasionally, the cursor X position is incremented (or decremented) by the right amount, but there is no visible displacement of the cursor. This is particularly noticeable around the peaks and troughs of the sine curve.

So far so good.

Now that we have established that it is possible to navigate a cursor around a curve with the data resolution, we (I) would expect to be able to do exactly  the same using the cursor coordinates displayed in the table to the right.

No such chance!

Try typing 3.275 for instance, and you will see the cursor jump to 3.225. Try 3.125 and you'll get 3.100.

If you zoom the graph such as to obtain a better ratio of number of visible points of number of pixels:

things work fine. You can type any valid data point coordinate (multiple of 0.025) and get the cursor to jump there and its position staying at the value you have typed in.

The exact same phenomenon occurs programmatically.

Type a target coordinate in the X control and press Set X: it will work fine if the graph if zoomed enough (the displayed cursor coordinate will match your requested position), but if you reset the graph to autoscale, this will fail for some values (as shown below):

I can not expect my users to be willing to zoom around their target position to be able to set a cursor's position, then autoscale back to full range and repeat for as many cursors are needed in the type of application they are interested in (defining regions in a graph). I can also not expect them to delicately navigate to their target using the oversensitive cursor navigation arrows.

I perfectly understand their frustration of not being able to type in a cursor target location and observe it jump to where they instruct the software to go.

Now, I can use a trick (the Set X(*) button shown below) and obtain the effect I am looking for:

How do I do that? Simple and stupid (check the code):

- programmatically zoom around the target position

- move the cursor

- reset the graph range to the original values

Notice that there is no visual signature of these scale range changes.

So my first question is: why do I have to do that and why is LabVIEW not doing it by default?

More aggravating: since there is no Event telling me that THE USER HAS EDITED THE CURSOR COORDINATES, I cannot use the trick I described above for the most natural case of user interaction with a cursor on a high data density plot, namely when the user types in the desired cursor coordinates.

Hence my second question: why is LabVIEW not moving the cursor where it is instructed to, even though admittedly that cannot always be done from a graphical point of view (but this works perfectly well using the cursor navigation arrows)?

To me, this sounds like a bad UI choice. 

[mikeporter]

The real problem is here: "...the plot should have 2000 data points displayed over an area covering 415 pixels..."

The effect is neither a bug or a feature - it's just the way the world works. You can't have LabVIEW decimating like crazy to fit 2000 data points into a few hundred pixels AND have minute control over the cursor as well.

One way you can move the cursor point by point but the cursor doesn't move visually (well that's not right!), the other way moves the cursor by pixels and so the cursor always moves visually but "skips" data values (but wait, that's not right either!).

You are telling LabVIEW to do something that is physically impossible and it is doing the best it can to handle the request. There is no perfect solution.

Wait, I take that back, there is one solution: don't have high density plots. They also waste processing time and memory.

Mike...

PS: I first noticed this behavior sometime in the late '80s.

[X.]

This is a valid opinion and one that I was expecting to get from someone like you who has been working with LV for ages. I also appreciate the searing sarcasm tinted with just the right amount of contempt to not sound overly insulting.

Essentially you are telling me that today's users (my users) should get used to antiquated behavior because things have always been like that and pixel density is all that matters.

I will make sure I forward my users to your answer to explain to them why they can not use the graph cursors to PRECISELY enter parameters for a subsequent analysis, but instead have to use a separate control, and juggle between both. I bet they will get back to me and say: "Oh now I understand that I was stupid to try and do what I was trying to do and that everything is fine".

PS: Any opinion on the addition of colors to the graph object since the late 80's? I personally feel ambiguous about all these eye candies.

Hmm, now that I think of it, if there were no cursors, I wouldn't have any such issues...

[billko]

---

@X. wrote:

This is a valid opinion and one that I was expecting to get from someone like you who has been working with LV for ages. I also appreciate the searing sarcasm tinted with just the right amount of contempt to not sound overly insulting.

Essentially you are telling me that today's users (my users) should get used to antiquated behavior because things have always been like that and pixel density is all that matters.

I will make sure I forward my users to your answer to explain to them why they can not use the graph cursors to PRECISELY enter parameters for a subsequent analysis, but instead have to use a separate control, and juggle between both. I bet they will get back to me and say: "Oh now I understand that I was stupid to try and do what I was trying to do and that everything is fine".

PS: Any opinion on the addition of colors to the graph object since the late 80's? I personally feel ambiguous about all these eye candies.

Hmm, now that I think of it, if there were no cursors, I wouldn't have any such issues...

---

What would be useful info is to see if you can do it in:

1. At least one different language (the more languages the better - more data points - yes, that was intended), and
2. Excel plot

Then at least you have a relative comparison.  It may be that LabVIEW is being unfairly accused of something unfeasible with current technology, or it could be that LabVIEW is seriously lacking in this regard.  We can't know until we have more than one data point.  (That was intended, too.)

[X.]

I was under the impression that the ease of building UI was a selling point of LV. Referring to Excel as a parangon of advanced UI is maybe...how to put that? a joke, right?

Irony aside, there is the suggestion I posted recently regarding one of the problems mentioned in my first post:

Create a "Cursor Location Edited" Event for Graphs with cursors

[billko]

---

@X. wrote:

I was under the impression that the ease of building UI was a selling point of LV. Referring to Excel as a parangon of advanced UI is maybe...how to put that? a joke, right?

Irony aside, there is the suggestion I posted recently regarding one of the problems mentioned in my first post:

Create a "Cursor Location Edited" Event for Graphs with cursors

---

The main selling point is that it has separate icons for 32-bit and 64-bit versions.

I separated Excel from the rest because it wasn't a programmking language.  At at least it gives you a frame of reference.  LabVIEW doesn't meet your expectations in this case.  With a frame of reference we can then extrapolate whether your expectations are reasonable or not.

[X.]

As a matter of fact, I figured out that the Graph object's "bug" can be used against it:

If one zooms to a level such that the number of pixels in the display area is larger than the number of data point ideally displayed in this area, typing any valid cursor coordinate will result in this coordinate to be accepted, no matter where the cursor is located (in particular, even if the cursor is out of the displayed range).

Note: I forgot to mention (but this should have been easy to check from the attached VI) that the cursors I am talking about are linked to the plot.

If the cursor is set to be "free", then ANY coordinate is accepted (even one that cannot be resolved graphically).

In other words, a workaround (not necessarily acceptable by everyone)  is to NOT use a "single-plot" or "multi-plot" cursor.

This also means that when the cursor is not "free", LV first checks the screen resolution and then gives up (it rejects the cursor coordinate update) if the requested cursor position does not result in a graphical update. Why this is not done when the cursor is free is beyond me, since graphically, the result is identical (nothing happens).

There is one difference between a free cursor and the other types, which is that there is no need to find a matching point in the plot, and, if the X coordinate is updated, display the corresponding Y coordinate. However, in principle, none of this requires using the screen coordinate and display resolution, which to me points to a flawed implementation of the search algorithm (search of the nearest plot point).

[billko]

LOL - so what you said in your first post is true - it's a feature!  (Design decision.)

[X.]

CAR 596099 was filed by NI Support