Owning library has blocked execution of the VI

[dkfire]

Have you tried to remove both the Config.DB.lvclass and the DB-Configuration.lvlib ?

And saved and reopen the project. 

[dkfire · Accepted solution]

---

 

You stated, "If a parent or a child of a class is having an error in a method, the rest of the children can be locked."

As Configuration.lvclass is a child of Interface.lvclass and DB-Configuration.lvclass is a child of the Configuration.lvclass, you say, the parents must not be executed anymore? While I do not doubt your words as this seems to be reality, I wonder WHY?!

That is like because one new car design fails working, the whole concept of cars gets forbidden. This makes it virtually impossible to work on existing, executable code without rendering it useless for other users - really without any need.

As the working hypothesis is that this child needs to be aborted (is that a proper OOP term?), how can I do that? Removing it from the project (taking it away from the family) obviously was not enough...

On the other hand, the other child of Interface.lvclass, Configuration.lvclass, which is runnable has two own children. Ini-File.lvclass is properly implemented, while XML-File.lvclass only consists of the .ctl with no implementation done till now (rendered as "not ok", albeit it is only an empty cluster).

This is just confusing to me by now.

---

The thing is, that when working with OOP, you have the posibility to dynamic change a child class out from one to the other, as long as they have the same parent. You can can atually dynamicly load a class at runtime.
So if your parent class define a public method, lets say Open.vi. You can, in your class redefine the implementation by making the childs own Open.vi. 

If you then place the parent's Open.vi on a block diagram, LabVIEW will check that all the defirent implementation of Open.vi is able to run. That said, all the implementation in memory.

Now, the thing is that LabVIEW can't unload a class once it is in memory. So if you remove a class from the project, the class is still in memory and thereby LabVIEW will still try to validate Open.vi. 

To be able to unload the class from memory, all classes/vi in a project are loaded into memory when you open the project, you need to remove the class from the project, save the project, close LabVIEW and reopen LabVIEW/porject.

To the last question: A child class don't have to implement anything. It don't have to overwrite anything, unless the parents method is set to Must overwrite. For the Interface.lvclass, non of its method are set to Must overwrite, and therefore its child classes can be with no methods.

Of cource you can then ask, why make the child if it doesn't do any special thing.

Did it make any sense?

[Questionmarker]

---

dkfire wrote:

The thing is, that when working with OOP, you have the posibility to dynamic change a child class out from one to the other, as long as they have the same parent. You can can atually dynamicly load a class at runtime.
So if your parent class define a public method, lets say Open.vi. You can, in your class redefine the implementation by making the childs own Open.vi. 

If you then place the parent's Open.vi on a block diagram, LabVIEW will check that all the defirent implementation of Open.vi is able to run. That said, all the implementation in memory.

Now, the thing is that LabVIEW can't unload a class once it is in memory. So if you remove a class from the project, the class is still in memory and thereby LabVIEW will still try to validate Open.vi. 

To be able to unload the class from memory, all classes/vi in a project are loaded into memory when you open the project, you need to remove the class from the project, save the project, close LabVIEW and reopen LabVIEW/porject.

 

---

First of all, removing the DB class, saving and restarting LabVIEW did the trick for me. I understand that dynamic dispatching requires vi s to be executable. I did not realize that LV has to compile them before runtime and thus must fail and renders the overloaded parents methods useless as well.

I do not understand why Labview cannot unload classes, especially during editing (not executing) - I think it would be very helpful if one could just "hide" a branch one is working on from the compiler - so I can program and if need be, switch back to a working environment to actually do something. Furthermore, everytime I create a class and reconsider, I have to restart - if it was a normal Typedef I could just delete or at least ignore it. I do not see the need of all classes having to stay in memory; this is confusing and frustrating especially for beginners.

---

dkfire wrote:

A child class don't have to implement anything. It don't have to overwrite anything, unless the parents method is set to Must overwrite. For the Interface.lvclass, non of its method are set to Must overwrite, and therefore its child classes can be with no methods.

Of cource you can then ask, why make the child if it doesn't do any special thing.

 

---

I actually like the childs not doing anything (yet) - they allow to plan the project and to create more handable work packages. From my point of view these classes emphasize the concept and helps sticking to it. By the way, is there an easy way to figure out which methods have to be overwritten, e.g. why arent they created by default to be filled out by the programmer? Right now it feels like one has to klick through all the properties which is confusing and not very helpful. I would expect a graphical programming language to show this a bit more convenient, maybe similar to the class hierarchy window.

After all, thank you very much for your explanations, they were insightful and I feel like I understood the reasoning behind it. When I encounter this problem again, I will be able to figure it out on my own. Thanks and Kudos dkfire (-:

[dkfire]

More insight I hope:

About unloadinjg a LabVIEW class from memory, no matter if it in project or exe, is the way NI has implemented class, and I think it relates to the general way LabVIEW handles memory. Nothing we can do about that at the moment, we just have to know about it. 

I'm glad it fixed your problem.

Regarding the override and Must override, then there is a feature when creating a child class.

Once you have setup a class to be a child of another class, you can right-click on the child, select New->Vi for Override. This will give you a list of methods from the parent that you can override, the methods on top with a * by the name is the one you have to override.

I hope you have read the following:

LabVIEW Object-Oriented Programming: The Decisions Behind the Design

Or

Applying Common Object-Oriented (OO) Design Patterns to LabVIEW

[Questionmarker]

Ah I just realized the star, thats a nice help indeed, but not as much as it could be.

Yes, I read the links, but I have to say, I am not a "natural" programmer, I am a physicist and I am mostly learning by doing - thus, I did not read the book of the Gang of Four that it references a lot. That being said, I have a hard time understanding the text, as it is meant for professionals, just like the mentioned book. E.g. I have no clue why it is useful to have a singleton pattern.

I see the advantages of OOP as I use it in other languages, although I probably do not use the full potential. LV OOP is partly confusing to me, just like first times labview until I got the gasp of sources and sinks - and design patterns. While there are well established courses (Core1-3) there is no good/extensive material for LV OOP.

Ultimately learning LV and other languages like Java and Python helped me as I utilize the different tools in both text and graphical programming - I hope for the same effect with LV OOP.