ShaunR

Doesn't get much simpler than an animated gif that is visible or not

Too quick...lol http://www.screencast.com/users/Phallanx/folders/Jing/media/6d76d3b1-a19d-4657-8db9-35caa09e1fa4

Import picture to clip-board. then paste.

I quite like making the vi a little bit transparent (say 5-10%) it really brings the focus to the dialogue and is dead easy. But I'm +1 on disable and greying out controls.

Project>>New>>Create New>>Class . Its quicker

Stuck? How so?

You wire a bullet to a gun and then to your foot, but when you press the trigger, the bullet shoots the gun and embeds the gun in your foot.

I've come across various variations of this over time How To Shoot Yourself In The Foot In Any Programming Language What about Labview? We need an entry in this prestigious list. Suggestions? This is my favourite C++ You accidentally create a dozen clones of yourself and shoot them all in the foot. Emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."

Not even a rep-point or effort?

Smart advertising

Well. I cannot use the server because it uses the old USB vi's But I think this is what you are after.

Post my VIs you've modified that are showing the errors and I'll see whats up.

And replace 1 small insignificant bug with 20 whopping huge ones

Nope you are right (only 1/2 a rep point then ) When I launched your example (dbl clicked) it switched to 2010 instead of my usual 2009. Making sure 2009 was open when I dbl clicked made sure I was using 2009, and it worked ok without moding.

Your example of the 2009 also fails on my 2009 SP1 (error 91). But if I remove the strict type it works again. I can switch backwards and forwards between it working and not working, so I'm not sure what you mean by "adding back the strict typedef setting has no effect" Hmmm. 2 cars? I didn't even get a rep-point

If you uncheck "Include Data Type" on the VI server reference classes ( Run, abort. Text display tree etc). It works. And if you save it to 2009 and add the "include Data Type" it fails. A default setting has changed maybe?.

I remember that article too. I also remember creating a distribution with just the lvrte.exe and the advanalys.dll (the latter was required for a lot of the trig/maths functions). And, if I remember correctly, if you were using other features you had to include those (like the VISA, DAQ and IMAQ dlls).

I think its been slowly getting worse every iteration. There used to be a time when you might see "insane object at..." maybe 2 or 3 times a year, but you had to be abusing it. I often get 2009 disappearing when I delete something. But its better than 8.x (IMHO) which was a complete crock...But I think NI realise this which is why they have said 2011 will be a "stability" release. My personal opinion that any software shouldn't be released UNTIL it is stable. Don't bet that 2010 will be better. See how many bugs are still existing from 8.x. (2010 Known Issues)

I think most people use some sort of Queue based error handling where each loop/subvi/process/task places a message on the queue which is handled by a dedicated error task.

Not sure if this is what Yair was talking about (didn't really understand) but.....You can also load a sub-panel within a sub-panel and instead of overlapping, nest them vertically. This might achieve the same effect,, but you would handle the event in the top level vi by inspecting the ctrl reference.

Why are you using polymorphic VIs? They are data bound. Shouldn't you be using dynamic dispatch or some other dark magic to choose the instance at run-time?

Seems this is a known problem that was fixed in later updates (allegedly). Load Error code 3

Generate a user event and handle that in the sub.vi? Haven't tried it, but it'd probably be one of the first things I'd try.

I thought a bit about this. Below is an example of a simple "possible" DAQ config file. One thing you can do to poke-yoke the file is have a "default" button which reloads (but does not save) the original config you decide on. That way they can always get back to a known "good" config and have "commit" and "Save" buttons, One which is temporary and will not be retained between launches of the software but allows them to "play", the other saves over the previous file. You can also do other stuff like having excel macros or create an interface for entry checking etc, but its not really necessary. Its really up to you. Its very flexible and scalable.

I'm not sure about that. From the last time I used MAX. It was a case that in the project you create a MAX database file which is deployed with the installation (under the build specifications >>New installer>>Hardware Configuration). If that is the way you are thinking, then your "default" will only be applied every time you install as well as deleting any changes or additional tasks. Additionally. Once it is in MAX, I'm unaware of a method to "lock" a task so that it cannot be edited (jump in here JG) . However, if you create that task dynamically (delete if exists, then add it again) every time you run your software, you will have a task that can be reset to default just by re-running your program (or by pressing a button). And if you do that you have the major component of the file system/database implementation This bit, I think, will cause them to moan quite a lot as well as being extremely error prone. If you had a way to "copy" the default then I don't think it would be so bad, but I'm unaware of a way to do that in MAX. Well. You could update the scales directly from the spec sheet (or an automated derivative) to make yours and their lives easier. No abort button ? What I meant was actually covered in your previous description, where they have to create a new task. Indeed. Your application is relying on the most error prone part of the process (configuring MAX). This is what worries me. But I'm not sure what module you would want to write to configure DAQmx, since the whole purpose behind using MAX is so that you don't have to is it not?