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

[shoneill]

Tst wrote: " although I know I would follow LAVA for that since that's where most serious users of LVOOP post "

That's quite untrue.

I will concede that most people who post on LAVA are serious users, but that's not what you wrote.

Michael Aivaliotis wrote " I'm curious, in YOUR development, build and release process, do you do automated Unit testing? ".
I don't do automated Unit testing either, but I'm still qualified to comment on NI failings where they're apparent.

Just like I may never have scored a goal in the world cup final, but I can still comment on Zizou's headbutt (not- soccer fans may need to look here for clarification).

Let's not let this dispute get personal.

Shane.

[tst]

---

@shoneill wrote:
Tst wrote: " although I know I would follow LAVA for that since that's where most serious users of LVOOP post "

That's quite untrue.

I will concede that most people who post on LAVA are serious users, but that's not what you wrote.

---

How many LVOOP discussions have you seen here?

Over the past year, LAVA had a lot of serious discussions about how LVOOP works and should work. I don't make distinctions between who posts here and on LAVA and when, since I know the level of the people in both forums and I know there are serious users here.

My phrasing didn't convey this well, but my meaning was that the discussions on LVOOP were on LAVA and that's where you would (at least currently) get the most for your time.

[billings11]

To all posters on this thread:

I would just like to revise any previous statements I have made to more concretely make the statement:

LVOOP WAS NOT READY MY ANY STRETCH OF THE IMAGINATION FOR THE 8.2 RELEASE.

I have now spent another 16 hours this week trying to get the same application that started this thread to build into an exe.

If a new feature cannot be built into an exe, it is NOT ready for release.

This time, no amount of mass compiling, saving subvi's, copying diagrams and pasting them onto blank vi's, then saving the resulting vis as the old filenames to remove invisible errors, is working.  I had to add a new test to this test sequencer app using LVOOP.  By adding a new class for that test somehow everything invisibly broke when I try to build into an exe.  I've already been through this process a half-dozen times and somehow gotten the thing to build, but this time none of my usual tricks are working.  I've built all the little chunks of my app into exe's now, but anything ith LVOOP errors, except I can't figure out which LVOOP class is broken because one of them are broken in development mode.  And I can't build individual LVOOP vi's into an exe because the builder won't let you.  My app is dead in the water with invisible bugs.  And all I get for an error message is that the top level app is broken, like it shows in the original post of this thread.

That's the equivalent of a C compiler saying:

"Syntax error in one of the lines of you 201,209 lines of code.  Please find the error and fix it.  Have a nice day."

So to repeat, NO NOT ATTEMPT TO USE LVOOP IN ANY CAPACITY IN LABVIEW 8.2.

What a tremendous waste of time this has been, all because NI chronically refuses to do adequate testing before releasing new features.  I am so tired of hearing lame excuses from NI fans.  Its pathetic.  "You have to expect a few bugs with new features..."  BULL!  This is not "A few bugs".  ALL new features start out below the beta release level, if that.  These are application killing, unusable problems.

[billings11]

Ok... I'll let you guys in on the kinds of things I am trying to do to get this to work.  Here's my next attempt:  If ABAPI Open vi and Check for Broken.vi is causing the problem maybe I'll had-wire it that all vi's are good.  Let's see.

Let's see what happens now...  It made it past the usual place and seems to be building with debug enabled.

[billings11]

Well that didn't work.

I was hoping it would build, and then I could use the debugger to find where the heck the broken vi is.  But unfortunately wwhen I try to connect labview.exe has errors and has to close.

[billings11]

Now I'm trying this to somehow get more information, but I'm not even sure the context of this vi, or really even what vi references are coming through here when the error happens.

[billings11]

Well I don't get it, but now somehow the buld worked with debug enabled and no broken arrow.  But I didn't even do anything to fix it!  Alll I did was modify the vi above!  Now I'll try without debug enabled.

I think I know what happened.  I changed the open reference option to 10, so the vi would put up a search window to find missing vi's.  When I built the exe, I saw the search window pop up for a second.  So I think somehow there is a vi relative path that's wrong and isn't getting fixed when I mass compile.  Bu changing that open reference option to 10 it is searching for the vi instead of breaking the caller.  There is so much strangeness in the LVOOP calling conventions that I'm sure that is the cause for a bunch of the errors.

I bet that modification will fix a lot of bugs in the App Builder.  I wonder if there are any side effects.  It seems to be working without debug enabled now.  Well... three days of effort thumbing through labview source code for one build of an existing app.

Message Edited by billings11 on 10-17-2007 04:41 PM