LabVIEW Class type for Expression Node

[gb119]

I'm playing around with scripting and trying to create an expression node (as in the in-wire formula nodes). I'm getting stuck as to what type of class to wire into the New VI Object primitive. I can tell that it must be some sort of Node class because if I use a Node class constant I don't get a type casting error from the New VI Object primitive. On the other hand it must be a sub-class of this because there needs to be some way to set the expression to be used. However none of the subclasses that the DataAct Class browser (great tool by the way for us trying to script in 8.20) knows about. Trying to create property nodes with class names set to likely looking strings isn't giving any joy yet either.

Has anybody created an expression node through scripting, and if so, how do you set the expression ?

[Yair]

I can't test this at the moment, but if I remember correctly, the class input does not determine anything. If this is correct, you can wire in the generic class and the enum will select the kind of node you're creating. Of course, that doesn't seem to make much sense (why else would you need to wire in the class?), so it's possible that I'm wrong, that this only works for some things or that this will be deprecated.

[gb119]

QUOTE(yen @ Mar 29 2007, 07:54 PM)

I can't test this at the moment, but if I remember correctly, the class input does not determine anything. If this is correct, you can wire in the generic class and the enum will select the kind of node you're creating. Of course, that doesn't seem to make much sense (why else would you need to wire in the class?), so it's possible that I'm wrong, that this only works for some things or that this will be deprecated.

The class input appears to define the Vi Server class of the refnum that comes out of the New VI Object which in turn determines which properties and methods you can access on whatever it is that you've created. As far as I can see, there must be a property or method to specify the expression that the expression node uses, hence one would expect the expression node to be some class different from e.g. the increment function. If one wires an class that is incompatible with the object that New VI Object tries to create then you get a type cast error (e.g. try specifying a terminal class constant while creating an add function). Compatible in this case means that the class you specify is either the same as the actual class of the object, or a superclass. The reason that wiring the generic class works, is that generic is a superclass of lots of things, but it does mean that you can't do very much with the object you've created without casting it to a more specific class first, for which you need the correct class constant... By replacing the generic control with more specific class types in turn, iterating over the class heirarchy and spotting which generate errors and which don't one can map out the specific heirarchy of the object that one is creating. Thus, I've got as far as 'Node' but no further.

Actually, thinking about it, if I create an expression node on a block diagram, I wonder if I can interrogate that from another vi to determine the class type of all the nodes on the block diagram. Will go and try this...

[AdamRofer]

QUOTE(Gavin Burnell @ Mar 29 2007, 01:37 PM)

The class input appears to define the Vi Server class of the refnum that comes out of the New VI Object which in turn determines which properties and methods you can access on whatever it is that you've created. As far as I can see, there must be a property or method to specify the expression that the expression node uses, hence one would expect the expression node to be some class different from e.g. the increment function. If one wires an class that is incompatible with the object that New VI Object tries to create then you get a type cast error (e.g. try specifying a terminal class constant while creating an add function). Compatible in this case means that the class you specify is either the same as the actual class of the object, or a superclass. The reason that wiring the generic class works, is that generic is a superclass of lots of things, but it does mean that you can't do very much with the object you've created without casting it to a more specific class first, for which you need the correct class constant... By replacing the generic control with more specific class types in turn, iterating over the class heirarchy and spotting which generate errors and which don't one can map out the specific heirarchy of the object that one is creating. Thus, I've got as far as 'Node' but no further.

Actually, thinking about it, if I create an expression node on a block diagram, I wonder if I can interrogate that from another vi to determine the class type of all the nodes on the block diagram. Will go and try this...

I started off that way to try to find an answer to your question, and it tells you that it's a Node (surprise!).

You can typecast a similar object to acquire a similar function that isn't necessarily exposed on that object, as Yen pointed out in this forum post: http://forums.lavag.org/How-to-get-reference-to-Text-of-StringConstant-t5791.html' target="_blank">How to get reference to Text of StringConstant?

I couldn't get any probable casts to work, I thought Formula.Formula Expression would be the closest match. Decoration.Text.Vertical Arrangement is another property that should work but doesn't, possibly indicating that scripting on this object type is (for now) not possible in the way you need to.

