I have a rather large application (700+ vi's 2 xcontrols 3 statecharts
47 lvoop classes) and I'm getting tired of trying to workout problems
with the application builder.
Sometimes the problems are obscure (adding a filedialog express vi in a
statechart wouldn't compile until I opened the front panel and saved it
as a non-express vi. If I remember right I couldn't create a small
example demonstrating the bug). Some are my fault (a recursive lvoop
function that calls a Shared Clone Reentrant subvi that in turn could
potentially (though never did) call the function that called it
(basically recursion without a lvoop object stringing it together),
this would function fine in development but would make the application
builder very unhappy (I wish it would have told me what vi it was
having a problem with though). And my current problem of if I add a
node for an empty class (that only inherits from one of my other
classes), it can't build and LabVIEW throws a fit all over the rest of
windows (I'll explain what I mean below). The part that makes it
frustrating is that the compiler fails without a decent indication of
why. Then I get to try to straighten it out by removing/tweaking the
changes I made since the last working version in source control, and
attempting a 20 minute recompile (and repeating until it starts working
again which makes a 30 minute change into a two day change).
So basically I'm wondering if there's a better way of dealing with
compiler problems (like a decent log file somewhere), or beta version
of LabVIEW with a newer application builder that I could try using
(8.5 fixed one of the bugs I was having in 8.2 with classes with the
same name living in different lvlibs). Hopefully a version one that can
use lvoop objects without making a bunch of folders (more annoyance
than serious problem). I could probably send a version of my program to
NI to play with, but it depends on some third party dlls (aerotech
a3200 software), that apparently need to be properly installed for
LabVIEW to access it (just copying the dll's doesn't seem to be enough
for moving to test building on a different system). Or if anyone has
some other suggestions. Currently on my list of pain in the neck things
to try are remake the project, reinstall labview, reinstall windows,
move into the mountains and live as a hermit.
As for what I mean by the application builder throwing a fit, it seems
that the application builder can interact with explorer.exe in several
a nasty ways (it doesn't always dispay all of these). Some windows
don't get redrawn right (part a window on one monitor gets drawn on
another), the icons on the desktop get repeatable redrawn, some
applications stop responding, and ctrl-alt-del just causes beep from
the computer as it mocks my attempts to kill the labview process (at
this point I can forcible power down the system, or wait several
minutes for the application builder to finish it death throws, where
it's last breath cries about an error in drawmgr.cpp line 3570). I've
run into the problem a few times before (the last time I had to turn
off Disconnect type defs in the Additional Exclusions to get it
working), but it got old the first time I had to work around it.
Also about 95% of the time LabVIEW crashes when I try to close my
project (this is just annoying since I now just use save all before
closing). And I found a bug where if I run my programs executable and
in the development environment at the same time it blue screens the
computer with a error in nisrx.dll, from another post I read I believe
this is due to both programs trying to allocate the digital inputs on
my daq board, and instead of the second returning an error it just blue
screens (I would try to make an example problem vi, but I'm busy trying
to get my program to build).
LV 8.5 Professional, DAQmx 8.6, Vision 8.5, Statechart module.
