Dynamically loading template VI class member causes error

[Fedor]

I would like to run same VI in several  subpanels at once.

I followed NI guidelines and load same VI template dynamically for each subpanel, which works fine.

I would also like this VI to be a member of the class. And it works too, up to the point where I would like to access protected class data in the template VI, after which I get the following runtime error:

Error 1003 occurred at Open VI Reference in TemplateTestTopVI.vi 

Possible reason(s): 

LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.

VI Path: ..\TemplateMember.vit

By the way, calling the same *.vit member directly, not through VI server,  works fine.

Is there any work around?

Sample code attached.

[muks]

See here

[Ben]

---

Fedor wrote:

I would like to run same VI in several  subpanels at once.

I followed NI guidelines and load same VI template dynamically for each subpanel, which works fine.

I would also like this VI to be a member of the class. And it works too, up to the point where I would like to access protected class data in the template VI, after which I get the following runtime error:

Error 1003 occurred at Open VI Reference in TemplateTestTopVI.vi 

Possible reason(s): 

LabVIEW:  The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.

VI Path: ..\TemplateMember.vit

By the way, calling the same *.vit member directly, not through VI server,  works fine.

Is there any work around?

Sample code attached.

---

Been ther done that, Sqashed by LabVIEW R&D.

This boils down to a philosophical issue that being

"Is a VI created from a template that is part of a class a member of the class?"

Bottom Line = NO. The class has to know about all of its members and the VI created from the template is not known by the class so not a member.

There is also a twisted way that Classes can be messed with that could be exploited so ...

What I do is create a template that is not a part of the class and uses only public methods of that class to do the job.

So...

Take it out of the Class.

Re-write it to use public methods.

Ben

[Jason_P]

Ben,

So does this mean if you needed multiple, independent copies of an active object, you'd use a reentrant VI instead of a VIT?

Thanks,

JasonP - CLD

[Ben]

---

Jason P wrote:

Ben,

So does this mean if you needed multiple, independent copies of an active object, you'd use a reentrant VI instead of a VIT?

Thanks,

JasonP - CLD

---

I believe (may be wrong!) the only difference is if you want to see a FP.

This image shows my code where I instanciate my version of an Active Object.

 

The class type I pass to the "Class" control dictates the personality of the object created.

But since writting that RogerL posted a nice collection of LVOOP examples where you can find part 1 & 2 of his zips here.

If you open his projec and the example "TextRotationMain.vi" and chase down "Threading.lvclass:Start.vi" you will find that he used a re-entrant VI.

If you decide one way is better than the other please post back so I can learn something as well.

I hope that helps,

Ben

[Jason_P]

OK - I downloaded the files, but it is going to take me a long time to chew through them.  It's clear I have a lot to learn!  LVOOP aside, at first glance it's pretty interesting stuff from a basic techniques point of view.  Anytime I can advance my style, I'm happy.   

Just a little background... The original poster made the same mistake I seem to have made.  I've written an app that uses active objects extensively.  I started with your pattern from the old "Dr Damien" post, and just modified from there.  Some of the objects are spawned such that their front panels appear in subpanels in the main VI.  I used VITs inside the AOs thinking that was the best way to handle it.  I never got burned by it because so far I've left all methods in my classes as public, figuring I'd clean it up later (I know, I know - hanging my head in shame).  But after seeing this post, I realized I have a timebomb waiting for me.  I'm looking for a convenient way to fix this without having to gut my whole design.  I don't THINK switching my VITs to reentrant VIs will cause a problem, but I was hoping somebody could shortcut the "exploratory coding" I was looking at.  I'll likely just try the reentrant approach and see what changes.  I really want to keep the AOs as single units, with everything in the class.  I just can't see how it would work if I have to pull the VIT out and use only public methods - I'd have to keep just about everything public!  

I'll let you know how it works out... 

Thanks,

Jason 

[Jason_P]

Ben - I finally had time to refactor my project to use reentrant VIs rather than VITs.  So far as I can tell, there isn't a significant difference in terms of execution.  Everything functions the same way, and the instances are properly independent of one another.  I haven't done thorough benchmarks, but it is more than good enough for my purposes.  I did however find something odd when I tried to go from development to executable.  To open a VI reference to the VITs in dev mode, I used option 8.  Everything worked fine... Then when I built an exe, it bombed out.  I had to switch to option 2.  No problem, but when I went back to dev mode, I had to go back to 8 to get it to work.  Not a fatal problem - I just used a conditional to detect which option to use - but it was annoying.

JasonP - CLD

[Jason_P]

Just a quick clarification - I found the odd behavior using my original VIT based approach, not the reentrant VIs. 

[Fedor]

Let me clarify a few points.

Why I am using VIT instead of reentrant VI: I don't think it is possible to use same reentrant VI in more than one subpanel at once. Not so with VIT.

"Is a VI created from a template that is part of a class a member of the class?": from how Labview seems to treat it, it's member of the class if called directly. It is not member if called using VI server. VI server restriction does not seems to apply to non-template VIs.

[Jason_P]

Fedor,

The point of my post was that you CAN use a reentrant VI launched by VI server in multiple subpanels at once.  I'm doing it in both the development environment and a built exe.  I had originally thought that I had to go with VITs as well, but I decided to try the reentrant approach when you reported the issue with protected class methods.  I haven't done a lot of testing, but at first glance it seems to be working correctly.

JasonP - CLD