The most I was able to do is get Node.Style to tell me it was an "Expression Node"

Keep trying, though, and let us know! :thumbup:

EDIT: It looks like the setup is almost identical to UnitCast (Convert Unit) objects, but the UnitCast.Unit property still doesn't yield the Expression Node stuff. Decoration.Text.Vertical Arrangement on UnitCast items is also not possible, oddly enough.

[smenjoulet]

QUOTE(Gavin Burnell @ Mar 29 2007, 03:37 PM)

The class input appears to define the Vi Server class of the refnum that comes out of the New VI Object which in turn determines which properties and methods you can access on whatever it is that you've created.

Yes, that is correct. This allows you to directly access properties/methods without having to cast the reference to the specific type after the "New VI Object" primitve.

As for Expression Node, it looks like this is a hole in the VI scripting capability. The Expression Node is of class Node and there aren't any properties or methods for setting expresssions at that class level, as you would guess. You can see this by getting the ClassName directly after "New VI Object" (even when using Generic or GObject as the class type).

I'd suggest using a formula node in this case. It's not the solution you're exactly looking for, but it does work and should accomplish what you need. I've attached an example.

Regards,

Scott

[gb119]

QUOTE(AdamRofer @ Mar 29 2007, 09:49 PM)

The most I was able to do is get Node.Style to tell me it was an "Expression Node"

Keep trying, though, and let us know! :thumbup:

EDIT: It looks like the setup is almost identical to UnitCast (Convert Unit) objects, but the UnitCast.Unit property still doesn't yield the Expression Node stuff. Decoration.Text.Vertical Arrangement on UnitCast items is also not possible, oddly enough.

Yup, it looks like it really truly is just a Node. I can't get a Text.Size to Text? to work either. On the other hand this whole typecasting of refnums so that property nodes don't notice you accessing non-exposed properties seems so completely and utterly hackery that I'm not sure whether to laugh or cry. I wonder if the NI employees enjoy watching us bang our heads against walls trying to do things that we're really really not supposed to do with LV :headbang:

[Yair]

QUOTE(Gavin Burnell @ Mar 29 2007, 11:37 PM)

The class input appears to define the Vi Server class of the refnum that comes out of the New VI Object which in turn determines which properties and methods you can access on whatever it is that you've created.

That would explain it. I haven't played with this much, but when I did it was often to create a simple object (or a non-supported one, like the TCP RW primitives which accept any data as input :thumbup: ) or to create a large number of objects in a loop and not work on them later, so I never really needed the reference coming out of the primitive.

Anyway, as Stephen mentioned in the other thread, this is probably just a property which was left unexposed.

[Rolf Kalbermatter]

QUOTE(Gavin Burnell @ Mar 29 2007, 04:37 PM)

Yup, it looks like it really truly is just a Node. I can't get a Text.Size to Text? to work either. On the other hand this whole typecasting of refnums so that property nodes don't notice you accessing non-exposed properties seems so completely and utterly hackery that I'm not sure whether to laugh or cry. I wonder if the NI employees enjoy watching us bang our heads against walls trying to do things that we're really really not supposed to do with LV :headbang:

Actually some well known NI person here stated once that he would rather like to make those castings impossible at all and has done so in the past for some areas as it is a very hacky way of sending LabVIEW into some crash course. There seems to be some extra security checks that when you try to access a typecasted property that doesn't exist for the actual object in question gives you an error message but he stated that this security check while there, is anything but fool proof.

Rolf Kalbermatter

[Aristos Queue]

QUOTE(Gavin Burnell @ Mar 29 2007, 04:37 PM)

I wonder if the NI employees enjoy watching us bang our heads against walls trying to do things that we're really really not supposed to do with LV :headbang:

All these holes in the functionality. And you wonder why NI never releases scripting?

It isn't that this is something "you're not supposed to do." It's actually that it is something that no one internal has ever needed to do so no scripting method has ever been created. The things you find when you dig into scripting are not the unshielded parts of some master document. They're the bits and pieces that various internal tools have needed to get their job done and nothing more.