The waveform graph cursor legend shows name of plot currently snapped to (in snap to any plot mode), even as user moves cursor to different plot. But there is no property to read this plot name! Active Plot and Plot Name do not update as user drags cursor to different plots. I'll try to cast the cursor reference to something useful while I wait for a response.
I didn't have any luck casting references. It seems pretty ridiculous to me that I can't programmatically discern which plot a cursor is snapped to! And this is only test code, with an event case registered for cursor events. If I don't grab, release, or move the cursor NOTHING happens in this code; it will sit and wait forever for one of these things to happen. The graph's cursor.plot has to be -1 in order for the user to be able to move the cursor from plot to plot; and cursor.cursormode has to be 1 (single plot) in order for snapping to happen. There's another mode to this test code that lets the user "change datae" by clicking and dragging the cursor, tracing the new data; this involves changing cursor.cursormode to 0 (free) while changing the data (of the last-snapped-to plot, which I can't determine programmatically) for the x-axis range covered between cursor move events. All this works fine for a single plot, but not for a graph of multiple plots since there's no way to determine programmatically where a cursor has snapped to.
I suppose I could search all plots' datasets for the coordinate values that exactly match the cursor coordinates, just hoping there never comes a plots intersection exactly at a point on the x-scale that is an integer, since then I could not be certain of identifying the correct plot. But why should I have to do any of this, when the graph control obviously knows which plot it is snapped to??! The only reason I can think of for LabVIEW not making this info available is that the same info is already available by some other route that I can't see--or it's a bug.
What about the cursor.plot property?
Thank-you for taking the time to reply, Ravens Fan. I, too, thought cursor.plot should provide the required information, but, as I mentioned, I needed to write "-1" to plot in order to give the user the ability to move the cursor from plot to plot while snapping to plot as he did so; but cursor.plot would then read "-1" all the time. What I've done to solve the problem is write a "1" to plot when the user releases the cursor (since he has to do so to click the button that changes operation to my "change data" mode where I free the cursor and modify the y-data of the last-snapped-to plot at the cursor's location); this restores the proper functionality of cursor.plot so I can save the plot index to a shift register.
This does work for me in this application, and it's probably the only way for the cursor.plot property to work. BUT, I should also have been able to get the info I needed right from the cursor itself since that would update properly before I implemented my work-around. Look at the front panel screen shot that you so kindly included and you will see, in the Cursor list box, below the cursor name, the line, "Plot 1 28 28". I wanted to read the "Plot 1" part of that line, but there is no way I could find to do so. I'm still interested to know how to do this, for future reference. I just find it so odd that, with all the properties available, this one would be missing!
Thanks, again, Ravens Fan.
Actually you can get the plot's name just like Ravens Fan described, by reading the Cursor.Plot -attribute - then feeding it into ActivePlot and reading the PlotName. This seems to work even if you have entered previously the value "-1" for Cursor.Plot for snapping your cursor on multiple plots. I have used the same trick in my own application and it's working for showing dynamically the active plot's name every time the user is "surfing" through multiple plots with the cursor.
There are some problems with this though. For example, I can not center the cursor in the middle of the graph on active plot when it has this "-1" value on Cursor.Plot -attribute.
Thank-you for taking the time to reply, Ravens Fan. I, too, thought cursor.plot should provide the required information, but, as I mentioned, I needed to write "-1" to plot in order to give the user the ability to move the cursor from plot to plot while snapping to plot as he did so; but cursor.plot would then read "-1" all the time.
I'm not sure why you would say that. What version of LV are you using?
That was one of the things I checked out and I was looking for the property. I found that when you dragged the cursor, it would easily snap from one plot to the other without doing anything special. I didn't do it in the previouis snippet, but wrap the reading of the property node in a while loop and put a stop button and wait statement in there so that when it runs, you can see the cursor index update and the cursor snap from one plot to the other.
You cannot move the cursor from one plot to another unless it's single-plot (free and multiplot are the only other choices, and if it's free it doesn't snap, right?) mode AND the plot property is a "-1". Try it. I'm using probes and an event case in a while loop (but without a stop button and wait "statement"/primitive ). That's how I know it's "-1", until I implemented the solution I mentioned above.
I reproduced your test code (complete with stop button and wait) and got the same results you did, as expected. The problem with test code is it rarely does anything useful. Try reproducing my case by putting a case structure in your test code wired to a "free" boolean; in the false case put a "1" wired out to a Cursor.CursorMode property and a "0" wired out to a Cursor.Plot property; in the true case put a "0" wired out to the Cursor.CursorMode prop and a "-1" wired out to the Cursor.Plot prop. With "free" = False you won't be able to snap to any other plot; with "free" = True Cursor.Plot will, of course be a "-1", no matter where it is, since it is "free". Bear in mind that I need to give the user the ability to select a plot, click a button, then change that plot's data by clicking and dragging the cursor (the data at the cursor's x coord changes to the the value of the cursor's y coord); when the user clicks the button to change back to the "don't change data, just select a plot" mode, the cursor needs to snap to its current location, which is the last changed data point of the plot that he just changed the data of. If you can come up with an alternative solution to mine, I'd love to hear/see it!
But my real point, since I found a viable solution to the immediate problem, is that there is cursor information presented to the user in the cursor list box that I can't get at programmatically! And this is info I could have used to solve my original problem! I don't understand why NI wouldn't have made a property for it like they have for other, much less useful, bits of info.
"But my real point, since I found a viable solution to the immediate problem, is that there is cursor information presented to the user in the cursor list box that I can't get at programmatically!"
But you can get at it programatically if you use Cerati's message if you take the index and to determine the plot's name.
You're problem is really becoming much more sophisticated than what you had discussed originally. Since you are trying to use the best features of one kind of cursor, then use the best feature of another cursor mode, and this and that, and back and forth, you are going to have to build a sophisticated program to handle all of these variations and requirements that you want to have.
At your urging I tried that little bit of magic and it failed with an error (invalid parameter)--I guess it didn't like that "-1".
You're problem is really becoming much more sophisticated than what you had discussed originally.
Actually, if you look back at the second post of this topic (I thought the topic post might have lacked detail), I did describe the scope of my problem/application, only in somewhat more compact language than just recently.
Since you are trying to use the best features of one kind of cursor, then use the best feature of another cursor mode, and this and that, and back and forth, you are going to have to build a sophisticated program to handle all of these variations and requirements that you want to have.
All I'm trying to do is accomplish my user interface goal--and I have, as I explained earlier, very simply and easily, as it turned out, once I understood what was actually happening in my code from a LabVIEW perspective. One prop node in the right place with the right value was about all it took! The most difficult part was accounting for the data between horizontal pixels since there was more data being plotted than there were pixels to represent it, but still not much to it. I've been programming in LabVIEW for almost 20 years now--since it came out for Windows (V2.5.1). Back then NI's tech support was totally customer-oriented--effective and a pleasure to work with. There was no "pay us $3500 a year for phone support or go fishing in the forums for your answers" non-sense, like today. Anyway...
I suspect there is no "documented" way to programmatically access all the contents of the fp Cursors List box; it "fell through the cracks" as it were. My advice to you, Ravens Fan, if you're still polling user controls is forget about it and come up to speed on the event structure and dynamic events registration for your user interface coding. You won't regret it.
My advice to you, Ravens Fan, if you're still polling user controls is forget about it and come up to speed on the event structure and dynamic events registration for your user interface coding. You won't regret it.
Well, I haven't been using LV for nearly 5 years and putting in over 6000 posts on these forums without learning a thing or two about how to use event structures.
If you've been programming in LV for 20 years now, I'm surprised you haven't participated in the forums before yesterday.
I don't think you are the only one who has some complaints about the way cursors are implemented in LV now. Some longer time users than me can tell you about their issues with it. I think the change occurred between LV 7.1 and LV8.0. I had initially started working with 7.1, and it wasn't long after that I upgraded to 8.0. So I don't have much experience with the older version of cursors, though I do remember seeing the changeover.
If you have time, search the forums for commentary threads about the old cursors vs. new.