How to obtain the data type of a XY Graph

[X.]

A XY Graph containing plots consisting of arrays of coordinates will not accept plots consisting of arrays of points or arrays of complex numbers, and inversely:

Therefore, it makes sense that a VI that accepts a reference to Graph 1 will not accept a reference to Graph 2 or 3 above:

unless the datatype is removed from the reference control:

resulting in coercion dots in the code, but no broken wires anymore:

The problem with that is apparent in the subVI:

The reference doesn't contain any information on the datatype of the Graph! You would need to pass additional information to the subVI, as there is no way to guess which type the data is (and what to convert the variant into), unless you do some manipulations such as this:

This if of course for single plot XY graphs. Things become a bit more complicated if you want to handle multiplot XY Graphs (which you generally want)...

Now, you are still not done yet if you want to access the graph's data, as you still don't know the numeric type of each component of the plot. X might be a double precision floating point number, while Y could be a 32 bit integer (think of an histogram), but both could be unsigned integers or a mixture of extended precision and something else. Casting the Graph's "Value" variant into, say, X and Y DBL might result in undesired effects.

Of course, you could write a polymorphic VI with as many XY  Graphs refnums as there are combination of plot types and coordinate numeric types. That's a lot of combinations...

Short of an XNode (not officially supported and not exactly trivial to design, from what I understand), or a Macro (same remark), I am missing a simple way to figure out the plot type of a XY Graph control in order to be able to manipulate the data adequately.

Is the path I have started to explore in the snapshot above the only way, or is there a more elegant approach? 

[Logan_K]

I guess what's unclear to me is why you think you need to handle all three of these different datatypes from the same function. Typically if the datatypes are fundamentally different, I would handle them with fundamentally different functions. If I want to first transform them to be the same, then I would first have three different functions to transform the XY graphs into the same datatype, and then use a common function for the processing.

You could consider approaching these graphs in an object-oriented way by creating a "Graph" parent class, and then 3 child classes for the 3 graph types you are dealing with that store the reference to the graph as private data. Then you can handle the graph-specific data in the functions and return generic data in the shared top-level function.

[X.]

Fair question.

In fact I started designing a polymorphic VI (so many VIs doing pretty much the same thing with different data types), until I realized that assuming 3x2 graph types was woefully insufficient, as an I32 plot Graph doesn't have the same kind of refnum as a DBL plot Graph, and therefore I needed to remove the data type from the refnum. But then I lost everything (graph type, not only plot numeric type), resulting in the question I asked.

Casting the Graph's Value to a common data type (having only the generic reference to the graph) requires the kind of information I am looking for (if you want to cast data safely - for instance, AFAIK, you cannot cast I64 to DBL in a lossless manner. So I would have to cast everything to EXT, which might be a waste of memory space if I am dealing with U8 plots, for instance).

I can get what I need along the lines of what I already showed, but this seemed a bit convoluted. I was hoping that I was missing something trivial.

[Logan_K]

How about you use the "To More Specific Class" function to coerce the typedef back to the type of graph you expect it to be? I've attached an image of what I am referring to. I also think it would make your design more straight forward if you stored the "type" of your graph typedef at the place where you created the original typedef. For example, instead of just passing the typedef around your application, pass a cluster which includes the typedef and type identifier (i.e. enum of types). I'm not totally sure what your end-game is, but as I mentioned it before I think using classes might give you more functionality in the long run.

[X.]

It won't work for me, because I want to write a utility that does something to a XY Graph without prior knowledge of the data type.

I could try to cast to a more specific class using all possible combinations of types (that's A LOT OF THEM) until I do not get an error, but I am looking for something more elegant.

I should be able to proceed with the approach I have sketched out, but I may also suggest adding a "data type" property to the XY Graph class...

EDIT: you keep refering to a a typedef. I don't use typedef. I was refering to the data type of the plot, which is what it is at the time when the indicator terminal is first connected to something on the diagram. This doesn't need to be a typedef object, obviously.