Invoke Node: LVClassLibrary -> AddItem not working

[LAVA 1.0 Content]

Hi,

I've the following problem, can does anybody know a way around. I try to programmatically add an empty folder to LabVIEW class and then fill the folder with a number of methods.

I open a class by path to lvclass file using LVClass.Open method of Application class. I then try to create an empty folder to the class using LVClassLibrary.AddItem method. I wire "Folder" as a type, empty path as a path and some name as a name. Everything works fine if the class I'm operating isn't inside another library. However, if the class belongs to a containing library, then I get an error message: Error 1055 occurred at invoke node, "LabVIEW: Object reference is invalid." The error is generated by the LVClassLibrary.AddItem invoke node. What do I do wrong?

p.s. Please do not move this topic to scripting, at least not before LV developers have had some time to answer...

[Robbie Gehbauer]

It doesn't look like you're doing anything wrong. Are you sure that your LVClassLibrary reference coming out of App:LVClass.Open is valid? I just tried a more simple version of what you have (just two nodes--the Open and the AddItem, all with constants wired in) and it succeeded without problem.

The fact that your getting error 1055 (Object reference is invalid) is very wierd. If you got an error in the Open, assuming you've correctly chained the errors (which it looks like you have), you should be getting error 7. That's what I get if I give it a bad path.

I guess I'd suggest starting as simply as possible, like I did, get it working, and then build it up, checking to make sure it still works with each addition. Maybe we can narrow it down to what's causing it to fail. Or maybe it'll just start working, leaving us to scratch our heads. You can also post your VI and I can see if I can find anything wrong in it.

Sorry I couldn't be more help,

Robbie

[LAVA 1.0 Content]

I guess I'd suggest starting as simply as possible, like I did, get it working, and then build it up, checking to make sure it still works with each addition.

The error is not generated by LVClass.Open but by LVClassLibrary.AddItem - therefore the error code is also related to this. The reference returned by open seems to be valid at least according to built-in probe. The error occurs only if the class is part of a library, for example MyLib.lvlib:MyClass.lvclass. If you create a class that is not part of library, then there is no error. I also tried to get the reference interactively from an active project browser, by checking the which items were selected and getting reference to these items. The same error occurs.

Edit: Robbie Gehbauer, I noticed it's your first post. Welcome to LAVA!

Edit 2: I created a dummy project and was unable to repeat the problem in this project. So it seems the error is somehow related to my real work project. I cannot post my project here since it is non-public. I have got LabVIEW 8.2 to crash so many times that I may very well be that the project is somehow corrupted, even though it seems to be functional. Any ideas how to fix a corrupted project. I cannot go back to non-corrupted backup since I have no idea when the corruption has occurred. I also have no wish to code everything again. I cannot use "Save as" for my libraries since this is the easiest way to get everything meshed up and to get LabVIEW to crash. This is a problem that never occurs in text based programming languages.... :question:

[Robbie Gehbauer]

I know we ran into a few problems related to classes in libraries during development, but to my knowledge, we don't have any open issues. Like last time, I gave it a try. I tried programmatically creating a folder in a class that's in a library, but I didn't run into any problems. I tried nesting it in two libraries, still worked fine.

The only other thing I'm wondering is whether you might be attempting to edit the class in two different application instances (i.e. two projects). This might fail (though I wouldn't think error 1055 would be what you'd get) if you have unsaved edits to the class in one app instance and then try to programmatically open the class in another context and try to edit it. Actually, YEP! I just got error 1055 when I tried to do this. So, if this is possible for you're application, if you have the VI that edits the class in the same project that the class is in, this could fix your problem. Otherwise, you should be able to get a reference to the existing class in the app instance (project) it's already opened in, rather than opening a new one in a different app instance.

I'm really sorry about your crashing bugs! If you have anything reproducible that you can report, please do. I know that takes time, but if we can fix it, it may save you time in the long run.

Robbie

[Aristos Queue]

Edit 2: I created a dummy project and was unable to repeat the problem in this project. So it seems the error is somehow related to my real work project. I cannot post my project here since it is non-public. I have got LabVIEW 8.2 to crash so many times that I may very well be that the project is somehow corrupted, even though it seems to be functional. Any ideas how to fix a corrupted project. I cannot go back to non-corrupted backup since I have no idea when the corruption has occurred. I also have no wish to code everything again. I cannot use "Save as" for my libraries since this is the easiest way to get everything meshed up and to get LabVIEW to crash. This is a problem that never occurs in text based programming languages.... :question:

Jimi: Try loading your project into memory, get all your VIs into memory (by opening the FP of all your top-level VIs) and then do ctrl+shift+click on the run arrow. This will force a recompile of all VIs in memory. I'm tracking a bug where you make an edit to the class' private data control and save the change. We recompile all the VIs that bundle/unbundle the class. Then you exit LV without saving all the VIs. When you next load, we don't seem to be noticing that the types are out of date and so we aren't recompiling the bundle/unbundle VIs automatically. So they have stale memory addresses and may crash when run. Forcing a recompile of all the VIs in memory catches these guys and brings them up-to-date.

