LVOOP Property Nodes and DVRs

[Jon Kokott]

I'm experiencing problems with using property nodes on classes to the point where I've been forced to abandon them entirely.

One of the new features of labview is that data members of classes are accessible through property nodes (both by value and by reference.) I found this to be extremely powerful as it allowed me to access not only the private data of the child class, but also the data of all ancestor classes (who have exposed their members to property nodes <- this makes it almost a public data type)

however, the property nodes are somehow losing the data type of the class (casting it to the parent type, I think) This has created LV development environment crashes (sometimes) and built application crashes (almost always)

Has anyone had success using property nodes with classes?

Specifically using them in conjunction with DVRs?

How about DVR/Inplace/Preserve runtime class dynamic dispatch operations in conjunction?

For now I've contacted NI on this issue I'm seeing (and eliminated all property nodes)

NI is seeing the same thing I do, but I'd be interested to know if anyone can get this to work.

~Jon

[Mr Mike]

Hi Jon,

Sorry to hear LabVIEW Class Properties aren't working for you. I went ahead and got a copy of a project that an Applications Engineer (Lynn) had made that demonstrated the problem. It looks like another bug that I had seen but couldn't reproduce. This sounds to be a lot easier to reproduce, so it should be a lot easier (comparatively ) to debug. When I get a chance to investigate it more thoroughly, I'll post here / communicate with support.

- Mike

[Jon Kokott]

Hi Jon,

Sorry to hear LabVIEW Class Properties aren't working for you. I went ahead and got a copy of a project that an Applications Engineer (Lynn) had made that demonstrated the problem. It looks like another bug that I had seen but couldn't reproduce. This sounds to be a lot easier to reproduce, so it should be a lot easier (comparatively ) to debug. When I get a chance to investigate it more thoroughly, I'll post here / communicate with support.

- Mike

Glad to hear it. Lynn has been my contact at NI on this issue and has been very helpful thus far.

[mje]

I found this to be extremely powerful as it allowed me to access not only the private data of the child class

This seems unintended. You can access private data of other classes in the inheritance hierarchy? If so then the property node implementation is flat out broken.

That said, I have had a lot of problems with property nodes for class DVRs too. I have not abandoned them, but I have abandoned the plans to release a public library which makes extensive use of class DVRs until I can hammer out what is causing the problems I've seen. Identifying a use case which reliably produces the odd behaviors I've seen has eluded me so far though.

In particular, my VIs using property nodes of class DVRs will often break because somehow a property node "blacks" out. What I mean by this is the property node text will be black, and it will be impossible to wire up anything to the value part of the node. I'll have to go back to the VIs that define the property node, force some kind of recompilation (usually by swapping connector pane terminals back and forth), which will then usually allow the property node to work. I've had methods in library classes break because of the property nodes used in their methods when working on child classes, forcing me to go in and re-compile the library VIs when nothing in the base class has changed. This can get particularly infuriating with complex hierarchies...

I have not done any evaluation in the run time engine, I can only hope that the run time behavior is consistent with the IDE. The problems I've been having are always at design time. Crashes and errors a plenty in the IDE, but run time behavior seems solid (when things compile).

[nhollenback]

I'm experiencing problems with using property nodes on classes to the point where I've been forced to abandon them entirely.

One of the new features of labview is that data members of classes are accessible through property nodes (both by value and by reference.) I found this to be extremely powerful as it allowed me to access not only the private data of the child class, but also the data of all ancestor classes (who have exposed their members to property nodes <- this makes it almost a public data type)

......

Has anyone had success using property nodes with classes?

Specifically using them in conjunction with DVRs?

~Jon

Just a reminder to us all. The property node only exposes the class private data of the parent when the property node is public. If I make the property node protected, then I can see the class private data from a VI outside the class hierarchy, but it is black and I can't access it. This is the "right" behavior. Could this be what you are experiencing? (I'll send screen shot later if needed)

