Access x,y coordinates in the field of a graph in a page of a tab control. I would like to understand how it's done.

[3d0g]

I was met with a surprise when I found that what I did with a simple x-y graph couldn't be done with a graph in a tab control.  I'm frankly puzzled with what's happening.

I used a method (invoke node) of the graph to map coordinates to x-y inside an event structure that has been gradually growing and growing as features have been added, step-by-step, but I was met with a surprise when I lost all access to my FP controls even before arriving at the second event structure containing the invoke node.  Yet when I played with this same invoke node operation with just a simple x-y graph dropped on the FP I had no issue.  I moved the mouse around and the x,y coordinates were displayed to me just fine.

I've come to the conclusion that the issue is the tab control.  Troubleshooting further I found that all I need do is add the mouse move event (for the x-y graph) to the second event structure and I lose all access to the FP controls, even when that part comes well before, dataflow-wise.  (It's all in a state machine, and that state hasn't even yet arrived!)  Delete the newly added mouse-move event and all is well again.  This has to be about the fact that the graph is in a tab/page of the tab control.

I've been hunting, but I haven't yet found the magic document to explain to me 1) what's going on, and/or 2) how to access this graph control in the tab.  I did find a vi (LabVIEW-included: acquire input data) that allows me to access mouse coordinates, sort of, but I don't like it, not yet, for this operation.  (It saw it sometimes and didn't others, and never worked inside the field of a graph.  I'd much rather understand how to get this other option to work, since it worked so well when it's just a graph on the FP.)

Thank you.

[3d0g]

In case it wasn't clear, what I want is the live mouse coordinates inside the field of the x-y graph on the page of the tab control.  (It's likely any graph would have the same solution, but I'm using the x-y.)

[altenbach]

Graph properties should not depend on tabs. If you want help, please attach a small VI that demonstrates the problem.

What is the "Second event structure"? How many do you have?

[3d0g]

Thanks for the response.  It's that "small vi" part... I have to think about how to do that.

However, it's nice to hear graph properties should not depend on tabs.  That tells me it's my error, somehow.  That's at least something.

But to explain a little more, there are two event structures being used.  The first is the event loop that gets the file choice from a list box.  Once the file is had it is processed (in another state of the state machine) to create a graph on a page of the tab control.  Then the second event loop is entered (via another state of the state machine) that allows manipulation of the range of the graph control and also includes a stop option that exits the vi execution. if desired.

It's in the second event loop that I want to access the x,y in the field of the displayed graph, but I've found, like I said, that I lose access to the FP controls, entirely, when I include the mouse move event in the loop -- there's no way to select the file of the list box, for instance. (??) The cursor just rides around on top of everything and nothing is clickable any more.  ...simply from adding that mouse move event case, later!  It's truly bazarre, to me at least.  However, I still have much much much to learn of the power in LabVIEW.  I've barely scratched the surface, relatively speaking.

[3d0g]

Currently I'm trying to use the Pages property of the tab control to drill down to the graph, maybe get at it from that direction without breaking my otherwise well functioning vi.

Seriously, I am a novice, but I learn more and more the more I practice.  ...I only recently discovered that I could even get the mouse coordinates much less map them to the graph's displayed data!  

[altenbach]

---

@3d0g wrote:

Seriously, I am a novice, but I learn more and more the more I practice.  ...I only recently discovered that I could even get the mouse coordinates much less map them to the graph's displayed data!  

---

Obviously you have mistakes and we can easily point you in the right direction once we see a simplified version of your code. Since there a re millions of possible problems, we cannot narrow it down without seeing code.

• What is the "pages property" and why is it needed?
• How many evet structure and independent loops are there?
• Why do you call the "event loops" (what is that?) "first and second". Do they run in parallel or is there a data dependency? Could it be one of your events locks the panel and cannot execute because of dataflow issues?
• What is the code architecture? What are the data dependencies?

[3d0g]

I know you (plural) really want to see code.  If that's what hampers my getting assistance, then so be it.  I'm interested in understanding more about how LabVIEW works, how it works.

I have a graph control, and that graph control is in/on a page of a tab control consisting of four tabs.  (I hear they're not called tabs.  Rather, they are called pages.)

The tab control hosts pretty much everything.  One tab/page configures; it is here where the folder path is set up, the folder path used to create the list of files in the listbox.  The listbox is outside of the tab control; instead, it's on the FP itself.  The next tab displays a function f(t) in a graph.  The third tab displays the Fourier transform of f(t), F(f); it's actually broken into two graphs, one for magnitude and one for phase.  The fourth (and last, for now) tab is a save option, such that the f(t) and/or the F(f) can be saved, if desired. 

The whole vi is a state machine.  In the state machine two of the states contain event structure loops, as explained earlier.  I'm finding adding this one event to the second event structure is killing all my FP controls and I'm trying to understand what I'm looking at, how that could be possible.  There must be some linkage.

At present I've drilled to "CtlsOnPage", an array of control references, where one of the references must be the graph control I want.  I figure worse come to worst I'll just end up killing all my FP controls, again, even using this "Pages" approach.  My thought is somehow LabVIEW knows when it's in the field of the graph vs somewhere else on the FP; hence, I should be able to get to the coordinates inside the field of the graph in/on the tab of the tab control on the FP.  It seems it's just a matter of drilling in the correct direction to find the gold.  

[altenbach]

It really seems to me that your multiple event structure cause a deadlock due to complete misunderstanding of dataflow and events.

Sorry we cannot help without seeing the basic architecture.  You are on your own and no number of paragraphs can substitute for what we need to see.

• a graph is typically an indicator, not a control.
• You should not need any control reference. You are digging in the wrong place!
• We still don't know what an "event structure loop" is. You should have one outer loop and exactly one event structure. The code should not even need to care what the current tab is. Just program it as if everything is not even tabs. The can be used just to organize the front panel, no need to even connect the tab terminal to anything

[3d0g]

The problem is I'm incorrect in terminology.  Yes, the graph is an indicator.  I call it a control, something of which I can send input or receive data.  For instance, I can send it a starting point and an ending point over the domain of the function I am plotting, via a property node.  I can also call functions/methods on this control that'll get me the coordinates, namely the method I mentioned earlier.  The graph is an object, ultimately.  Somehow I need to dig into the object to get its members.

In a nutshell, dataflow is simply you can't do X until it has the data available that is needed to do X.  ...and it'll use that data if it has it, even though you didn't know it had it.

An event structure loop is just that, a loop.  An event structure goes inside a loop.  There must be a loop that runs such that the events inside are detectable.  Basically you sit in the loop until you want to leave.  Therefore, you'd better provide a way out, such as sending a false to a continue if true sitting in the outside while-LOOP.  Again, this is about terminology.  An event structure must be inside a loop.  It seems perfectly reasonable to me to call the thing an event structure loop.  Here I'm using two separated event structure loops, separated by states (called cases) of my state machine.

It's just bizarre that an event loop addition later (dataflow-wise) has locked me out of the controls on my FP.  I'll need to go clobber it again to be sure (as I said, I can turn on and off the clobbering at will), but perhaps there's a clue in the crosshair cursor I get.  My mouse pointer is the typical arrowhead, and I use this arrowhead to select, for instance, the strings in my listbox.  When this thing croaks my arrowhead becomes a crosshair.  I think that's a clue to what's going on.  (I use the crosshair to punch my LabVIEW emergency stop/abort, cince my vi's gone to lunch.)  Now the question is what is that crosshair?  Where did that come from?  Does LabVIEW exhibit different cursors under various circumstances?  I didn't know that!  But now I go off searching some more.

[3d0g]

The above shows one state inside the second event structure loop.  The state of the state machine is "get input" vs the "get f(t)" state that happened earlier.  I just sit inside "get input" unless I need to leave to redraw my graph (the state is "plot X(f)", because, for instance, I've changed the range (actually it's the domain of) f, frequency, for my function.  (The Fourier transform is a function of f, frequency.)

I wish I could make that picture larger (easier to read,) but I don't know how, yet.