Unbundle by name within dynamic VIT class instantiations creates a broken run arrow. (Error 1003)

[Evan R.]

Now that's a mouthful!

It turns out I wanted to combine OOP with dynamic thread allocation. I am trying to write a client/server program. The architecture I've opted for is an OOP approach which has a TCP listener that instantiates a new object of type "Client" upon connection. Then I use a state machine method of the Client class to handle the protocol as I've defined it for this particular application.

If any of that makes sense, you may be thinking - this is a good candidate for a VIT. I am also open to alternative methods, but what I've got works rather well right now.

I am using a VIT to launch each state machine as a new thread within the development environment. This makes sense because each client / state machine will be created at different times, we need to support multiple incoming connections, and those connections could end at any time. As a result, I used the VITs to dynamically copy the state machine class member VI.

It turns out that I was using bundle / unbundle of the class typedef (member data) inside the state machine VI. This causes dynamically created VIs from the VIT to have a broken run arrow. You must not use bundle/unbundle from within these VIs.

Workaround: Instead, use accessor methods and mutators to read and manipulate class member data.

Get in touch with me if you're curious to learn more about this.

Best,

Evan

[Ben]

Aristos Queue and I had an exchange over this issue a while back. The behaviour you observed represents the "safe approach" to handling VITs and LVOOP.

That behaviour occurs even if the template is made a member of the calss library.

The core question is "Is a template created from the lbrary really a member of the library?"

The "Safe" approach closes loop-holes that would allow VIT's to be created either from within or outisde the libaray.

It sounds like you figured out the work-around "Use only public methods" in the VIT.

Since you are walking this ground could I ask a related Q?

What kind of memory usege per VIT instance are you seeing?

I ask becuase in an app that I developed that used a similar approach, the "memeory footprint" for each instance created limited the total number of instance to less than 200 instances.

What have you observed?

Ben

[Evan R.]

Hi Ben,

I've seen your comment and I am taking the issue up with our AEs. You're right about the core question, but let me try to word it slightly differently: "is a VI dynamically created from a template within a class library really a member of the class library". I think that NI R&D has decided that the answer is no. This I'm guessing as you indicate has something to do with safety. I also understand that this behavior is designed, and expected. I would like to know why however. Not that I disagree, I just want to be better educated.

Also - to answer your question about memory footprint, I don't have any metrics right now. I am looking at a situation of having fewer than 15 instances of the VIT, so I doubt I'll be of much help to you.

Cheers,

Evan

[Ben]

Hi Evan,

before you ping Aristos Queue, take a look at his reply (post # 26) in this thread on LAVA.