Tim_S

I agree with (a), but would argue (b) and ©. Experience does not equate to skilled and even a skilled programmer can get something out of an example. Inexperienced people can learn from the example and should (not will, should) ask questions if they don't understand something.

It's not just daughters. We had a roommate who was going through "WoW-withdrawel". My wife wasn't so far behind (though not with WoW).

Yes, that is correct. I've been thinking on this and I believe it's a feature to avoid including DLLs in Windows system and system32 directories.

The first thing that comes to mind is an array of paths with a boolean "browse" button tied to a file dialog, and to put a Drop event in an event structure. Next thing was a string control instead of a array of paths which lead to needing to check for correct path structure which lead to thinking about XControls...

I figured I should share something that bit me for a while. The problem I was having is I was building an executable, transferring the executable, et. al., to another machine and getting a file dialog showing up when the executable starts. This was not happening on the build machine, only the target machine. I tracked this down to a copy of a DLL I was using was in the PATH environmental variable. The build didn't include the DLL in the support files until I removed the path from the environmental variable. (Note: Changes to the environmental variables don't take effect until you restart LabVIEW).

You're going to have to recompile to add them inside the executable; why not add the new object to a VI as well? You're other option would be to use a plugin structure.

Since you're using objects, why not just open the config file and pass the reference to each object? Each object would be responsible for reading its own section rather than parsing through an array.

The guy who set up ours years ago made the repository/server-side default with that property. I'm sure could figure it out if RTFM.

The only standard for an INI file that I'm aware of is how the file itself is formatted, not the structure of the information inside it. I expect your best method of laying out the data is to mirror how you would put the data into a cluster/data structure.

SVN does (can?) also set the read-only flag; we have SVN set up that way.

I've no clue about SNMP, but I would recommend posting the work you have done for people to look at. Your post indicates a communication VI, but I have no idea where you downloaded it from or what the MIB file is and I expect others are in a similar situation. Also, since this appears to be an assignment, people are leary of doing homework for you (appreciate noting you are a student, though).

64-bit will be faster ONLY IF you can take advantage of the 64-bit instructions, or optimizations in the processor. Otherwise the only advantage 64-bit operating system offers you is more memory (32-bit caps out at 4 GB). Most ATE does not require massive memory, so you'll have to evaluate based on your specific application. Depends on what you're trying to do and what hardware it requires. I've got some systems in the field that still require ISA slots for that one legacy board that no one wants to pay to replace; ISA has been "dead" for a couple decades. Lots of slots is good; I've yet to fill a 14-slot chassis, but come very close a couple of times.

Are you distributing source code or executables?

I recommend you look through the string palette.

Why do you intend to measure a numeric and put it in a string indicator rather than a numeric indicator?

Have you tried customizing the control and going into edit mode?

You're missing the attachment.

Just a note that LV 8.6 doesn't have that option, but 2011 does. Not sure about inbetween.

The code updates some typedefs in dynamically loaded code. This couldn't have happened with the default UAC if the code was in Program Files. I vaguely recall having some issues with opening VIs through VI server, but can't recall them at the moment. This was with LabVIEW 8.6; I'm not certain if 2011 would work differently. Most of our systems go on plant floors. We lock the systems down hard for the autologin user when we can as we've gotten too many calls from customers of poor system performance to find out that the operators have been playing games, doing homework, surfing the internet, etc., on the machines. There is a second "supervisor" user for the plant engineers, IT and us to debug and update the system. The plant IT I've worked with when our system is on their network does something similar (though not usually as aggressive). We had one plant that didn't do any of that; it took a week and a half to get them back up running full production while we cleared out the viruses (they are now a believer in imaging hard drives as well).

I recommend checking out the examples to see what can be done and to look at Vision Assistant. You're going to need to get a feel for what each routine does. Try out the routines and get some working code going. People here are very helpful when those asking for help have put in effort.

hooovahh has the right of it. I updated code to work with Win7 last year; the main gotchas were accessing the registry and directories because of the UAC. I found that the program has to request higher level access to get to the registry, so I chose to eliminate accessing the registry all together. The installer put the application with its configuration files in the Program Files directory; Win7 wouldn't allow modification of those files (possibly also requiring requesting higher level access?) so I had the application go into "C:\<app name>\" instead and the commonly modified configuration files go into to the all-users application data folder (per Microsoft website). I could have turned off the UAC entirely and not made any changes, but the software will get installed on a variety of network setups depending on the specific plant's IT so it was better to follow MS's guidelines.

Obsolescence is always going to happen. Microsoft support legacy code for a very long time (there are still DOS programs that work in Windows), so I don't see why you'd be concerned about such. Changes that could impact you (such as the UAC) are outside of what you can control or plan for.

You can, when creating a listener, give the port number a string name. The TCP connect primitive can accept the string name as the port number. Tim

I stand corrected then. Thanks, good to know it does bitwise operations.

The arithmetic parser doesn't handle bitwise operations, or at least it didn't when I last looked. May have to look again...