blawson

Just got this yesterday testing an installer. I installed new versions (over old) of LV and DAQmx runtimes, then installed my app and ran it without restarting. That says "VI has an error of type 302208. The full development version of LabVIEW is required to fix the errors" at least 100 times. The dialog is ~1350x800px on a 1680x1050 screen. Oh and when you click OK, it leaves the main VI FP open, broken, and not running. When I restarted it worked fine. cracked me up

I don't think there were browse dialogs going anywhere near the locked files - text logs created by an internal library. There are likely to be read/write references open to the current log file. I'm guessing that something about the .NET method for attaching files will balk (silently!) at locked files, and for some reason this extends to locked files inside a zip. It was clearly this: I could unzip the archive with LV open and Win7 would show a "file locked by LV" error if I tried to copy the files. when attached to an email, zip files with locked files wouldn't send, zip files without would. I got around the issue by opening a read only reference to the file and copying its contents. Would be nice to understand what's going on, though, as I think I've seen something similar before.

No, that is a terrible idea! The .ini file should be human-readable and generally user-editable. Making the selection into a bitfield makes it hard to read and with no reference to which dialogs it controls makes it impossible to translate. We also do not need more clutter in the tools->options UI. Absolutely. Start with this, it ought to eliminate most of the truly repetitive ones.

I'm using NSIS for a couple of my more complicated installs and so far I'm very happy with it. Mostly what I've used it for so far is to package a LV-built installer with installers for 3rd party applications. Now I have another problem - I've got several LV exes in an app suite for which I want a single installer. I intend to build installers in labview for each exe and then script an NSIS installer to package them together. All of the exes are optional, all require the LV RTE, and several require some additional LV installer (VISA, DAQmx, etc.). If I add the LVRTE to every exe's installer, the file size will be huge. So I'll package the NI installers in NSIS and build LV installers for the exes only. I'm assuming that the best way to get these is to download the standalone installers from NI.com (for the RTE, VISA, etc). Any pitfalls here, or alternatives? I'll note that when you look inside one of these standalone installers, there is a \Products\ directory with a bunch of NI components, each with msi files. Comparing VISA 5.0.3 to 2010RTESP1, there is about 50MB of overlap. I suspect that a LV-built installer with "additional installers" checked skips the redundant products. Is there any way to create a standalone "LV components" installer that is separate from my application's installer? -B

Update: turns out I have (exactly) the same problem if I use the built-in zip tools. Update 2: turns out it's a file-locking problem: labview is keeping locks on files copied into the folder before zipping.

I'm having an odd issue (probably) with openG ZIP tools. I have a program where I zip a folder and email it. I develop on two machines, "A" and "B". Both are running LV2010sp1 on win7x64, and both have the newest versions of VIPM and OpenG as of this week. I use "ZLIB compress directory" to zip a whole folder. Default options, nothing fancy. If I try to attach an archive made from computer "A" or from an executable built on A, the email sends without errors, but never arrives. If I send from A (or B) with any other file, including zip files made with other programs, they send fine. If I send a zip file made on B in development or in a B-built exe run on machine B, it sends fine. What I presume is happening is that something about the zip files created using machine A's ZLIB is subtly malformed enough that the mail server is intercepting the email because it thinks something's wrong. I don't have access to the mail server for more info. I've tried uninstalling and reinstalling openG on machine A with no joy. Can anyone offer suggestions on troubleshooting Machine A's zip setup? -B

What properties of the ring are you changing? In my experience, if you change the ring's strings[] property, it changes existing values to the new values or to <#> if there is no longer a match. I've done this with a combobox (and undefined items disabled). -B

bah! I thought I had it right and then it stopped responding to one of two of the dynamic events, but only in the exe. I declared it a waste of time trying to get undocumented stuff to work and rewrote it without the dynamic events.

Aha! I read that dynamically registered events won't wake up an xcontrol's event structure (they'll enqueue the events but not process them). My solution here was to add a case "this vi:mouse enter" that does nothing, but will wake up the event structure. (I'm thinking this was the problem all along, not a dev vs. exe issue.)

I'm registering for mouse events and a value change event on some controls that are in a cluster which is in an array on the facade FP. The standard events in the event structure don't give you access to array elements or their children, and registering works around this. It can be a convenient way to react to activity in an array. The ctlref data source in the event frame refers to the actual element, Mouse events will fire even on empty array elements, etc. I think I have it working now that I moved the event registration refnum off the USR into the xcontrol's display state cluster, and added register and unregister code to the Init and Uninit abilities. I'm still confused as to what was wrong with using either a USR or First Call here.

I'm trying to register for a Mouse Down? event on an element of an array which is on the FP of an xcontrol. I don't need this event to be dynamic, so I put it in a First Call case before the event structure in the facade. The event reg refnum is in an uninitialized shift register, so I expected this to work. I'm not using the Init and Uninit abilities for this, but side from not unregistering the event, this seems like a simple way to do it. It works in development, but in a built exe the registered-for events aren't firing. anyone know why this wouldnt work in an exe?

Or in other words, a data type doesn't have an acceptable null if all possible values are acceptable. Booleans would be the easiest example. I just want to find the middle ground where I can store the state of an object in a human friendly form without writing it out custom for every single class, and without it mysteriously changing if values are sometimes default and sometimes not.

I've been tangling a little with some classes designed for data serialization and also with just trying to serialize some classes. One of the things I'm not wild about is the way that default values in a natively serialized object (using the binary or native XML tools) are omitted from the data. I feel like this breaks one of the goals of serializing the data, which is to separate the serialized data from the implementation of the object. I'm considering making it a convention to try to use default values in class private data that are null or otherwise illegal (in context). For new objects, this would require writing a constructor that sets the intended defaults. For deserialized objects, this would require writing a method to validate an object against a class invariant. I'll claim this is a good habit. Does anyone do it like this? Any drawbacks I'm missing? Any comments or ideas are appreciated. Thanks, -B

Hey folks, I was just curious if anyone can recommend a decent terminal program for serial debugging, since win7 doesn't ship with hyperterminal. Is there something useful in Win7, or in any of the NI software? What do you use? -Barrett

For now I'm just tweaking window position and size for when I hop around between machines with different display sizes. Ultimately i'd like to save/restore the state of the open windows of a project. The former works pretty well one window at a time, but in order to do the latter, I really need the whole list. Once I benchmarked the individual properties, it was clear that the BD window props are slow, roughly in proportion to the size in memory of the diagram.