First stab at OOP

[Dan Bookwalter]

Ok.... attached is my first try at using this OOP stuff.... can some of you look at it and tell me what i am doing wrong , this is based on hardware so you really wont be able to run it , but , you should get the idea.... it still needs lots of work , but , i figured i better stop now before i get too far into it and figure out that its all wrong...

dont be too harsh

Dan

Download File:post-114-1163087862.zip

[Kurt Friday]

Ok.... attached is my first try at using this OOP stuff.... can some of you look at it and tell me what i am doing wrong , this is based on hardware so you really wont be able to run it , but , you should get the idea.... it still needs lots of work , but , i figured i better stop now before i get too far into it and figure out that its all wrong...

dont be too harsh

Dan

Hi Dan

Just had a quick look and the first issue I noticed is that you need to use a shift register to hold your object ie just like you are using the shift register for the error cluster. LV classes are by value and not by reference, just treat them as you would if you were using an ordinary cluster.

[Mark Balla]

Ok.... attached is my first try at using this OOP stuff.... can some of you look at it and tell me what i am doing wrong , this is based on hardware so you really wont be able to run it , but , you should get the idea.... it still needs lots of work , but , i figured i better stop now before i get too far into it and figure out that its all wrong...

dont be too harsh

Dan

Neat way to call the do function.

It still bugs me that when I open the Parent Do cmd vi it shows me a vi that does nothing and LabVIEW gives me no option to see the child vi's block diagrams.

Unless I have the project open and know to look for vis of the same name, I have no clue what is going on.

This will be confusing For users who are not familiar with OOP. It breaks idea that what you see in the block diagram at edit time is the same code used at run time. I know the argument has been raised about dynamic vis doing the same thing but a dynamic vi doesn't allow me to see any code. Where an override vi shows me one of many possible diagrams.

I am going to avoid override vis in my OOP projects until LabVIEW can somehow indicate and show me all of the override vis that can be called.

Maybe a selector similar to the one used for a polymorphic vi would work.

:2cents:

[Aristos Queue]

It still bugs me that when I open the Parent Do cmd vi it shows me a vi that does nothing and LabVIEW gives me no option to see the child vi's block diagrams.

Fascinating... it bugs you too! I thought I was the only one. Someone should do something about that.

[LAVA 1.0 Content]

Fascinating... it bugs you too! I thought I was the only one. Someone should do something about that.

Perhaps I can fix it if NI hires me with good enough salary

[Dan Bookwalter]

Fascinating... it bugs you too! I thought I was the only one. Someone should do something about that.

Stephen

One thing I would like to see is when you right click a class New -> VI that the vi would have the class controls and error clusters already on the FP.

Dan

[Aristos Queue]

One thing I would like to see is when you right click a class New -> VI that the vi would have the class controls and error clusters already on the FP.

New>>VI will always generate a blank VI. Not every VI in a class has the inputs/outputs you're talking about. New>>Dynamic VI does what you're asking for and, in LV8.2, if you want a static VI using the template just generate a dynamic VI and then turn off the dynamics in the conpane (right click on terminal, select "This Connection Is >> Required" -- for both the input term and the output term). My team would like to add more useful templates as time goes by (such as a New>>Static VI that does as you request), but the New>>VI will always give you fresh starting point.

Perhaps I can fix it if NI hires me with good enough salary

Have you submitted a resume?

http://ni.com/jobs

[Aristos Queue]

dont be too harsh

Actually... EXCELLENT job. You've got the right general direction. There were changes to your inheritance hierarchy that I made -- not fine grain enough. Keep each class focused on a particular aspect of the system. Detailed comments are included in the refactored project (see attachment) both in comments on the VIs and the HTML file that I've added to the Project tree.

Download File:post-5877-1163786011.zip