This was reported to R&D (# 40667H1W) for further investigation.

[LAVA 1.0 Content]

Jimi: Try loading your project into memory, get all your VIs into memory (by opening the FP of all your top-level VIs) and then do ctrl+shift+click on the run arrow. This will force a recompile of all VIs in memory. I'm tracking a bug where you make an edit to the class' private data control and save the change. We recompile all the VIs that bundle/unbundle the class. Then you exit LV without saving all the VIs. When you next load, we don't seem to be noticing that the types are out of date and so we aren't recompiling the bundle/unbundle VIs automatically. So they have stale memory addresses and may crash when run. Forcing a recompile of all the VIs in memory catches these guys and brings them up-to-date.

This was reported to R&D (# 40667H1W) for further investigation.

About your proposal, I'm writing currently a toolkit which doesn't have any main level VIs. It only contains classes and subVIs used by the classes. There are hundreds of methods and hundreds of subVIs used or referenced in the project. Is there any easy way to force updating the links with no main VIs?

I manually forced LabVIEW to mass compile the project a few hours ago, before your proposal. It's still mass compiling although I think it's close to the end now (592 VIs loaded). There are between 500-1000 VIs referenced in the project so compiling process seems to be quite sticky.

I ended up mass compiling since I couldn't start LabVIEW anymore. One of the class probes, Icon Probe of my Class Iconizer project also published here at LAVA, located under user.lib started to load all of the VIs of all other projects under user.lib to memory at LabVIEW startup. I got tired of waiting more than 30 min to get LabVIEW even started. I don't know why this happened. The reason must be realted to the fact that yesterday I added hundres of method VIs for operating different data types to my main project which was also located under user.lib. The Icon Probe was not part of this project, the only relation was that both projects were under user.lib. This Icon Probe doesn't in any way reference any of the classes or VIs it was loading at LabVIEW start up. So I moved all my projects to another directory, and LabVIEW started with normal speed. However the links to actual files in the moved projects were now broken. I fixed the links by manually browsing each and every file that wasn't contained in a library or a class. Libraries and classes seemed to have stayed intact. Because I wasn't very trusting in LabVIEWs ability to update links, I decided to mass compile all the files in my most important project. So slow and frustrating. :headbang:

[Aristos Queue]

I ended up mass compiling since I couldn't start LabVIEW anymore. One of the class probes, Icon Probe of my Class Iconizer project also published here at LAVA, located under user.lib started... <snip>

Mass compile won't fix this bug -- the whole problem is that LV doesn't think there's any reason to recompile. Mass compile does a load, check for whether anything has changed, and only do recompile if it needs to.

To fix the Icon Probe bug, find this token in your .ini file:

ProbeDefaultCache

Delete the problem probe from the list of paths.

If you don't have one or two top level VIs that will load everything, you can write a quick VI Server routine to load all the VIs in a directory. Once everyone is in memory, use the ctrl+shift+click on run arrow that I mentioned before.

None of this, by the way, is correct expected behavior.

*sigh*

[LAVA 1.0 Content]

If you don't have one or two top level VIs that will load everything, you can write a quick VI Server routine to load all the VIs in a directory. Once everyone is in memory, use the ctrl+shift+click on run arrow that I mentioned before.

Thanks a lot for your help! I'll try the trick after my mass compile finnishes, LV has been compiling my project for a little over four hours now. I still verify that aren't the VIs in memory when I open a project containing them? So I still explicitly need to open a reference for each VI, method VI, control, polymorphic VI, library, class and VI template in my project and after that do the ctrl+shift+click trick?

None of this, by the way, is correct expected behavior.

Good I eagerly wait for the maintenance release 8.2.1... and most probably also for the maintenance release 8.2.2

Honestly Aristos, I very much appreciate your active presence here at LAVA forums and your ever lasting strength to help us with problems related to these new LabVIEW 8.20 features!

[Aristos Queue]

I still verify that aren't the VIs in memory when I open a project containing them? So I still explicitly need to open a reference for each VI, method VI, control, polymorphic VI, library, class and VI template in my project and after that do the ctrl+shift+click trick?

That's correct. Opening a project simply opens a file listing. It does not load all the VIs into memory (the project is designed to be a manager for very large projects where you might not want all the VIs in memory simultaneously). The same is true for a library -- .lvlib files do not load all their VIs into memory.

.xctrl and .lvclass files do load all their member VIs into memory.

VIs load their entire subVI hierarchy into memory, and polymorphic VIs load all of their instances into memory.

Summary:

File extensions that do not load all of their referenced files into memory:

.lvproj

.lvlib

File extensions that do load all referenced files into memory:

.vi

.ctl

.vit

.ctt

.xctrl

.lvclass

[LAVA 1.0 Content]

That's correct. Opening a project simply opens a file listing. It does not load all the VIs into memory (the project is designed to be a manager for very large projects where you might not want all the VIs in memory simultaneously). The same is true for a library -- .lvlib files do not load all their VIs into memory. .xctrl and .lvclass files do load all their member VIs into memory.

This distinction between class and library explains why my library of hundreds of subVIs worked very well as a conventional subVI library. Now I have encapsulated the same behaviour into a class hierarchy which also includes several hundreds VIs and LabVIEW seems to freeze when I open the project containing the class structure. If I understand you correctly opening the project should not open the classes within the project, but... it still takes a very long time to load the project. Well, I figure out something.

So as a summary I can create huge projects containing conventional VIs, but the same is not (currently) true for OOP projects.

[Robbie Gehbauer]

If I understand you correctly opening the project should not open the classes within the project, but... it still takes a very long time to load the project.

Actually, I think Aristos was a little ambiguous. loading projects do load some "referenced files". They will load their libraries. For regular project libraries, this means it will not load any of their VIs, but for classes and XControls, it will load VIs/CTLs/sublibraries/parent classes/etc. that belong to them. That is why probably why loading your project takes a such a long time. Those VIs are all being brought into memory.

Unfortunately, this behavior actually is expected, though we realize it is not ideal. Aristos can explain better than I why this is necessary.

[LAVA 1.0 Content]

I suggest that we move this discussion to a new topic that I created. This discussion is not related Invoke node problems but to large scale application design using LVOOP.