First steps into LVOOP

[Jacemdom]

Salut.

Making my first steps into LVOOP and here are some questions about the project discussed in the presentation (Introduction to OO Dev by Robbie Gehbauer) available at

http://secure.niweek.com/published/I80_Geh...resentation.zip

Exploring ShapesTest.vi in Shapes.lvproj

1- When probing Line.lvclass i get a picture control...where does it come from?

2- is it possible to probe the actual data on the input of Draw.vi in the for loop? If not is this planned in future versions? I only get a probe that tells me the actual datatype...

3- In reference to number 2, how can i look at the data that flows through if the probe does not work?

[Ton Plomp]

Exploring ShapesTest.vi in Shapes.lvproj

1- When probing Line.lvclass i get a picture control...where does it come from?

There is no Line.lvclass inside shapestest.vi only a linesegment and this one has a special probe! (see the properties of the lvclass

2- is it possible to probe the actual data on the input of Draw.vi in the for loop? If not is this planned in future versions? I only get a probe that tells me the actual datatype...

Just like linesegment create a probe inside the polygon lvclass

Hope thiss helps (haven't checked it)

Ton

[Aristos Queue]

2- is it possible to probe the actual data on the input of Draw.vi in the for loop? If not is this planned in future versions? I only get a probe that tells me the actual datatype...

3- In reference to number 2, how can i look at the data that flows through if the probe does not work?

Suggestions for improving this in the future are welcome. Here's how "probes with classes" support stands today:

1) The probe is built for the wire type. Since any type of data may come down that wire at run time, the wire type is the most specific probe we can put up. And so we do.

2) The probe does show the specific type that comes down the wire, but none of the more specific data because there's no place in the probe to show this data. We discussed all sorts of options for probes that add/remove fields when a specific type comes down the wire. This creates a very jumpy probe (bad user experience).

3) You can create custom probes for class types. You might write a probe for a specific class hierarchy that displays a subpanel for the specific classes. This is A LOT of effort to go to for a probe, so I'd only recommend doing this for a class that you're going to release as a library for other users to use in development.

4) Why was the current solution found to be acceptable for this release? Whenever you have child data traveling on a parent wire, the vast majority of the time, you don't care what the values are in the child fields. The problem that is being debugged is generally to do with one of the fields of the parent class. In the other smaller percent of the time, you can put debug code on your diagram that does a "to more specific" cast of the object and then probe the output of that wire.

I hope this helps.

[Jacemdom]

Suggestions for improving this in the future are welcome. Here's how "probes with classes" support stands today:

1) The probe is built for the wire type. Since any type of data may come down that wire at run time, the wire type is the most specific probe we can put up. And so we do.

2) The probe does show the specific type that comes down the wire, but none of the more specific data because there's no place in the probe to show this data. We discussed all sorts of options for probes that add/remove fields when a specific type comes down the wire. This creates a very jumpy probe (bad user experience).

3) You can create custom probes for class types. You might write a probe for a specific class hierarchy that displays a subpanel for the specific classes. This is A LOT of effort to go to for a probe, so I'd only recommend doing this for a class that you're going to release as a library for other users to use in development.

4) Why was the current solution found to be acceptable for this release? Whenever you have child data traveling on a parent wire, the vast majority of the time, you don't care what the values are in the child fields. The problem that is being debugged is generally to do with one of the fields of the parent class. In the other smaller percent of the time, you can put debug code on your diagram that does a "to more specific" cast of the object and then probe the output of that wire.

I hope this helps.

2) I would definately prefer a jumpy probe than no probe. I'm used to the possibility to just poke around everywhere on the wires to debug, but also to understand code. maybe you could create another kind of probe, Default, Custom and Jumpy! :laugh:

4) And in this case, the parent class "shape" is an empty cluster so this is why i get an empty probe...

Is it possible to make a probe that uses a dynamic dispatch? I am trying but i get