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.
![Screen Shot 2016-07-08 at 18.49.13.png Screen Shot 2016-07-08 at 18.49.13.png]()
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:
![Screen Shot 2016-07-08 at 18.56.33.png Screen Shot 2016-07-08 at 18.56.33.png]()
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:
![Screen Shot 2016-07-08 at 19.10.39.png Screen Shot 2016-07-08 at 19.10.39.png]()
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.