Robbie Gehbauer

Actually, that VI is in the palettes. It's in the Cluster, Class, & Variant palette.

QUOTE(Paul_at_Lowell @ Oct 15 2007, 11:20 AM) Just a warning about creating override from New>>VI from Dynamic Dispatch Template... There are certain VI properties (like reentrancy) which are required to match between base implementations and override VIs. I don't know them all off the top of my head, but they are documented in the help. If you've modified any of these in the base implementation and don't modify them in the override, the override VI will be broken. Yes, the Error List will tell you what you need to fix, but that might be kind of a hassle for you. Even worse, though, might be properties that are NOT required to match which you set in the base implementation, but don't think about setting up in the override, even though you intended to have them match in the override VI. These kinds of things might even slip through your testing undetected. I'm not saying you should never create an override by starting with New>>VI from Dynamic Dispatch Template. I just want to raise awareness of a possible gotcha. Personally, I think it's faster to start with the New>>VI for Override and ctrl-drag to make space. Usually I delete the CPN, sometimes I don't, but starting this way ensures that I won't have to worry about what the front panel looks like (assuming I like how it looked in the parent class) or wiring up the connector pane or having to set anything up in VI Properties.

QUOTE(Paul_at_Lowell @ Oct 15 2007, 09:39 AM) I agree with you. I think there are use cases where copying the entire implementation of the parent would be useful, but I think it's very rare and I also think it's a bad practice to ENCOURAGE. I'd hate for people to accidentally end up with a maintenance nightmare (i.e. having to go fix 20 different places where they did the same thing, when it could have been nicely wrapped up in a call parent node) because we made it too easy to make a bunch of copies of their code. So, I agree that a blank "template" makes more sense. However, oddly enough, what may seem like the easier solution (creating an empty case structure as opposed to copying all the code) is actually a more difficult problem to solve. As AQ mentioned, sometimes people don't have/want error handling in their VIs. So, programmatically, what would we wire into the case structure? What's so nice (from a usability standpoint) about the Call Parent Node, and even copying the entire implementation for that matter, is that there's no guesswork about what the user wants. With the Call Parent Node, what we create is guaranteed to run and give them the same behavior as a starting point for them to then add subclass-specific functionality. We have also considered having an error case structure in the new Override VI which uses the Call Parent Node (CPN). Assuming there was no "what if there's no error handling" problem, we'd still have to guess about whether users would want 1) to have the CPN inside the case structure, 2) to call the CPN first and then wire the error out into a case structure or 3) to have a case structure with the error wired through into a CPN called after the specialized code. If we put the CPN inside the case structure, most users would probably still need to drop an additional case structure inside the first to check the error coming out of the CPN, right? So, it doesn't seem like there's a one-size-fits-all solution. Thoughts?

Yes, you can change this to Get/Set. I pull those strings from the global CLSUIP_LocalizedStrings.vi. So, you can just change those two strings by opening <labview>\resource\Framework\Providers\LVClassLibrary\NewAccessors\CLSUIP_LocalizedStrings.vi and changing "Read %s.vi" to "Get %s.vi" and "Write %s.vi" to "Set %s.vi". Then don't forget to pop up on each and select Data Operations>>Make Current Value Default. Save and close the VI and you're good to go! You don't even have to restart LabVIEW. And FYI...if you reinstall or have a new installation, you'll have to repeat this procedure.

Hit Ctrl-C with the Search Results window active, and it will format all the entries in the listbox and you can paste/save it however you want. This was broken in 8.0, but worked before 8.0 and works again in 8.2. Is this what you mean?

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.

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

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