Jump to content

Locked Library


Recommended Posts

Obviously the Class is getting loaded or is loaded in other application instance?

But that would suggest there is dependencies between the two projects - but the dependencies tree is has no elements in it (no expand button).

?

Are the classes siblings? If there is a parent class that in one way or the other happen to have a dependancy on its child class I believe this might happen. Check if the second class is loaded when opening the first class.

Edited by MartinPeeker
Link to comment

You're looking at a limitation of classes. If the same class is loaded in two projects, it cannot be edited. Plain and simple as that. It has to do with applying edits from one project to the other in a meaningful order. There are many cases where you can edit a file in one project and another file in the other project and the class, which depends upon both files, has to handle the resolution of those changes, but the order in which the changes are applied matters for how the class finally ends up, and there's no way to resolve the changes.

But that would suggest there is dependencies between the two projects - but the dependencies tree is has no elements in it (no expand button).

And then I read this... jgcode is right... that's very odd... I was assuming that one class used the other and thus they were both loaded in both projects.

Is there a third app instance that you're loading these classes into?

Link to comment

You're looking at a limitation of classes. If the same class is loaded in two projects, it cannot be edited.

I just got the same message and I only use the locked class in a single project.

post-6989-007683300 1285892763_thumb.png

There are no other projects open. For the record, I just installed the LabVIEW2010f2 and RTf1 patches today.

Link to comment

I just got the same message and I only use the locked class in a single project.

post-6989-007683300 1285892763_thumb.png

There are no other projects open. For the record, I just installed the LabVIEW2010f2 and RTf1 patches today.

But you are calling it from two Application instances (PC and RT) --> thats the same thing.

Link to comment

Hmm... maybe so. I can't remember if this was the case before. It doesn't present the same cross-project issue AQ was describing. I don't think there's a reason a change to a called class can't update both callers within the same project. (In the current instance, I just want to resave the class to a new location on disk. I don't remember not being able to do that just because I have two callers--in the same project--before, but maybe I'm wrong.)

Later...

OK I found this link Link on locked classes and it's all consistent, but something still seems not right to me, but probably that's an end-of day-thing. In any event it seems more problematic than I remember it being. There usually is an easy way to work around a class lock, but the solution isn't jumping out at me tonight. Tomorrow morning, then!

Edited by Paul_at_Lowell
Link to comment

....but something still seems not right to me, but probably that's an end-of day-thing....

Nope, its a LabVIEW thing :)

Project = Application Instance

Target = Application Instance

Thats why I now lean towards separate project files for RT targets.

Link to comment

Hi Bjarne

You've already got the lock sorted out now, but I was just wondering why you prefix all methods in the class the the class name?

Any reason?

Cheers,

Mikael

Yes, yhaks for the help:worshippy:

Well, I am just strated to use goop and I am in a learning process.I thourght that naming the methods by class-name I could always see witch class it belong too when I use them in a project.

Regards Bjarne

Edited by Bjarne Joergensen
Link to comment

Nope, its a LabVIEW thing :)

Project = Application Instance

Target = Application Instance

Thats why I now lean towards separate project files for RT targets.

OK, I see. I did find a helpful page on what an Application Instance means in LabVIEW Working with Application Instances.

For the record, I did the following test:

I created a test project in LabVIEW 2009SP1 and added a class to it. I called it in a top-level VI (main1.vi) on the same target, then main2.vi on the same target, and finally in main3.vi on a different target. Only when I added main3.vi to the second target did the class library lock.

post-6989-008417800 1285957301_thumb.png

I do see, then, that is a good argument to create separate projects for RT Targets (which is not what we have been doing), as you suggest. In our situation we have to be sure we handle our networked shared variables correctly, but I don't think that's all that much of a problem since the shared variables are in a project library, and in principle it can be more flexible. (Note that you can update a shared variable project library open in two projects simultaneously, as long as you update the library in one instance if you've changed it in the other.)

OK, the thing that troubles me is the renaming issue (already touched upon in other threads). Let's say I use a class (or any library) in two projects and rename it in one project while the second project is closed (necessary, as we just said, in the case of classes). This will break all the callers in the second project, and I can't just do a quick replace in the second project to remedy that. (LabVIEW tells me the class, for instance is not loaded, but I can only load it with a class of the same name; I can't replace it with the renamed class.) (Hmm... if I copy rather than rename the class then the second class will point to the original, which I can then replace. That might be a workaround, but it is definitely a workaround.) In any case, doesn't that seem like a serious limitation? (It certainly is one we have encountered.) Maybe it would be sufficient if LabVIEW would let you replace an unloaded class with another class (certainly OK if it is just the renamed version, but of course I would expect callers to break if I picked the wrong class). Or is there a better way to deal with this?

I just checked and replace is not an option for a class in a project, even if it is loaded.

Link to comment

After lunch...

OK, this seems to be an argument in favor of packaging things in project libraries. Actually, that's what I am trying to do at the moment--replace code with code in a library. There's actually only one call on the RT side, so it's really not hard at all for me to fix in any event for this situation, but it does kind of point out what I think is a problem. At least at the top level if you go against advice Daklu offered on another thread and change the namespace of something called in another application space, you can end up with broken and not at all easily fixable code.

Link to comment
  • 1 month later...

Hello there,

I am having this problem too but I haven't been able to sort it - can anyone help please?

I have a class which is only included in one project. When I click on the 'why is it locked' option I'm told:

A vi in the library is reserved in this application instance or another application instance.

It's driving me nuts today!

Thank you,

Martin

Link to comment

I am having this problem too but I haven't been able to sort it - can anyone help please?

I have a class which is only included in one project. When I click on the 'why is it locked' option I'm told:

A vi in the library is reserved in this application instance or another application instance.

Hi Martin

Are you using it across multiple targets?

Is its being called by an X-Control in memory?

Maybe some screenshots would help.

Cheers

-JG

Link to comment

HI JG,

Thank you for the reply. I can't get an image past our firewall here at work which is something of a pain but I will post from home tonight. I am using several xControls but they are quite 'dumb' and just plot data that I send to them - they shouldn't have anything to do with my locked class, apart from the notifier reference that they use to share info.

It does sound like I might have a reference to something still open then but I have restarted the machine several times. I'll keep investigating...

Thank you,

Martin

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.