Controlling Cursor - Plot order

[DonRoth]

For example, on a waveform graph, is there any way to place a cursor so that it shows up behind a plot (i.e. the intersection of the cursor and the graph would show the graph color rather than the cursor color)? Or stated another way, is there a way for for cursor to have transparency where the intersection occurs?

Thanks,

Don

[DonRoth]

Let me provide a little more background to this issue.  In LabVIEW 7.1, one can simulate the above-described behavior using 'none' for point style and 'lock to plot' option.  In LabVIEW 8, I adjusted my application to take advantage of the new 'Cursor Move' event. However, the cursor lock style property is gone and replaced with a cursor mode property. I am toying with this 'new' property but do not seem to be able to achieve the effect I need. My application will work as it is supposed to if cursor is set to 'free dragging,' however in this case the cursor overlays the plot (and I want plot to effectively overlay the cursor).  If I attempt to lock the 'Start' and 'End' cursors to plot (using 'single-plot' and 'plot' mode options?), the application will not allow cursor movement as needed.

Sincerely,

Don

[Jason King]

Hi, Don.  I'm sorry about any confusion with the change in cursor lock styles in LV 8 - that was my doing.  No behavior was lost, we just re-categorized things a bit, mainly to allow for the new cursor type introduced for the Mixed-Signal graph.  If you set your cursor to "single-plot", and select the plot you want it locked to, it should behave as you want - it will move along the specific plot and can only exist where there are data points on that plot.

The way we draw cursors has not changed at all, as far as I'm aware. If you set the same cursor properties - point style, etc, you should see the behavior you saw before.  I believe we have always drawn cursors over top of the plots, so anytime the cursor intersects a plot (either with the point or the vertical and horizontal guides/lines), the cursor will draw over the plot.  There were new properties added to the graph (in 8.0 I think) that allow you to render picture data in between the grid lines and the plots, which would allow you to draw whatever you wanted behind the plot so that it doesn't obscure the data.  Of course, this solution will require more programming to get the behavior that cursors give you.

J

[DonRoth]

Well as I stated in my clarification post, I attempted to lock the cursors to plot using 'single-plot' and 'plot' options but the application does not then let me consistently even move the cursors.  Furthermore, when I look at the cursor properties, it has changed from 'plot' to 'window'.  If you can, give it a shot, first testing my application as is, and then locking the cursors to the plot followed by running again.  Tell me what your experience is.

Now Jason I am going to cut you some slack because I think the event structure was your implementation and it is one of the more significant advancements to LabVIEW!!  I was waiting for that for many years.

I am going play with the new draw properties soon.

Sincerely,

Don

[Jason King]

Hi, Don. I do appreciate you cutting me some slack, and I was one of the two primary developers for the Event Structure.  I had downloaded your VI and was playing with it, but got distracted by lunch. I am attaching my version of the VI, which seems to work fine, but I'm not exactly sure what behavior it is you feel is missing.  Is the whole window supposed to move when you drag one of the cursors?  If so, the code is not written to do that - instead it seems like it will grow and shrink the window.  Unfortunately, you cannot override where the user's mouse puts the cursor (Cursor Move is not a filterable event).  What I'd suggest is moving the opposite cursor (start if they're dragging end, and vice-versa) to the same location as the one they're dragging if they try to go beyond the other end point.  Does that make sense?

J

[DonRoth]

Well here is how it is supposed to work.  If you move either of the end cursors, the window as denoted in red overlay shrinks or expands as it should.  Moving the middle cursor keeps the window width the same. Try that with my original posted code and you will see it works perfectly (except the cursor overlays the plot). Sorry I did not explain this better.

At some, with your example (cursors locked to plot), the plot gets confused and the window collapses as the cursors collide and get stuck.  Not sure how else to explain.  Will look at your further suggestions if they are pertinent.

Sincerely,

Don

[Jason King]

I guess the point I'm making is that you can't stop them "collapsing" on top of each other by modifying the position of the cursor the user is dragging.  The user interaction will always win out against any programmatic changes to the location of the cursor.   So, to avoid this from happening you either need to move the cursor that the user is not actively moving, or discard the "Cursor Grab?" event and do the cursor movement yourself by watching for Mouse Moves.

J

[DonRoth]

I think I am doing exactly what you suggest. If you look at my block diagram, I am generating an event based on cursor movement.  I am programmatically modifying the cursor position(s) of the cursors NOT being moved by the user.  So for example if the middle (Move) cursor is moved, the start and end cursor positions are changed programmatically.  If the start or end cursor position is changed, only the Move cursor is programmatically changed.  This behavior allows shrinking, expanding, and moving the window.  So I do not think I am running into a situation where user interaction and programmatic changes are operating on the same cursor.  Again, with cursors in the free drag mode, the code operates perfectly.  Maybe I am misunderstanding some additional behavior the cursors have in the 'locked' mode and I have to set the ones I am interested in moving programmatically to free drag, then alter their positions progammatically, and then relock to plot?  I am thinking this is what might need to be done in a serial fashion.

Sincerely,

Don

[Jason King]

Hi, Don. Sorry for the delay - I didn't have too much time to look at this closer, but this is what I see:

1) It is possible for the user to collapse the window on itself.  When start cursor is >= end cursor, you try restoring the cursors back to their previous location.  This won't work because the user is actively dragging one of the cursors - as soon as the OS gives us a mouse idle event or the user moves a single pixel the "invalid" state will happen again. I think your best bet is to let the user move whichever cusor they're dragging, and you should just move the one they're not (either start or end) to ensure at least a "small" window.  However, I'm not sure the point of your application.

2) In the VI I attached above, there does seem to be an issue when you interact with the "Move" cursor.  The reason for this is a build up of error terms.  With cursors that are "locked to plot" (as it used to be called in 7.1), when you write the "Cursor X "or "Cursor Y" properties, we snap to the closest data point to those (X,Y) values.  Your method of computing where to place the start and end cursors (taking the current position of the Move cursor and adding/subtracting half the distance between the cursors) is compounding the error term.  Prior to some version (7.0? 7.1?  I don't know, they all blur together for me) we used to ignore the writing of these properties (Cursor.X and Cursor.Y) if the cursor was anything other than free.

Hopefully this all makes sense. If I have time later today I'll try to modify the VI to get the behavior I think you want, but I can't guarantee I'll have time to do that.

J

[DonRoth]

No problem Jason, I am tied up with another problem today and was going to get back to this soon......Don