Locked Library

[Bjarne Joergensen]

Hi

I am just started to use GOOP (Symbio), but I got a problem wiht two classes(se picture)

Both is locked for modifying

Is there a way to unlock them or a way to find the reason for the locked state?

Hope someone can help me.

Thanks in advance

/Bjarne

[Aristos Queue]

Right click on the class in the project tree and select "why is this library locked".

[jgcode]

By looking at it, it doesn't seem to be Locked under Properties >> Protection >>Locked/Password-Protected as the private-scoped folder is shown.

Might be a loading issue?

[Bjarne Joergensen]

Hi again

When I hit " Why is library locked" I got this message (se picture), but I can't figure out what to do about it.

When I only open one of the Class librarys, it don't get locked.

When I open both they get lokcked - sometimes it's only one of them that get locked.

regards Bjarne

[jgcode]

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).

?

[MartinPeeker]

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 September 24, 2010 by MartinPeeker

[Aristos Queue]

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?

[PaulL]

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.

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

[jgcode]

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

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.

[PaulL]

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 October 1, 2010 by Paul_at_Lowell

[jgcode]

....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.

[ShaunR]

Nope, its a LabVIEW thing

Nope. Its an OOP thing

[jgcode]

Nope. Its an OOP thing

OOP as in LVOOP as in LabVIEW OOP?

[ShaunR]

OOP as in LVOOP as in LabVIEW OOP?

Hope you're pronouncing that correctly

[MikaelH]

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

[Bjarne Joergensen]

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 October 1, 2010 by Bjarne Joergensen

[PaulL]

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.

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.

[PaulL]

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.

[MartinMcD]

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

[jgcode]

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

[MartinMcD]

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