LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get the number of plots in an XYGraph via reference

Solved!
Go to solution
Highlighted

I'm looking for a way to take an XYGraph reference and extract the number of plots, such that I can iterate over 'Active Plot' and make adjustments.

 

The forum thread number of plots in xy sounded promising, but the user here wanted to get the number of entries in the Legend, not the number of plots. The first reply shows ways using Array Size to get the number of plots, but I'd like to know if it is possible without having access to the actual data - only a reference to the graph control.

 

I'm considering parsing the 'Plot Name' until I don't find a plot name that can be parsed into the format I expect, but I'm worried this isn't very robust - perhaps my reading VI runs before the VI in a separate class holding the graph, which changes the names when new data is added/removed. Alternatively, perhaps I change the naming system and don't immediately notice why things are broken in a separate part of the code. (This might not take too long to fix, but might confuse a colleague if they changed the format to suit their preference, then wondered why it all broke...)

 

In any case, I can imagine plenty of ways for parsing the plot name to go badly, so an alternative would probably be better!


GCentral
0 Kudos
Message 1 of 6
(1,245 Views)
Solution
Accepted by topic author cbutcher

Hi cbutcher,

 

this should work:

check.png

(using the value property…)

Best regards,
GerdW
CLAD expired, using LV2011SP1 + LV2017 (+LV2019 sometimes) on Win7+cRIO
Kudos are welcome Smiley Wink

Message 2 of 6
(1,241 Views)

I guessed that might work, but it requires a strict reference, right? At least, with a non-strict reference, the Value property returns a variant, and with no knowledge of the data type it can't be cast (and if I knew the data type...)

 

I'm uncertain if I've just managed to confuse myself on this topic, but I think I can only pass strict references around by carefully defining them in one place then following it through, which is fine, but seems to remove the dynamic nature I'm seeking here. 

 

Did I get it all wrong? If this is the only way to get the plot number (which it might well be) then I'm left with either ensuring I keep a strict reference, or storing the number of plots somewhere that has that information, and passing that value around my code to places that need to know the number of graphed plots.


GCentral
0 Kudos
Message 3 of 6
(1,236 Views)

Hmm. Should test before replying. Seems I can create an array of clusters of XY data, without any data, and then cast the variant Value to data, then take Array Size from there. Fantastic!


GCentral
0 Kudos
Message 4 of 6
(1,234 Views)

Hi cbutcher,

 

you didn't mention you need a "more generic" approach in your first post…

 

- when you know the datatype of your graph you can easily use a strict reference or the "Variant to data" conversion

- when you don't know the datatype of your graph you could try to guess the datatype by testing several "Variant to data" conversions…

 

But in the end: why do you need to test the graph content by its reference? Why not store data in a different manner (like FGVs)? Then it would be so much easier to really KNOW the number of plots…

(Reason: Graphs are used to display data as data sink, but you want to know a property of the data source! So you should query the source and not the sink!)

Best regards,
GerdW
CLAD expired, using LV2011SP1 + LV2017 (+LV2019 sometimes) on Win7+cRIO
Kudos are welcome Smiley Wink

0 Kudos
Message 5 of 6
(1,222 Views)

@GerdW wrote:

 

(Reason: Graphs are used to display data as data sink, but you want to know a property of the data source! So you should query the source and not the sink!)


This is a great point - perhaps I should look at that avenue instead.

 

Regarding reasoning, I've put together some code to acquire data and store it in a SQLite database. The graph reads the data from the database. I'm currently trying to implement a (probably) Multicolumn Listbox based legend, because although using the Plot Legend to toggle visibility would be simplest, I'd like to allow toggling of groups of data (e.g. all the temperature sensors, all the load cells, etc) and so I need some 'pseudo' data sources listed in my legend, to give me something to click (and then handle in an Event Structure etc).

 

Since the database holding the data can become quite large, and since the data needed for the legend is very small and changes completely depending on which datasets are loaded, I intended to create a second, in-memory database holding only some meta-data about the plots, with flags representing 'IsHeader', 'Visible' and so on.

 

Perhaps loading the main database in another connection and having a temporary table would be a better option - then if querying the source data is needed, it is more readily accessible.

 

However, in principle, the legend/overlay shouldn't depend on the data coming from a database - as I'm currently writing it, it could use any graph and provided it was told information about appropriate grouping, could show/hide plots, groups of plots, etc, whilst feeding back that information to the graph if needed (in the sqlite case, I can choose not to bother SELECTing the data that is hidden, for example, until it is shown again).


GCentral
0 Kudos
Message 6 of 6
(1,217 Views)