"vi is not executable" built app - product feature request

[smercurio_fc]

OK, here's what I want for the next version of LabVIEW. Forget a real implementation of OO. Forget about making XControls so that you don't need a PhD to program them. Forget about a real polymorphic control (down all you who say "variant!"). Here's what I want for the next feature of LabVIEW.

I want the run-time engine to give me a better idea of why a built application won't run. The generic "This VI is not executable. The full development version of LabVIEW is required to fix the errors..." is meaningless. If the VI works just fine in the development environment, and it builds without errors, why does it not run? If there's so many reasons, how is one supposed to track it down?

I've been using LabVIEW since version 2 on a Mac, so I like to think that I know what I'm doing with it. Yet, whenever I run into this I feel helpless because I have NO information! This is frustrating beyond my ability to put into words. And please don't tell me to look at this article or this other article in your KnowledgeBase. Been there, done that. In one situation I tracked the problem down to a VI. Couldn't find ANYTHING wrong with it. So, I created a new VI, copied the block diagram over, and saved the new VI over it. Rebuilt the app, and presto, the app worked. Do you know how long it took me to track it down to that VI? About half a day. Was there ANYTHING that gave me a clue as to the problem? Can you say rhetorical question?

I'm posting this here in the hopes that enough people get my grief, and head over to the Product Suggestion Form to hopefully make this pipe dream a reality. Power to the people!

Now, back to figuring out why my latest built application won't run. Guess what I'll be doing for the next half-day or so.

[Xaq]

Actually, there are a few good knowledgbase articles......OK, just kidding. I would have to agree that error reporting could always be more specific and that there are cases when errors are just flat out not helpful. There seems to be a balancing act between too much information and not enough included in errors. Take the windows BSOD for an example of too much information for 99% of windows users. Most people don't care about the memory address of the kernal module that crashed or know what to do with it, but it is helpful to those who know what to do with it.

I think the best suggestion is to have a simple link with more information about the crash or error in question (i.e. where it happened, a specific error code, and suggestions for fixing it) for advanced users.

[smercurio_fc]

Well, you can't really balance against no information, which is what you get with the error I'm talking about, so I don't see how it helps at all the way it is now.

In the application that I was trying to build, for example, I tracked the problem down to a single VI after about three hours. I'm dealing with an application that has over 1200 VIs, so each time I delete a chunk of code to try to isolate the problem I have to go through the rebuild and test the app. What was wrong with the VI? Nothing, as far as I could tell. I took another VI and copied it on disk. Renamed it to the VI that was supposedly bad, changed two property nodes, resaved it, rebuilt the app, and presto the app now ran.

I'm just waiting for the next time this happens...

[chrisger]

smercurio, i can't help you, but i'm with you, maybe that makes you feel better.

i upgraded a LV-app i created originally with 7.1 (this was the best LV ever, in my opinion) to 8.20. i was forced to do that because of the 64bit feature of ms tickers. it took me about 4hrs to create a project to generate an executable, after several LV-crashes during editing. finally i managed to get the project working (compiling took about 10 mins, with the 7.1 app builder about 1 min!! same code!!!), and then there was this error message: "error blabla in VI blubblub", and the VI was part of the vi.lib! so what to do?

KB: no answer!
discussion forum: no hits!

i found a post in the forum about another error code, but the same scenario. workaround was to disable the "remove as much as possible" option in the advanced project settings.

result: size of executable increased about 100%, while execution speed decreased about 50% compared to the 7.1 version, though all of the "code enhancement features" of 8.20.

now i'm thinking of switching back to 7.1 and to workaround the limits of long execution times with 32bit tickers.

i'm a big fan of LV, and i'm dealing with it since 1998, not for fun, but as a professional programmer. but 8.2 is a real step backwards in quality in my opinion. i think this has to be said to make 9.0 better!

[smercurio_fc]

Thanks for the vote of support. I tried that setting as well, but that had no effect. Believe me, I tried a lot of things.

I've seriously considered going back to 7.1 since the only reason we upgraded to 8 was that in the specific application I'm doing I'm dealing with a .NET library that uses callbacks for some functionality. Well, .NET callbacks are not supported in 7.1 but are in 8. As it turns out, they didn't work too well in 8, and I ended up having to write my own .NET wrapper library to perform that functionality, which pretty much negated the need for 8. We upgraded to 8.2 because we got it as part of our SSP, and the ridiculously long load times of 8 were unacceptable. I was also really looking forward to using the object oriented stuff in 8.2. Well, once I saw what was actually implemented as far as OO in 8.2 I was underwhelmed.

Will I actually go back to 7.1? Probably not, since the number of fixes and improvements in 8.2 outweigh, in my opinion, the cons. Still, it's clear that NI is going to have to issue an update that doesn't require one to be on the SSP to get it. As far as my specific request related to the "VI not executable" business I doubt that will appear in the maintenance release, unless NI is feeling extra nice. Hint, hint...

[Matt_W1]

I found a solution (at least in in my case) so I figure I'd post it here in case anyone else runs into it. If you try to mass compile the project file (well the directory containing the project file), it'll error on the bad vi.

Matt W