I have great success with property nodes for classes. They are fast to write since they are all scripted. I may have a class with 50 data members. I know that I want 20 to be public or protected. But, at design time I am uncertain how to group those 20 (and I don't exactly have 20 terminals on the connector pane - or I better not). So in about 3.5 minutes, I can make 20 reads and writes that are exposed through the property node. Then later on when I am coding I can access only the data members that I need!

I have only done a quick test on the DVR usage.

I'd be happy to also try to reproduce the error, as I need to be aware of for my application.

Best,

N

[mje]

If I make the property node protected, then I can see the class private data from a VI outside the class hierarchy, but it is black and I can't access it. This is the "right" behavior. Could this be what you are experiencing?

Right, I know what you're talking about. This is most definitely not the case for the behavior I was referring to. Specifically, I've had property nodes break in a VI which is a member of the class being operated on: the class method should have access to the private methods since it is the same class.

[nhollenback]

Right, I know what you're talking about. This is most definitely not the case for the behavior I was referring to. Specifically, I've had property nodes break in a VI which is a member of the class being operated on: the class method should have access to the private methods since it is the same class.

I'm assuming it's not reproducible.

I don't have a complex hierarchy. One abstract parent and 5-6 child classes. Everything has worked flawlessly (though now that I've stated this, it'll break tonight!). I like the fact that when I realize I need access to another data member, I can add the method and save the class and then it's availability is updated in the property node that is already on the BD.

[Jon Kokott]

I'm assuming it's not reproducible.

I don't have a complex hierarchy. One abstract parent and 5-6 child classes. Everything has worked flawlessly (though now that I've stated this, it'll break tonight!). I like the fact that when I realize I need access to another data member, I can add the method and save the class and then it's availability is updated in the property node that is already on the BD.

Here is a snippet from the code that is crashing

This is the case with the property nodes.

The snippet didn't change. It is the same except the last VI is replaced with a property nodes that reads the two data values from the class data.

It won't crash without the dynamic dispatch VI "no Crash" in there. This one is crashing in the development environment as well as the runtime. It is important to stick a datatype like a string or array in the child type.

I attached the whole project in a zip file if you want to mess around with it. Just make sure you don't have something else open that you need...

It is the same file that I gave to NI.

~Jon

NIDemo.zip

Edited October 29, 2010 by Jon Kokott

[nhollenback]

Here is a snippet from the code that is crashing

Thank you for the warning to save and close everything else. Did NI have a specific answer as to "why"? Anything other than removing the property node in the offending sub? I'll take a look a little further this evening.

I owe it to the students in my OOP course this week as I did "brag" about how cool the property node feature is.

N

[nhollenback]

Here is a snippet from the code that is crashing

Hey Jon,

If I get rid of the up and down casting it all works great. I create the JonChildChild class outside the loop and there is no crash. So I wonder about the need for the upcast and 2 subsequent downcasts.

Also, you can replace the downcasts with "Preserve Run-Time Class" and you are golden!

Best,

N

[Jon Kokott]

Hey Jon,

If I get rid of the up and down casting it all works great. I create the JonChildChild class outside the loop and there is no crash. So I wonder about the need for the upcast and 2 subsequent downcasts.

Also, you can replace the downcasts with "Preserve Run-Time Class" and you are golden!

Best,

N

Remember that this is just an example and the code doesn't really do anything. I'm illustrating some common things I do with classes (which actually are needed in my development application.) If I cant change the data type on that wire in the shift register there is no point for me to even use classes (I realize that I don't do that in this example, but I wanted to show how legal syntax (<- is that even the right word?) can create a crash)

As far as the preserve run time class goes, its a similar situation. I really do need to be able to change the data type in that loop sometimes, and that function will return an error. The preserve run time class (as far as I can see) is for use with in place element structures or other situations where labview is unable to resolve the run time data type (inside a dynamic dispatch vi perhaps?)

Make sure that you can build an application also. I spent like a week with an architecture similar to this before I had a point where I could make an exe that would do something before I realized that using the property nodes was gonna crash every time.

~Jon

[Jon Kokott]

Remember that this is just an example and the code doesn't really do anything. I'm illustrating some common things I do with classes (which actually are needed in my development application.) If I cant change the data type on that wire in the shift register there is no point for me to even use classes (I realize that I don't do that in this example, but I wanted to show how legal syntax (<- is that even the right word?) can create a crash)

As far as the preserve run time class goes, its a similar situation. I really do need to be able to change the data type in that loop sometimes, and that function will return an error. The preserve run time class (as far as I can see) is for use with in place element structures or other situations where labview is unable to resolve the run time data type (inside a dynamic dispatch vi perhaps?)

Make sure that you can build an application also. I spent like a week with an architecture similar to this before I had a point where I could make an exe that would do something before I realized that using the property nodes was gonna crash every time.

~Jon

I am gonna side step my original statement of that I cannot use the preserve run time class VIs. Any place where I would perform that downcasting I wouldn't be changing the class on the wire (I would be getting downcast errors.) As far as that replacement goes it did eliminate my errors in the development environment (no crashes, no data type losses.) But In a built application it still crashes.

Could you build one of your own applications where you are using property nodes?

I didn't consistently see the error until I built my application for the first time. Furthermore, it was mostly displaying bad data in fixed data types like U32s or some other scalar. It wasn't until I used a datatype like a string or array before the crash became consistent (I think its still a matter of probability, it just gets alot higher the more memory you require for a datatype.)

[ShaunR]

I am gonna side step my original statement of that I cannot use the preserve run time class VIs. Any place where I would perform that downcasting I wouldn't be changing the class on the wire (I would be getting downcast errors.) As far as that replacement goes it did eliminate my errors in the development environment (no crashes, no data type losses.) But In a built application it still crashes.

Could you build one of your own applications where you are using property nodes?

I didn't consistently see the error until I built my application for the first time. Furthermore, it was mostly displaying bad data in fixed data types like U32s or some other scalar. It wasn't until I used a datatype like a string or array before the crash became consistent (I think its still a matter of probability, it just gets alot higher the more memory you require for a datatype.)

The "Othello" contribution in the "Examples Competition" uses property nodes.

Othello

[Mr Mike]

There are two reasons a property item may be broken (turn black):

1. The property you're trying to access is inaccessible (scoping). We originally thought about not letting you select that property item, but that went against our approach of letting the user do what they want in the order they want. If they wanted to use a private/protected property out of scope and they decided to make it more available, they should be able to access it and then change the scope
2. The property you're trying to access can't be found. This can happen if you remove a property or change its name without the property in memory. See my first response to mje on another reason it may happen

In particular, my VIs using property nodes of class DVRs will often break because somehow a property node "blacks" out. What I mean by this is the property node text will be black, and it will be impossible to wire up anything to the value part of the node. I'll have to go back to the VIs that define the property node, force some kind of recompilation (usually by swapping connector pane terminals back and forth), which will then usually allow the property node to work. I've had methods in library classes break because of the property nodes used in their methods when working on child classes, forcing me to go in and re-compile the library VIs when nothing in the base class has changed. This can get particularly infuriating with complex hierarchies...

If this is the problem that I think you're describing, I've got a fix which is still being reviewed. (The person doing the code review has been out sick for a few days). The basics of that problem is that behind the scenes the properties have different names for if it's dynamic and static and some property nodes weren't getting updated when you change the properties from dynamic to static or static to dynamic. The problem only happens when you change the class input before you change the class output. This is CAR 248637 if you're interested.

That said, I have had a lot of problems with property nodes for class DVRs too. I have not abandoned them, but I have abandoned the plans to release a public library which makes extensive use of class DVRs until I can hammer out what is causing the problems I've seen. Identifying a use case which reliably produces the odd behaviors I've seen has eluded me so far though.

I haven't heard of any problems with DVRs and property nodes. What specifically are you having trouble with?

Did NI have a specific answer as to "why"?

Jon Kokott's issue appears to be caused by something not related to property nodes, but the property nodes are just getting caught in the crossfire. I haven't had time to take a good look at Jon's demo (I just heard about the issue before I left last night), so I can't say for sure why it's happening. It might help to force a compile (Ctrl+Click the run arrow) after loading a VI (i.e. opening or restoring). I recognize this isn't a solution for a lot of cases.

[Jon Kokott]

The "Othello" contribution in the "Examples Competition" uses property nodes.

Othello

I didn't experience any problems with this code, in dev environment nor built application.

thanks for the example.

~Jon

Jon Kokott's issue appears to be caused by something not related to property nodes, but the property nodes are just getting caught in the crossfire. I haven't had time to take a good look at Jon's demo (I just heard about the issue before I left last night), so I can't say for sure why it's happening. It might help to force a compile (Ctrl+Click the run arrow) after loading a VI (i.e. opening or restoring). I recognize this isn't a solution for a lot of cases.

I would agree with this assessment that something else is going on beyond the property node itself. I've had them work sometimes, but eventually I do something to the class that creates this corruption condition. I've been cntrl clicking quite a bit, and it does help, unfortunately, I cant do that for a built application .

[Jon Kokott]

I was assigned CAR 255982 for what I was seeing.

I'm kinda surprised no one else is seeing this because NI was able to demonstrate the error on their end building up a class hierarchy from scratch (reliably.)

At any rate I won't be using property nodes with classes.

Thanks for the input from everyone.

~Jon

[nhollenback]

I was assigned CAR 255982 for what I was seeing.

I'm kinda surprised no one else is seeing this because NI was able to demonstrate the error on their end building up a class hierarchy from scratch (reliably.)

At any rate I won't be using property nodes with classes.

Thanks for the input from everyone.

~Jon

Hey Jon,

Thanks for closing the loop on this. Since I'm not doing any up or down casting I'll keep using property nodes for now. But I will be back here if anything odd and repeatable occurs.

[Jon Kokott]

Hey Jon,

Thanks for closing the loop on this. Since I'm not doing any up or down casting I'll keep using property nodes for now. But I will be back here if anything odd and repeatable occurs.

I'm not really even sure if that is what the issue is. It could be some kind of corruption that occurs in normal class creation. Also I'm suspicious of whether or not it is system dependent (I'm using windows XP 32 bit service pack 3)

I was able to use the othello example with no problems (and I taxed the hierarchy with new data members, methods, property nodes.) So something is going on, but its not totally reliable.

It would be interesting if the up and down casting had something to do with it (I'm under the impression that they do absolutely nothing other than change the data type of the wire so you can actually wire the correct class type to a method.

~Jon

[Mr Mike]

I haven't heard of any problems with DVRs and property nodes. What specifically are you having trouble with?

Could you describe problems with DVRs? In the examples you sent Lynn, I don't remember seeing any DVRs.

Jon Kokott's issue appears to be caused by something not related to property nodes, but the property nodes are just getting caught in the crossfire.

Looks like I'm going to have to eat my words on that one. It turned out to be a property nodes related issue. I have a fix for the issue and I'll try to get it in the next possible release, which may or may not be a bug fix (SP1 or 2011). I can't promise anything. (On a side note, I wish there were an embarrassed smiley that wasn't holding a giant "Oops" sign)

I was assigned CAR 255982 for what I was seeing. [...]

At any rate I won't be using property nodes with classes.

You may also see this in the Known Issues List as CAR 246263, since that one is the same issue and was just about to go on the list. Sorry you couldn't use my feature for your project. I hope you'll try it again when the fix comes out.

[Jon Kokott]

Could you describe problems with DVRs? In the examples you sent Lynn, I don't remember seeing any DVRs.

Looks like I'm going to have to eat my words on that one. It turned out to be a property nodes related issue. I have a fix for the issue and I'll try to get it in the next possible release, which may or may not be a bug fix (SP1 or 2011). I can't promise anything. (On a side note, I wish there were an embarrassed smiley that wasn't holding a giant "Oops" sign)

[/size]

You may also see this in the Known Issues List as CAR 246263, since that one is the same issue and was just about to go on the list. Sorry you couldn't use my feature for your project. I hope you'll try it again when the fix comes out.

After further investigation it is likely not a related to the DVR.

It just so happens that in my original finding of the problem I was using DVRs and property nodes where the problem originally manifested itself. As I peeled the onion to find the root cause the DVR was one of the things that was removed.

Really Glad to hear that the problem has been identified. Is this the place where the known issues will appear? http://zone.ni.com/devzone/cda/tut/p/id/11869 I haven't seen it come up yet but I'll be watching for it.

~Jon

[Mr Mike]

Yes, that's where the CAR should appear. I don't know how long it will take though.

[mje]

Resurrecting this thread...

In particular, my VIs using property nodes of class DVRs will often break because somehow a property node "blacks" out. What I mean by this is the property node text will be black, and it will be impossible to wire up anything to the value part of the node. I'll have to go back to the VIs that define the property node, force some kind of recompilation (usually by swapping connector pane terminals back and forth), which will then usually allow the property node to work. I've had methods in library classes break because of the property nodes used in their methods when working on child classes, forcing me to go in and re-compile the library VIs when nothing in the base class has changed. This can get particularly infuriating with complex hierarchies...

If this is the problem that I think you're describing, I've got a fix which is still being reviewed. (The person doing the code review has been out sick for a few days). The basics of that problem is that behind the scenes the properties have different names for if it's dynamic and static and some property nodes weren't getting updated when you change the properties from dynamic to static or static to dynamic. The problem only happens when you change the class input before you change the class output. This is CAR 248637 if you're interested.

I've managed to capture a case where the problem I described happened. This is the aftermath of it:

I was working on a child class when a base class method (above) broke because of a property node. I had been making several changes to the child, so while I don't think anything in the base class was explictly operated on, I could be wrong. The property node methods definitely were not touched. The node just...broke, taking all my class implementations along with it.

The node magically fixes itself if I open the VI that defines the read method and force a recompilation by swapping a connector terminal back and forth, for example.

I'm wondering if I can possibly get this code to NI to evaluate if this is indeed the same problem addressed in CAR 248637? Mr Mike perhaps?

[Mr Mike]

I'm wondering if I can possibly get this code to NI to evaluate if this is indeed the same problem addressed in CAR 248637? Mr Mike perhaps?

That sounds like the same problem and it should be addressed in 2011 (as always without making any promises). If you can reproduce it and describe the steps, I can probably tell you. If you can reproduce it but not figure out the steps exactly, try recording it with Jing. However, I should say that including my fix for CAR 248637, I don't know of any case in which a property item will black out other than if the property name changes AND the file name of the accessor VI changes.

[mje]

Thanks, I'll see what I can do. I think I'm working with a different problem as the property names or VI names most definitely had not changed. Something else is amok here...

[Jon Kokott]

To close this thread:

When I made the original posting, I did not think my problem was in any way related to the "blacked out" property node element that mje described above.

It seems that their may be some interaction between this and the run time crashes I experienced in built applications (Mr. Mike's response)

I will not be using property nodes, as it reliably fails on my machine. After trying out the Othello example (and hacking it hard to try to recreate the crash--- and failing to create a crash) tells me that something else is probably in play, and I'll have to wait to see the CAR/ fix whenever it is released.

Thanks again for all the responses.

~Jon