How to get reference to Text of StringConstant ?

[Jim Kring]

I'm trying to get a reference to the Text of a StringConstant (so that I can set it's Justify attribute). I can get the Label attribute (which I'm not interested in), but the StringConstant does not appear to have a Text attribute, as the String (Control/Indicator) does? I'm using LabVIEW 7.1. Maybe this exists in 8.0 or 8.2. Any ideas?

Thanks,

-Jim

[castech]

I can get the Label attribute (which I'm not interested in), but the StringConstant does not appear to have a Text attribute, as the String (Control/Indicator) does? I'm using LabVIEW 7.1. Maybe this exists in 8.0 or 8.2. Any ideas?

I don't know the answer BUT are you saying that you have placed a string constant on the block diagram and have been able to create a reference to it? How?

Sorry - we are all here to learn!!

Cheers

[Jim Kring]

I don't know the answer BUT are you saying that you have placed a string constant on the block diagram and have been able to create a reference to it? How?

That's a short question with a long answer. See here: VI Scripting Forum - Readme First

[Yair]

Type cast the reference to the string control class and you can control this.

I only checked it on 7.1.

[LAVA 1.0 Content]

Type cast the reference to the string control class and you can control this.

I only checked it on 7.1.

Shouldn't you use to-more-specific node instead of explicit type-cast?

[Jim Kring]

Type cast the reference to the string control class and you can control this.

Yen,

This is a great solution! I didn't even think of that -- I just tested and it works in 8.2.

Thanks,

Shouldn't you use to-more-specific node instead of explicit type-cast?

Jimi,

No, the To More Specific Class function will not work, since a StringConstant object is not a more specific type (subclass) of a String (control/indicator). StringConstant inherits from Constant and not Control -- if VI Server objects were implemented using multiple inheritance, then maybe both could simply inherit from the String datatype, but that's a different discussion.

The reason that the typecast solution works, is that property/invoke nodes don't do type-checking at run-time (they rely on LabVIEW's type checking of wires in the editor) -- they only check to see if the input object has the properties/methods that are being accessed/called. And, the StringConstant VI Server object does have a Text attribute, but it simply hasn't been exposed yet in VI Server. This is akin to duck typing -- if a StringConstant has a Text attribute, then reading the Text attribute should work (even if the StringConstant is masquerading as String control, as long as nobody checks to make sure that it is really a String).

Thanks,

[eaolson]

The reason that the typecast solution works, is that property/invoke nodes don't do type-checking at run-time (they rely on LabVIEW's type checking of wires in the editor) -- they only check to see if the input object has the properties/methods that are being accessed/called. And, the StringConstant VI Server object does have a Text attribute, but it simply hasn't been exposed yet in VI Server. This is akin to duck typing -- if a StringConstant has a Text attribute, then reading the Text attribute should work (even if the StringConstant is masquerading as String control, as long as nobody checks to make sure that it is really a String).

Interesting. I've only fiddled with scripting a little bit. It looks like the pre-cast StringConstant refnum and the post-cast String refnum are the same. So does the Type Cast primitive manipulate the actual data (i.e., the thing the refnum is pointing to) in any way, or does it just cause the block diagram editor to interpret the data type of the wire differently?

It is possible to get yourself in trouble with this trick. For example, a String has the Default Value property, while a StringConstant doesn't. Trying to modify the Default Value of the StringConstant this way throws error 1058, "Specified property not found" at run time.

[Aristos Queue]

The reason that the typecast solution works, is that property/invoke nodes don't do type-checking at run-time (they rely on LabVIEW's type checking of wires in the editor) -- they only check to see if the input object has the properties/methods that are being accessed/called. And, the StringConstant VI Server object does have a Text attribute, but it simply hasn't been exposed yet in VI Server. This is akin to duck typing -- if a StringConstant has a Text attribute, then reading the Text attribute should work (even if the StringConstant is masquerading as String control, as long as nobody checks to make sure that it is really a String).

Oh dear lord. You're kidding right? That is soooooooo a crash waiting to happen in some case where we (LV R&D) add an data field to the record of a FP control that we don't add to the constant... I can imagine a function where we assume we have a control in our hands, so we access a field (which isn't there because it is really a constant) and booom.... down goes LV.

I can see why you want this functionality to work -- I mean, having access to the text field and all -- but WOW, that is so bad it makes my teeth hurt. And we can't even fix this improper cast in any way that I can think of without breaking your code. Even if we were to add a Text property to the StringConstant, how could we find all the improper type casts and change the code to leave out the type cast and just call the StringConstant's new Text property directly.

Wow. It's bugs like this that had me so paranoid when we released OO in LV8.2 -- what did I put in that is a bug, a dangerous hole, that will have to haunt us for the rest of time because there's no way to mutate away from it? Haven't found such a bug yet, but the possibility continues to plague me every time Jimi starts a new thread...

:!: PS -- for those of you who are now building object hierarchies in LabVIEW, the correct way to handle an object hierarchy like this, where you don't have multiple inheritance but you want something to unify two branches, is for one inheritance to own an instance of the other branch as a data member. For example, the Constant class would have a Property of "Control" which would have all the control behavior that underlies the constant. The other possibility is for StringConstant and StringControl to be the same class, with a boolean property "Is Constant?" (or maybe a trinary "style" which returns Indicator, Control or Constant).

Type casting your types in this abusive manner is, as I said, a problem waiting to happen.

[Jim Kring]

[...snip] the possibility continues to plague me every time Jimi starts a new thread...

You forgot to typecast your reference.

Type casting your types in this abusive manner is, as I said, a problem waiting to happen.

Sometimes it is easier to wait for a problem (ask for forgiveness) than wait for a solution (ask for permission) ;-)

