asbo

Haha, I've resisted the urge to install LV at home so far. Some might say that's a bad thing, but I still need that mental division

At least you'll be remembered

On what version of LabVIEW? "(now compatible again with LabVIEW 6.0)" is unsettling.

I wish I had an excuse to play around with this, it looks sweet.

I'm not picking up what you're putting down about this helper sequence structure. Care to demonstrate?

This is going over the white-noise generators very, very soon ...

For reference: VI will be purged. Didn't know about this one, I don't often muck with private stuff.

Not everyone is privileged with powerful hardware! I meant no affront to your code

This kind of involves a level of involvement I think you're looking to avoid, but you could try using a generic wrapper VI to call the actual subVI and signal the top-level VI in whatever manner you like. To use an event structure, I suppose you would have to pass something into the wrapper VI so that the top-level is aware of it as well.

Very cool! Is the capture choppy or is the rendering choppy? The jumping around of the block diagram at the end inclines me toward the former.

You are indeed, the in-place structure was added in LabVIEW 8.5.

A least a month or two, I remember seeing an e-mail go by, I think. I'd love to see how this works its magic as well. Perhaps I'll take it for a spin tonight and see how well it crosses over.

Don't bother ... it's a lie. Congrats on the big five-oh-oh!

You might look into the LabVIEW Database Connectivity Toolkit, though you may not have a license for it. You can use the evaluation version to see if it fits your use case. Additionally, there has been some code written specifically for MySQL that works well, albeit much slower than the toolkit.

Since I'm a hair color-blind, sometimes I can't easily discern the different between the black and the red anyway (especially on the property nodes), so I eagerly await the day we can have animated icons

BSOD's usually make me think of driver issues. If it save a memory dump/mini dump, you could grab WinDbg and try and figure out what component(s) specifically caused the crash.

I haven't used the scheme you came up with before, but I really like it. The only downside I can see is that without the context help open, you lose visibility. Even then, you'd have to mouse over each VI to check the terminal requirements. If you're just eye-balling a block diagram, especially a big one, that can be a bit unwieldy. In the past, I've followed NI's example of Invoke/Property Nodes and added a little red "?!" to the icon if my subVI is going to ignore error. There's no option to ignore incoming error, but obviously you can do whatever you want with your own subVI.

We use OrbitMicro pretty regularly. Like crossrulz said, though, 6x PCI will be a rare beast no matter where you go. Unless it's back in time ...

You could also lock the INI file while the program is running. When the second instance runs, it checks if the first INI is locked and if it is falls back to the second INI file.

As you can see, I do have two new unread threads, but I also have three pages of threads show up, all of them read already. However, when I have no unread threads, I don't get a list of any threads (which is what I'd expect). It honestly doesn't bother me at all, just thought I'd throw it out there.

It's very subtle in FF 3.6, I didn't notice it either. If IE has any filtering stuff built-in you could just block that image.

You didn't attach your VI

Horizontal Scroll Hotkey Enable 'Retain Wire Values' for entire VI hierarchy