Class cast problem: error appears only once

[_Y_]

Class cast problem: error appears only once

I have got a strange behaviour when dynamically assigning an object to a terminal. The problem appears only at the first run. To get it again, the project or the whole LabVIEW must be reloaded. I assembled a simplified code illustrating the problem.

The project contains:

1) A LVOOP class ClassN. In this example, the class does nothing. It is used only to initialise the object wire.

2) Run-able main.vi that calls Wrapper.vi.

3) Wrapper.vi that calls internal.vi dynamically.

 

Important: object terminals of this VI have type of LabVIEW Object; thus, when main.vi calls it, up-casting takes place.

Wrapper.vi dynamically searches own controls. When the object-receiving control is found, it transfers the value to corresponding control of dynamically called internal.vi; then runs internal.vi.

4) The internal.vi does not do any enjoyable staff but shows a simple message.

Important: object terminals of this VI have type of ClassN; thus, when Wrapper.vi calls it, down-casting takes place.

When running main.vi first time, an error is launched: Error 91 occurred at Invoke Node in MethodWrapper.vi->main.vi Possible reason(s): LabVIEW:  The data type of the variant is not compatible with the data type wired to the type input. Method Name: Control Value:Set

If running main.vi again (and again), the program works without errors. The error re-appears only if the project/LabVIEW is closed then opened again. The same behaviour takes place if I open the whole project or only main.vi.

I tried to simplify code of Wrapper.vi even more (tried to cast the object wire to variant and assign the obtained value; tried to use reference to the input terminal instead of searching for it, etc.) but could not get the same phenomenon.

What could be the reason?

The project is attached.

[JackDunaway]

Important questions before we proceed: could you guarantee that 'internal.vi' can always have the same connector pane (the exact same four terminals as 'Wrapper.vi')? Also, can you confirm that Run VI is indeed intended to have True wired to 'Wait Until Done'? If so, we can proceed, and also dramatically reduce the complexity of your code.

I'm thinking Call By Reference Node or Dynamic Dispatching.

[_Y_]

JackDunaway, thank you for the reply. First, a comment to your suggestion:

I'm thinking Call By Reference Node or Dynamic Dispatching.

Sorry, I did not express myself in a clear way. I do not ask how to solve this particular problem, it is easy. I ask: Why the problem appears? A purely academic interest

And particular answers:

could you guarantee that 'internal.vi' can always have the same connector pane (the exact same four terminals as 'Wrapper.vi')?

No, they do not have the same connector pane. Object terminals of  Wrapper.vi have type of LabVIEW Object while corresponding terminals of internal.vi have type of ClassN.

Also, can you confirm that Run VI is indeed intended to have True wired to 'Wait Until Done'?

I do not think that it is important. The error appears before calling the Run VI. Let’s assume it is so.

[JackDunaway]

---

@_Y_ wrote:

I ask: Why the problem appears? A purely academic interest

---

While I'm trying to recreate the issue, and since this is academic, can you confirm my suspicions that your desired outcome can be achieved using Dynamic Dispatching? (e.g., a single Dynamic Dispatch SubVI placed inside the No Error case with no additional VI Server business)

[_Y_]

JackDunaway, confirm my suspicions that your desired outcome can be achieved using Dynamic Dispatching?

---

I did not think about it. The Dynamic Dispatching suggests a hierarchy of classes (isn't it?). It could be more suitable in main.vi.

May be I do not understand you correctly and thus cannot answer in a good way. Why is it important?

The problem is in dynamic assigning the object to the terminal. Actions of the whole "program" do not matter. As a fact, I can propose ways around the problem even without abandoning the dynamic assigning.

PS: terminals of internal.vi are not Dynamic Dispatch. They are not couplet to the connector pane. I tried with coupled and non-coupled terminals but it did not affect the phenomenon. So, I uploaded the simplest variant.

[JackDunaway]

Try one more thing for me to see if we can recreate the error without needing to exit LabVIEW: between two subsequent runs, go to the file menu and select "Edit >> Reinitialize Values to Default" on all the VI's. If you do this, do you receive the error on the next run?

[JackDunaway]

---

@_Y_ wrote:

JackDunaway, confirm my suspicions that your desired outcome can be achieved using Dynamic Dispatching?

---

The Dynamic Dispatching suggests a hierarchy of classes (isn't it?).

---

Yes. Dynamic Dispatching is run-time polymorphism where child classes are able to have different datatypes wired to it's terminals, given the child's terminal is the same type as or a descendant of the input wire.

[_Y_]

---

JackDunaway, wrote:

"Edit >> Reinitialize Values to Default" on all the VI's. If you do this, do you receive the error on the next run?

---

No, it does not have any effect. Only the first run cuases the error.

---

JackDunaway, wrote:

Yes. Dynamic Dispatching.......

---

So, probably Dynamic Dispatching is not the source for this error. The project has only one class; there are no Dynamic Dispatch terminals in VIs.

[_Y_]

I tested the problem in different computers with defferent versions of LabVIEW. The results is version dependent:

The error appears only if LabVIEW 2010 is used. LabVIEW 2009 and 8.6 do not show any error.

Bug?