Plugin Architecture

[JW_L3CE]

This is my first useful journey into LabVIEW OOP and I'm working with the packed project library plugin architecture here. It's mostly going well, but I'm down to a point where I think my base understanding of OOP might be wrong.

The parent class defines 4 methods:

Front panel- Dynamic Public and Required Override- Designed to be overwritten by the plugin itself. The parent method only returns an error to alert any cases where the child isn't used.

Initialize- Static Public- Initialized variables and calls the front panel into a case structure that allows variable loading and mostly visual setup. This also passes the Front panel VI reference to the main application for Subpanel embedding.

Run- Static Public- Calls front panel into run case

Close- Static Public- Calls front panel into close case for instrument shutdown and other closeout.

What I'm noticing is that when I load the child plugin and call the initialize method, it calls the parent Front Panel and returns the error. I know the plugin should override the Front Panel method because it is required by the class. I have also recreated the override several times.

I'm also very open to architecture critiques (aka nooo, it's allll wrooong) and will post the code if someone has time to donate to my education. Thanks in advance.

(P.S. First post in this forum. Felt like this was a better place for an OOP question)

[todd]

Probes and "Get LV Class Path.vi" have useful information about whether you're down-casting properly:

[Ryan Podsim]

Not sure how you are calling the Front Panel VI; but I would guess, since you referring to sub panels, that you ware using either the Asynchronous Call by Reference node or using VI:Run method. In either case, I don't think the dynamic dispatch works. This could be why you always getting the Parent VI.

[JW_L3CE]

Thanks for the info about the probes. Definitely helpful. However,it is down-casting to the plugin interface properly.

The reference is actually coming from the Front Panel itself. My intention was that you call the initialize method, which calls the Front Panel method in initialize mode. The Front Panel returns it's own reference to the Initialize method, then back to the main application for SubPanel embedding. The idea was to avoid asynchronous calling by using the Run method, which calls the Front Panel as well.

I've attached the code since I might not be describing this correctly.

(side note: I had this general idea working when the Initialize method was dynamic and each child Initialize contained a static reference to the Front Panel. I wanted to avoid as many mandatory overrides as I could though.)

Thanks for the answers to far.

PluginTest.zip

[crossrulz]

I think I found it. In the testApp.vi, the first thing that happens is the Close. The shift register is of the parent’s class. Since the shift register hasn’t been initialized, it will have a class of the parent. Therefore you get your “parent class was used” error. This error is then causing the rest of the code in the event to not run and the shift register will have a “parent class” loaded into it. I recommend changing the error to a warning and see what happens.

[JW_L3CE]

I think I found it. In the testApp.vi, the first thing that happens is the Close. The shift register is of the parent’s class. Since the shift register hasn’t been initialized, it will have a class of the parent. Therefore you get your “parent class was used” error. This error is then causing the rest of the code in the event to not run and the shift register will have a “parent class” loaded into it. I recommend changing the error to a warning and see what happens.

Yeah. That was it. Thanks. I was so focused on OOP that I didn't realize the close was causing the problem.

Either way, we can let this thread die. I'll put the working code up if someone has any architecture critiques. My company has a tendency to plan things with the phrase "It's just like" and drag around code/hardware for a long time. I want to make sure this is robust/easy/expandable.

Plugin Test.zip

Edited October 4, 2012 by JW_L3CE