brent99

My core problem seems to be the labview analysis dll for 8.0 won't load on target machines, and Labview updated all my references to this library when it updated Vis to 8.0. I painstakingly went through and was able to re-reference the library calls to 7.1 and then all is relatively happy. Why doesn't the 8.0 analysis dll load on target machines? I don't have the faintest clue. Oh well. Got bigger fish to fry. At least I'm upgraded,

I'm trying to build a 7.1 application in 8.0. It builds and runs fine on my host computer, but as soon as I move it to a fresh install it complains and whines about not being able to load front panels of NI_AALPro.lvlib vis and other analysis stuff in the shared directory of vi.lib. To date, I don't know how to resolve this issue. I've forceably included some of these vis in the build and then it just spits out 2200 and 2220 errors, whatever the heck that means. :headbang: I even installed the development demo version to make the available libraries closer to the host system that works and it still doesn't solve the porting issue. It also whined about cw3dgraph being an old version which I eventually resolved by reinstalling MAX or ComponentWorks or something like that. Also, somewhat offtopic, I notice that 8.0 takes a LONG time to load relative to 7.1. Hmmm....my pain has so far outweighed my gain considerably. Oh, I should add, I started compiling my 7.1 app in 8.0 because, after installing 8.0, all copies of my 7.1 build file mysteriously refuse to load correctly now (blows up). Since I didn't feel like trying to recreate my 7.1 build files that have a lot of support files and stuff from scratch, I thought the easier path would be just to convert the build file into 8.0 and build the executable in there...which worked fine, other than the fact the target only runs on the host computer as mentioned above. BUT WAIT...now I realize that I'm not dragging over the new support files!! Problem solved??? Well, no. So I bring over lvanyls.dll which the program kindly dropped into my support directory (don't think I needed a local copy in 7.1) and it runs fine on the host, but the server is now saying its an invalid dll. What??? Even reseting all the support files from the new build on the target, I get the same errors as before plus it insists lvanyls.dll is not a valid labview file, which may be causing some of these errors. Upgrade hell.... :headbang:

Just because a file completes download doesn't mean all the bytes in it are correctly downloaded. Its surprising how often this is true. To be safe, download a checking utility called "md5sum.exe" here: http://www.etree.org/md5com.html#download Run "md5sum.exe labview_80.exe" and the program should spit out this checksum: 42950520eb90d3908c74e97461480988 Of course, this is my result. If they change the file on the server, the checksum would change. Perhaps someone here can give me a "Hey I got that too!" It only takes a couple minutes to do this and is far easier than dealing with the ill-effects of a slightly warped download.

Anyone trying to download a file this big using basic Windows IE download feature is likely to be extremely disappointed. Most browsers can't not, by default, handle a file download this large. I recommend getting a file download tool. I like to use something called "Star Downloader", personally, which has a free version.

Ah, "origin"! Good one, and in Labview 7.1 they even put origin gridlines up for you. Thanks for the tip, should make life a bit saner.

I often go through the pain of having to "recenter" my objects on the front panel from having the window scroll "out of bounds" from an interaction with a background control or other random reasons. Is this just part of the burden of labview or am I missing a good trick here? It seems needlessly painful to have to recenter your controls. Other design tools, like VB, don't have that "endless landscape" issue. Does labview need some "revert" function to recenter your front panel automatically? :headbang:

Labview keeps data in big endian format in tribute to its Apple roots. If you write out data to other programs circumventing Labview's reverse functions, you'll see everything is wackbards. I know, I know...not funny if you have to explain it!

...when you start tieing both of your shoelaces at the same time. ...when you know exactly what x-y*floor(x/y) is. ...when you no longer wire the > and < signs backwards. ...when you think Jesus was born at noon on Friday, January 1, 1904. ...when you need to get a property, you aren't talking about Florida. ...when all of your description and tips are set. ...when you believe the answer is 28, not 42, because after that you are out of connectors. ....when you've begun to view your life as one big state machine. ...when your search engine defaults to ni.com rather than google. ...when you write by hand, words come out backwards.

I think this was a bizarre conversion problem from Labview 6 that corrupted this text control. I've done simple examples where I didn't witness this problem. Very odd though...

I kick off an independent loop using a generated user-event that wakes up a single-event event structure. It occurs to me that I probably could have used a notifier to do the same thing. Are these essential the same mechanisms? The only advantage I can think of to the event structure is it could more easily expand to accomodate other events if my situation required it.

In Labview 7.1 (sorry haven't tried others yet), my text control is set to NOT limit to single line and this works fine in debug mode, but when I compile an EXE it behaves as if this property were set to true. I've even tried forcing the property to be False continuously as well as forced focus back on the box. Is this a known bug?