One instance where this technique works really well is type casting "strict" VI References to non-strict VI references. Opening them strictly is useful for reserving them for Call By Reference, however casting them to non-strict is useful for storing them with other VI References (in an array) and still being able to access VI properties and methods with the non-strict reference.

[Tomi Maila]

I like this picture, may I use it in my signature... Althoug I wonder if I should use by-value objects instead...

[crelf]

You forgot to typecast your reference.

I knew LabVIEW wold take over the world one day - looks like thay day has arrived

[Aristos Queue]

I like this picture, may I use it in my signature... Althoug I wonder if I should use by-value objects instead...

I just assumed that Jimi was a strict typedef of Tomi Malia for backward compatibility. I had no idea that we had actually changed wire type. I'll be sure to cast in the future. At least Tomi didn't inherit from Jimi and override the Name method -- although that would make wiring convenient, it would make his his own parent, and the recursive allocations would rapidly cause problems. ;-)

[crelf]

I just assumed that Jimi was a strict typedef of Tomi Malia for backward compatibility.

[Yair]

So does the Type Cast primitive manipulate the actual data (i.e., the thing the refnum is pointing to) in any way, or does it just cause the block diagram editor to interpret the data type of the wire differently?

A type cast takes the bit pattern of whatever you wire into it and reinterpets it as the new data type. The actual data (as you saw in your example) does not change.

In this case, the type cast is only necessary because the editor does not let you see the Text property when you use the StringConstant class. If you had wired the numeric class to the top terminal, you would have gotten the numeric class properties.

[Aristos Queue]

A type cast takes the bit pattern of whatever you wire into it and reinterpets it as the new data type. The actual data (as you saw in your example) does not change.

In this case, the type cast is only necessary because the editor does not let you see the Text property when you use the StringConstant class. If you had wired the numeric class to the top terminal, you would have gotten the numeric class properties.

Exactly. And that's why this is such a terrible bug for LV!!! I'll wager at least one of those casts creates a crash situation.

This should *soooooo* be illegal. At the very least the property/invoke node should be type testing the refnum value and returning an error if it is an invalid type.

[Jim Kring]

Exactly. And that's why this is such a terrible bug for LV!!! I'll wager at least one of those casts creates a crash situation.

This should *soooooo* be illegal. At the very least the property/invoke node should be type testing the refnum value and returning an error if it is an invalid type.

If LabVIEW was going to crash, then it would crash the first time the code was run (probably). Also, this code is (obviously) used as an editing tool (text attribute of StringConstant, remember) and I have no problem rewriting an editing tool when it does start crashing LabVIEW (many of mine do) or when the Text attribute of the StringConstant is implemented by NI. I'm not too worried about it -- LabVIEW crashes much more often for lesser offenses. However, I agree with you, in principle.

:2cents:

[Rolf Kalbermatter]

Exactly. And that's why this is such a terrible bug for LV!!! I'll wager at least one of those casts creates a crash situation.

This should *soooooo* be illegal. At the very least the property/invoke node should be type testing the refnum value and returning an error if it is an invalid type.

While I can see your point of view to a certain degree I think it is not exactly helping. If you typecast refnums and then try to access a property that does not exist in the original object you usually get a runtime error in the error cluster to that effect. So it does appear that the property node does do some runtime property lookup or something and only references the object data field from there. Seems quite safe to me!

If you want to brandish the person having implemented that, you should also and even more so do so with the person having forgotten to add the TextField property to the String Constant. And there are many inconsistencies like that in the LabVIEW object hierarchy (without even looking at the super private and more obscure things) although I do understand that maintaining that and keeping it complete is a thankless job.

Rolf Kalbermatter

[Aristos Queue]

While I can see your point of view to a certain degree I think it is not exactly helping.

Wasn't trying to be helpful this time. :-) I don't have a helpful suggestion on this topic. Jim is right -- go ahead and use this trick. Perhaps someday it'll stop working. Or, perhaps, we've gotten along this long without someone filing a CAR, maybe it'll just be enshrined. I haven't filed it after reading this conversation. There is some error checking, but it isn't comprehensive.

although I do understand that maintaining that and keeping it complete is a thankless job.

And you wonder why we have never released scripting... :-)

[Rolf Kalbermatter]

Wasn't trying to be helpful this time. :-) I don't have a helpful suggestion on this topic. Jim is right -- go ahead and use this trick. Perhaps someday it'll stop working. Or, perhaps, we've gotten along this long without someone filing a CAR, maybe it'll just be enshrined. I haven't filed it after reading this conversation. There is some error checking, but it isn't comprehensive.

And you wonder why we have never released scripting... :-)

No I do not wonder at all and have full sympathy with you guys. I even made repetitive statements to that effect.

Doesn't mean that I wouldn't sometimes like to get my hands dirty though.

I have a strong experience with all kinds of crashes whenever trying to debug my external code projects so I can't really be shocked.

Rolf Kalbermatter