Cursors

[Andrew Berkley]

I'm trying to control the cursors on a graph and everything works
well except:

I want to duplicate the functionality of the "Center Cursor" selection
on the Cursor Palette. What I do right now is I read the Xmin/max and
Ymin/max and put the cursor in the middle. This works fine as long as the
cursor is not set to snap to points. Problem is, if snap to point is
set to true the cursor snaps back to the original point it was at (not
the closest point to the center). I tried turning off snap to point,
then centering, and then turning it back on, but it still zips back to
its original place. Ideas?

Andrew Berkley
University of Maryland

[WNM]

See this article:
Attribute Node Cursor Locked (Snap to Point) Does Not Seem to Work Correctly

Document ID: 1FNFHJE7

�In addition to unlocking the cursor, you must also set the Cursor.Index attribute to -1. After you write to Cursor.PosX, the cursor will be moved to the nearest point on the specified plot.�

Keywords: cursor.index, snap, lock, PosX, PosY

In fact, this article is the only place anywhere on the NI web site (including the developer�s zone & forums) that I found this mentioned. This is not the first time I have thought that the little pieces of LabVIEW were less than adequately documented.

Sometimes I think NI gets so busy adding new features to LabVIEW that they don�t take the time to fully and properly document the ones that are there. It is very common to find only minimal documentation on things like this property. I realize that it isn�t easy for the developer of the new functionality to step back from the new function and think like someone who is using it for the first time; the developer is just too familiar with the function to recognize the trivial items that also need documentation. It�s also difficult to hand the function over to someone who isn�t familiar with it and ask them to explore and document it because they won�t have the knowledge to exercise it as thoroughly as the developer could so they might miss using a piece of it that needs documenting. The beta testing NI does certainly helps since the questions you get from your users at that time should indicate which areas need better explanations. Proper documentation is a tough nut to crack. The people in the best position to do it don�t want to do it, it�s not as fun as writing the code and getting it working properly. Yet proper documentation must be done if the product is going to be any good.

At the very least I hope NI has some sort of checklist that the developers can use to help them remember if there is anything special about each and every property, input, output and function that they implement. Things like default values, how they are initialized, how they are reset, forbidden values, special values, special behaviors, default behaviors and so forth. Your technical editors need to review the documentation for every item that is only one sentence, and ask if it that one sentence is really enough.