asbo

Check out the Panel Close? and Application Instance Close? events. The question mark in the event name indicates it's a filter event, where you wire out a boolean which indicates whether to honor the action or not.

I was just going to let him give me credit for it...

http://www.eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf

Elegantly put. I redact my comments. This sounds like a weak case to use scripting to dig through property nodes. Personally, sticking a "TODO:", "DEBUG:", or "FIXME:" just as easily facilitates finding these comments without requiring that the free label be of any specific format. I recognize that it is a standard, but argue that it's simply one that does not apply. Keep an eye on your svn logs, I'm going to start changing all of your comments.

Ah, this is actually one I don't like. The syntactic significance of /* ... */ is moot in LabVIEW - what else could a free label be used for on the block diagram but to comment? I particularly dislike the color contrast chosen for the OpenG comment. I see no value-add except having more colors on your BD. I whole-heartedly embraced the square-bracket array notation (but rarely find cases where I think its necessary) and think that the typecast terminals are only misleading in that they use the & and * operators in a language that's almost exclusively by-value. I remember the first time I read that terminal, I got a little warm and fuzzy feeling for knowing exactly what it meant, though. Ah, C, I miss you sometimes...

That's because TestStand expressions are modeled after text-based languages like C.

Thanks for uploading the code! I'm glad you found something that worked, I'll store that away in case I need it someday. One workaround to the issue you mention is to do what was recommended in the thread I linked - store your actual working directory yourself and then use the API call before/after dialog calls to make everything place nice.

OT: Does the Code Capture Tool let you grab control/indicators from the front panel too, or did you edit that in?

Trivia: this is referred to as a ternary operation.

Change the calling convention to stdcall (WINAPI).

LabVIEW is known to be a little greedy when it comes to file locks. For example: Cannot move or delete folder while LabVIEW is open. I use the utility Unlocker for deal with locking issues in general. As usual, the wise rolfk presents a Windows API-based solution using SetCurrentDirectory(), if you're up for it.

I'm just shooting in the dark here, but what about replacing your LV2 globals with a private DVR? You could drop in a re-entrant VI to replace the LV2 global calls, and then just wire in the DVR reference - if I'm thinking of this right, it wouldn't be much of an overhaul and the block diagram footprint would be only marginally bigger. This is without looking at your code or even playing with the idea myself, so feel free to yell at me if it's dumb.

It silently crashes for me, LV2011/Win7 x64, but I didn't check to see where. My suggestion would be to figure out which CLN is causing the exception and rebuild it referencing MSDN to be sure everything's correct. Not sure why it'd be okay in past versions of LabVIEW, but if a rewrite doesn't work, submit it to NI - maybe something in CLNs got broken.

Then you should post the code you've already tried and what your specific problem is, as well as the example HWS. Otherwise, you're only going to get useful advice if someone else has encountered your exact problem, which is unlikely.

http://digital.ni.com/public.nsf/allkb/5BBC0C25E2E3E8CE862575BB00662D7E

The forum is here to help, but you're not trying awful hard on your own: http://lmgtfy.com/?q=labview+play+video

I was curious about this too. I think it's going to vary from developer to developer because personally I'd want some feedback if the enqueue failed. One of the modules we use internally has two error outputs on its action VIs: one for the outcome of the action of the VI and one for the pass-through and/or generic logic of the VI. Sometimes the terminals get merged, sometimes they are handled separately, sometimes the action error just gets discarded, but it's nice to have that flexibility. In short, I definitely agree with "the whole point", but think it's valuable to expose the error output anyway.

The way you've written your timing code does not guarantee accuracy - use a flat sequence structure with three frames instead and don't both with a shift register just make a call to Get Tick Count immediately prior and after the payload code. 70ms * 2 = 140ms, 162ms (from your screenshot) - 140ms = 22ms of lag. Does your device have to multiplex in order to read one meter or the other? If it does, settling time maybe a factor. Does the manufacturer specify response time? What is the baud rate of the device? Additionally, is your 70ms for the individual read a looped benchmark or a one-up? The device may not be able to churn out data quickly. Again, baud rate may be relevant. Two unrelated things: 1) You can replace your "read until buffer is empty" loop with a call to VISA Flush. As you have it written, it would be slightly faster/cleaner to test for a string length of zero. 2) If you change the mechanical action of Init to any kind of latch ("latch when released" is default), you won't need to reset its value with a local.

Do they involve registering, unregistering, and mapping values??

I agree that "Register" doesn't seem like an apt verb for your method. I'm inclined toward "Map" or "Set" because neither of those have the associated cleanup paradigm that "Register" does. Given that your own description of the functionality uses the word "map", that really feels like the right choice. However, if you truly are rooted on "Register", I would vote against a sentinel value being used to unregister - it feels backdoor and kludge-y, IMO. You could just as well as another boolean terminal for "Unregister?" which was optional and defaulted to false. I also had the thought that using "Deregister" might be far enough different from "Register"/"Unregister" that it would make a developer actually read the Context Help for the VI before slapping it down.

This hits on a good point. I thought about it more and in the thread I referenced I don't necessarily agree with needing to know the name of the event at all, so perhaps it's a moot issue because there's not a good use case for it. I agree that if the name is significant, the data should be structured such that the name attribute is discrete (cluster {string name, userevent ref}). I agree with everything you've said, except I guess I disagree with the implication that the data has a name - which, if I'm reading this right, you would agree it does not. The name belongs to some single instantiated item, which is why I suggested either terminal name or wire name, but the data has a source and destination(s) and has potentially many instances. You could argue each of these instances have different names, but I still have issue with saying that the name belongs to the data. I don't think I found the right words there to justify my position, but I think this will boil down to semantics at best and philosophy at worst. 2-2! Tied up!

PEBKAC is one of my favorite error descriptions.

I don't know the technicalities, maybe someone else can chime in. I know that on a couple random occasions, I've had a broken arrow with no error listed and force compiling corrected the problem. LabVIEW must use iterative compiling, so maybe what's caused your constantly-unsaved state is some bit of state information not getting updated or something. Hard to say. I don't have as much hope for it now, though, if re-writing the VI from scratch didn't help. The next step would be to start deleting stuff and see when the problem goes away.

Have you tried a forced recompile? Shift+Ctrl+click the Run arrow. You also retry rewriting the class from scratch - I've read a number of posts where that was a solution, though the reason why it happened was still a mystery. Have you tried opening on someone else's machine?