Greg Hupp Posted July 17, 2008 Report Share Posted July 17, 2008 I have an compiled application (.exe) that dynamically calls VIs to load into a subpanel. If any of the subVIs in the dynamically called VI are broken or missing (in the distribution), an error is thrown, albeit a general error saying can't load the dynamically called VI. Is there any way to report which of the subVIs are broken? These dynamically called VIs use many subVIs so figuring out which one is broken or missing can be a guessing game. Quote Link to comment
mje Posted July 17, 2008 Report Share Posted July 17, 2008 I guess I'm a little lost as to the question. By saying you're dynamically calling a VI, I'm assuming you mean calling it by reference, which there are multiple ways of doing. Some code showing how you're loading would help clear the situation up. A few stabs in the dark: Are you referring to VIs that load when you're in the development environment, but not when compiled and using the runtime? If so, and you're using a relative path to obtain a reference to the VI, keep in mind there's an extra path level for VIs when in the runtime environment (something located at ../foo.vi during development becomes ../../foo.vi in the runtime). The other possibility is if you're not using a strict reference to the VI, the compiler won't know to include the VI (or any of it's subVIs) into the final application since you never directly reference it. You'll need to specify in the build options to include the VI, at which point the compiler should include it and all its subVIs (except of course, other non-strictly referenced VIs). Quote Link to comment
Norm Kirchner Posted July 17, 2008 Report Share Posted July 17, 2008 I've worked w/ Greg on this a bit and it's definitely not a simple problem. Built exe w/ a sub-panel You can load a VI not built into the exe into this subpanel. The problem is the VI attempting to be loaded is missing a sub-vi for some reason (trust me on this, don't worry why) How can you determine what VI is missing (cannot be found)from a dynamically loaded vi (using OpenVI ref) Think plugin, Exe is installed on PC, and you download the plug-in. But because of some oversight, the plugin is missing a vi. How do you determine what sub-vi is missing because OpenVI Ref only says that "a" vi is missing? Quote Link to comment
eaolson Posted July 17, 2008 Report Share Posted July 17, 2008 QUOTE (Norm Kirchner @ Jul 16 2008, 04:05 PM) How do you determine what sub-vi is missing because OpenVI Ref only says that "a" vi is missing? Interesting question. I didn't notice this before, but if you just use Open VI Ref with a path to the plugin VI, you won't get an error. If you wire a type specifier to create a strictly typed VI refnum, you do get error 1003 when you try to load the plugin VI. In the first case, you get a valid refnum, but the Callee's Names property does not contain the name of the missing VI. Same with Callee's Paths. In the second case, you do not get a valid refnum, so you can't use the property node. If there is a solution (other than walking through the VI as a binary file and looking for subVIs), I'm stumped. Quote Link to comment
mje Posted July 18, 2008 Report Share Posted July 18, 2008 Ah, I better understand the problem. So they dynamically loaded VI is failing to load a subVI. Is that subVI by chance also dynamically loaded? Forgive me if I'm running through the obvious, but one thing I've noticed, see the diagram/panel below: If the reference to the dynamically loaded VI is successfully found, no error is returned through the reference and call by reference call chain. It will be the responsibility of the called VI to pass on any errors, including failure to load, and it tells me what failed to load. I suppose you don't have the ability to check the error state of the called VI? Quote Link to comment
Antoine Chalons Posted July 18, 2008 Report Share Posted July 18, 2008 QUOTE (Norm Kirchner @ Jul 16 2008, 11:05 PM) How do you determine what sub-vi is missing because OpenVI Ref only says that "a" vi is missing? I never really tried to use a plugin architecture in LabVIEW, but many people have and with success I think. http://forums.lavag.org/Calling-an-external-LabVIEW-VI-from-an-EXE-t3161.html' target="_blank">This thread deals with some similar problems, I hope it can help you. Quote Link to comment
LAVA 1.0 Content Posted July 18, 2008 Report Share Posted July 18, 2008 I can't help with the Q re: figuring it out from the exe, but I can share how I avoid this. I use Tree.VI also called a catalog.VI or in this post by Greg McKaskle, "Fakeroot.vi". I make sure this VI is open why editing. As long as the tree is OK my app is OK. Just trying to help, Ben Quote Link to comment
Norm Kirchner Posted July 18, 2008 Report Share Posted July 18, 2008 QUOTE (neB @ Jul 17 2008, 08:38 AM) I can't help with the Q re: figuring it out from the exe, but I can share how I avoid this.I use Tree.VI also called a catalog.VI or in http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=3291#M3291' target="_blank">this post by Greg McKaskle, "Fakeroot.vi". I make sure this VI is open why editing. As long as the tree is OK my app is OK. I thought of this too, but because he's already using a project and dependencies to grab a full list of sub-vi's as possible, the tree may just be as error prone. I'm starting to think that he could try to make a separate loader VI for each plugin that would be created before distributing that would have a bottom up listing of SUBvi and check them 1 at a time first by existence of file and then make sure that the VI is runable, that way we could find which one is missing and which ones are broken because of it. Greg, this would be similar to the splash screen. It could be distributed with the plugin or only after someone complains that it's missing. You could make the tool when requested, then send it to them and have them send back the log of what worked and didn't. Quote Link to comment
LAVA 1.0 Content Posted July 18, 2008 Report Share Posted July 18, 2008 QUOTE (Norm Kirchner @ Jul 17 2008, 11:49 AM) ...that would have a bottom up listing of SUBvi ... You have a VI that produces this list? Ben Quote Link to comment
Norm Kirchner Posted July 18, 2008 Report Share Posted July 18, 2008 QUOTE (neB @ Jul 17 2008, 11:13 AM) You have a VI that produces this list?Ben Maybe I do....what's it worth to ya? Quote Link to comment
LAVA 1.0 Content Posted July 18, 2008 Report Share Posted July 18, 2008 QUOTE (Norm Kirchner @ Jul 17 2008, 12:33 PM) Maybe I do....what's it worth to ya? You show me yours and I'll show you mine. Ben Quote Link to comment
Greg Hupp Posted July 26, 2008 Author Report Share Posted July 26, 2008 OK...so I can get a list of the bad VIs by recursive searching and looking for the bad VIs in the tree using the Callees property node. I created a subVI to do this and it works real slick. Unfortunately, the Callees property does not report any VIs that are missing in the subVI...so I can get the bad parent VI, but that is as far as I can go. It is better than I had, so thanks for all the suggestions. Anyone got any further/other ideas on how to report a missing VI? Quote Link to comment
Norm Kirchner Posted July 26, 2008 Report Share Posted July 26, 2008 (edited) That was very surprising to hear that callees did not return the missing VIs in it's array.... but I believe that I have found a potential work around (using some hidden properties) What this does is caches and clears the search paths so the app doesn't spend 10 min searching your HD for a file that we already know probably doesn't exist. Opens a ref to the VI and lists any issues w/ links to other VIs then it sets the search paths back. Give this a shot and be careful on the rusty nails coming up out of the floor boards {See link for nail ref} (New link to scripting subforum after rusty nails was merged) Edited October 16, 2018 by hooovahh Rusty nails was merged into scripting, link updated Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.