That's weird... the vi doesn't LOOK broken!?!?

[billings11]

Sorry NI, but after the 12,000th time getting this message I'm starting to think its too funny not to post.  Why did I upgrade to 8.2 again?

[gmart]

The error message is generic since typically, the reason why this error occurs is that a VI is broken outside of the build process. There are conditions where while processing VIs during building, a VI could end up broken.  The most common cause is a problem when removing typedefs and poly VIs. So the first step is to try rebuilding without removing typedefs or polys. There are other conditions that could cause problems (saving VIs during the build process that has disable structures comes to mind). Obviously, the error message could use improvement.

[billings11]

Today I added a custom Icon I made with the icon editor to a project.  If you close the build editor before it has a chance to load the icon image the whole project explorer hangs indefinitely.

[gmart]

Would you expand on the exact steps you performed to get the hang? I ask because it might be this issue -

42UGCF3E

Fixed an issue where LabVIEW might hang when you double-click a custom icon file from the Select Project File dialog box of the Icon page of the Application Properties dialog box.

http://digital.ni.com/public.nsf/allkb/CAB9E23506CA6A18862572B8001066C6

Message Edited by gmart on 09-14-2007 02:36 PM

[billings11]

This application uses LVOOP.  I'm not removing unused typedef's, etc.  I found that NI bug long ago and worked my way around it.  But still, the broken vi message happens every time you change any vi in this application.  The only way to make it EVER build is to mass compile before building. 

What's funny is when I asked a labview development engineer from NI in the LVOOP group about building exe's with LVOOP, his response was somethinng along the lines of "we just assumed it would build fine."  All it takes is a 5 minute LVOOP application to figure out it ain't the same as a normal build.

[billings11]

Yes I believe that's the bug about the icon file hanging.  I may have been double-clicking it.

Message Edited by billings11 on 09-14-2007 02:38 PM

[gmart]

What might be helpful is if you can duplicate the problem is a simple case and report that as a bug. With the example code, an Applications Engineer can try to reproduce it in both 8.2 and in 8.5. Hopefully the good news will be that the problem is not present in 8.5. I know that won't help your current situation, but at least we can determine if the problem was addressed.

[billings11]

Thanks for the responses.  I'm sure the big is fixed in 8.5 since it was in the bug fixes section of the upgrade notes. 

Sometimes I feel like all I do is post criticisms of labview 8.2.  It has been difficult to continue to be an advocate of this thing when the quality has been so poor in the last few releases.  The sky is the limit on this thing in theory, but in reality the quality control is actually a real limit that affects every developer outside in an industry application.  Quality control is the biggest problem right now with labview, and I'd just like to see NI make it more of a priority.

Right now you guys take whatever you've been working on and throw it on a CD on release day, and call it a release.  Its obvious some of these 'new features' like LVOOP had very little debug before release.  You guys never even had time to build an executable with it before you had to release it.  And basically that shifts all tjose bugs you could have found and corrected yourself onto people like me - the same people who push and advocate labview in industry.  Now my work is riddled with bug workarounds and it drives me nuts!

I'll try to stop posting about bugs, but sometimes when I've had 3 or 4 affect me in day or I try to build 3 or 4 times and some bug keeps it from working, I can't help myself.  I just want to go back to enjoying working with labview again!

[tst]

I can understand that having your code "riddled with bug workarounds" drives you nuts, and that's legitimate, but I think you're being very unfair to NI. I don't know much about NI's testing and building process, but it's definitely not "take whatever you've been working on and throw it on a CD on release day, and call it a release". At the very least, other than the design and testing NI does, it also has a public beta version several months before release. Features which are not ready don't go out the door. LVOOP, for instance, was in the 8.0 beta and was moved to 8.2 because it wasn't ready.

When it came it, it obviously had some additional bugs, but I understand that the major ones were resolved. I agree that having classes work in executables is important, but if it didn't work I wouldn't say that there was no debugging done by NI.

In any case, this should have nothing to do with bug reporting. Reporting bugs is a good thing and you should definitely report any bug you find, because we need NI to fix those bugs.

[billings11]

But that's just my point.  LVOOP wasn't ready for 8.2 either, but they took what they had, threw it on a CD, and called it a release.  Their release dates are set by their sales department, and they are releasing the pre-specified feature set on that date regardless of whether it has been tested or not.  They never even had time to try to build an exe before they released... they were in the dark completely about it until we told them.

The project manager has been around since 8.0 right, but in 8.2 if you double-click a custom icon file labview hangs completely.  I'm sorry but that is a bug that should have been caught in beta and somehow made it through two betas and two releases before finally getting fixed in 8.2.1.

8.0 should never have existed, and neither should 8.2.  They should have waited and released 8.2.1 as 8.0.  It was never ready until 8.2.1.

Message Edited by billings11 on 09-19-2007 11:17 AM