LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Class gets locked in combination with XControl

Solved!
Go to solution

I have a LVOOP class and an XControl that uses this class in the data.ctl (i.e., the data type of the XControl is actually the LVOOP class).

 

Now, I would like to place this XControl on the front panel of a method VI of the LVOOP class or a child class thereof. As a result, in both cases the class gets locked in the LV project browser. "The library is locked for the following reason(s): A vi in the library is reserved in this appilcation instance or another application instance."

 

What can I do to resolve this problem?

0 Kudos
Message 1 of 9
(3,368 Views)

@dlanger wrote:

I have a LVOOP class and an XControl that uses this class in the data.ctl (i.e., the data type of the XControl is actually the LVOOP class).

 

Now, I would like to place this XControl on the front panel of a method VI of the LVOOP class or a child class thereof. As a result, in both cases the class gets locked in the LV project browser. "The library is locked for the following reason(s): A vi in the library is reserved in this appilcation instance or another application instance."

 

What can I do to resolve this problem?


 

 

An XControl is a VI that runs any time a VI that cantains it, is open for editing or running.

 

A Class is locked when a VI using that class is running or resrved to run.

 

I can see why it will not go onto a method of the class but not the child.

 

Did you try doing in a project that only has the child?

 

Just riddling out loud.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 9
(3,358 Views)

Thank you Ben. Your explanation makes it clearer for me.

 

Having only the child class in the project doesn't help (probably because the parent class is anyway in memory, i.e., in the dependencies).

 

Maybe the reason it doesn't work for the child class either is that a child class has a IS relationship to its parent (i.e., somehow, the child class actually is a special case of the parent).

 

Hmmm... I still hope there is some workaround...

0 Kudos
Message 3 of 9
(3,341 Views)

Hi,

 

would you mind posting a little example of your code with instructions on how to see the exact problem you are running into? I'm not 100% sure I understand what the issue is and this would help with that.

 

Regards,

joseph

0 Kudos
Message 4 of 9
(3,329 Views)

Here is an example project demonstrating the problem. Created with LV2010 SP1...

 

  • Child.lvclass is a child class of Parent.lvclass.
  • The XControl has the Parent.lvclass in its data.ctl.
  • Child.lvclass owns a member VI run.vi that has an instance of the XControl on its front panel.

As a result, every library is locked.

0 Kudos
Message 5 of 9
(3,327 Views)
Solution
Accepted by topic author dlanger

I found the following work-around allowing me to at least proceed using XControls for my purpose:

 

In order to be able to edit the libraries (classes) in the project, you have to temporarily "Unlock library for editing" (via right mouse click) the XControl.
When you are done with changes to the libraries, save the whole project and choose "Apply changes to all instances" (via right mouse click) for the XControl.

 

Note:
- This is only necessary for changes to the libraries (i.e., deleting/adding method VIs or changing their scope or editing the classes' private data (or typedefs used in the classes' private data).
- It is NOT necessary for mere changes to block diagrams or front panels of member VIs.

Message 6 of 9
(3,325 Views)

Thanks for the example code. I was able to reproduce and see the problem more closely.

Unfortunately I think you will simply have to unlock the xcontrol manually as you described to be able to work in the libraries. They end up locking each other in a circular fashion.

I know it's more convenient to use an xcontrol in the method of the class, but the normal was of working for method VIs is to use the class directly on the front panel and not the xcontrol. Remember that member VIs will normally be called from somewhere else and not usually display their front panel.

 

Regards,

Joseph

0 Kudos
Message 7 of 9
(3,312 Views)

@jtagg

 

In my case, the method (run.vi) containing the XControl is displayed to the user due to the fact that its front panel is loaded into a subpanel of my applications main VI. That is also the reason I am using an XControl.

 

That I have to unlock the XControl in order to edit the class is a bit unconvenient, but I can live with it. Maybe it can somehow be prevented in future LV versions.

 

Thanks for the help!

0 Kudos
Message 8 of 9
(3,298 Views)

I am having the same problem. labview locks the whole class tree when using a  subclass from that tree. This design feels a bit unreasonable.

0 Kudos
Message 9 of 9
(718 Views)