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.

Expanding upon the idea of a .ini token... depending on how many dialogs this could affect (say, 5 or less), each could have its own .ini token. If more dialogs are affected, they could all share one token and it could be an unsigned integer where the integer holds information on whether a certain dialog should be displayed or not. For example, say the token value is 56. That's 111000 in binary. That could represent windows 1, 2, and 3 should not be displayed (the lower 3 bits) and windows 4, 5, and 6 should be displayed. There could also be an entry into the Tools->Settings dialog where users can select which dialogs are displayed (along with a "Show All" and "Show None" button that selects/deselects all).

While this is a great idea, it isn't within the scope of the topic. I was originally looking for dialogs that need to be reworded.

The .ini token idea though is a great idea! I think it should be submitted to the idea exchange and see how other users feel about it.

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.

Anything that can be undone should not have a dialog, period. Get rid of it altogether. No checkboxes or ini settings.

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

Hi Martin

You can do this and I have done it before. Here is a screenshot of an example:

You just have to use Rings (not Enums - FWIW I don't use Enums as display elements anyways, only as application data) and don't use Strict Type Defs for the Rings, Cluster or Array as then you cannot change the Ring's Strings[ ] property (it throws a Run Time error if I remember correctly).

In the example the UI element is an Array of Clusters where one element is a Ring.

I just use VI Server Refnums to populate the Rings at Run Time (e.g. on changes in the Applications etc...) and they can be different even though they are in an Array.

Cheers

-JG

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.)

Is the event you are registering for on the front panel of the Xcontrol's Facade.vi?

why do you need to register for events in the first place?

~Jon

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?

To quote the teflon president, "I feel your pain."

This is one of those design decisions R&D had to make that doesn't have a clear "correct" solution. Consider what happens if you save an object to disk with default values, update the .ctl with new default values, and load the saved object? Should the loaded object contain the old default values or new default values? The answer is, it depends. NI had to choose something, so they implemented it so the object loads using the new default values.

Not all data types lend themselves to the default=null convention. Numbers are particularly problematic. Suppose you have a Sum class that adds two numbers and maintains the sum internally. When you load a Sum object from disk where sum=0, is that valid or not? Maybe it's the result of adding -3 and +3? If your serialized objects have data that could be "invalid," it's safer as a general practice to include a private "IsValid" flag.

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

Can you tell us more what you want to do with the references?

/J

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.

too late to edit...

turns out that the problem I was having is that BD.open is incredibly slow. If I only check BD.open when FP.open is true, everything's nice and fast.

Hi all,

I just wrote a little window management script for use while developing. I get a reference to all of the VIs belonging to a target application instance that have an open & visible BD or FP. My initial approach was to get a VI.OwnedApp reference and then get App.AllVIs. I autoindex that in a for loop and get VI refs by name for each element. Then I check each VI's properties to filter it.

This worked swimmingly... and then l I opened a big project with >1k loaded VIs, where it takes several seconds to execute.

Is there a property or method anywhere that will give me a more focused list of names or references? Do I have to filter the list myself?

LV2009sp1, Win7

I have narrowed it down to the .NET picture control that I had in the new program. Even though I disabled all the code related to it, I still have the .net control on my front panel, and this caused the slowdown. When I removed the .net control itself, load time was back to normal.

I have seen this too in some cases, and I think it is related to .NET certificate checking. What I think is happening is that since there is a .NET component, the .NET runtime is attempting to check for an application certificate. I haven't tried to isolate it as such, but I suspect the problem occurs on computers that have a network connection but not one that can access whatever cert server .NET wants, so it tries a few times, times out on all attempts, and gives up.

-Does the app load with the delay every time? It might not try on every run, so watch out for false negatives.

-Does network/internet connectivity make a difference?