asbo

The alternative to the 8.x layout is to just put in more debugging code where the call is failing, figure out what it's expecting, what it's using, and then fix it.

1) Check your filesystem for issues with Scandisk. 2) Do a repair (or uninstall/reinstall) of the Report Generation Toolkit.

It's buried in the help file, but you prefix your string with (?s) - the regex implementation in LV is pretty dirty. The correct format for a regular expression is [delimiter][expression[delimiter][options], e.g: /(foo(?:.(?!foo))+)/sgi, which is my solution for your problem (but LV doesn't like lookaround). I'm spoiled by all the time I spent working with proper PCRE. Well, you're parsing with regex - it's not the same thing as writing a parser. A true parser is written with the specific grammar of your subject in mind; not necessarily foo, followed by some stuff, and maybe another foo like the regex is doing. The "some stuff" part is something that regex is particularly bad for - unlimited quantifiers paired with dot or equivalent tend to be a sign that regex is the wrong tool. Regex is awesome when your subject is precise, but as you can see in your case, the variable-length payload is difficult to deal with elegantly. I bring this up especially because you mentioned that your header itself is variable, which is only going to further complicate things. You might be be successful with a regex, but it will be brittle and potentially very tedious to build. Technically, yes, you can write a true parser using regex (and that's probably okay) but there's a very clear line (to me) when you're trying to do too much with one regular expression. Darin's suggestion works correctly in LabVIEW (I don't think that it should), so you might be able to get away with finding an expression which works for the header and substituting it for your foo's.

It's beginning to look like writing your own parser is the smarter choice. It's pretty often that regex gets misused in that kind of circumstance (if I had a dollar for every time someone tried to parse HTML with regex...). Give it some thought and see if you'd come out ahead with a proper parser. By the way, why did you choose [\s\S]? "Match any whitespace or any not-whitespace."

Good lord, think of the energy savings...

Also in LV2011 (DAQmx 9.3.5), I tried this on a simulated device (PCI-6230, though I doubt it matters). It repro'd, but I couldn't stop the VI. When I tried to close it, it asked me to save; I declined and it got stuck at the "Resetting VI" window.

Not to mention lookup on variant attributes is extremely fast thanks to some optimizations in the late 8.x (?) era.

Have you turned UAC off through the User Accounts control panel applet?

I hadn't even noticed the VI name, but you're absolutely right. Thanks for making the pointer-sized integer problem clear.

Did you get NI's take on this?

I found a couple posts on NI's forums that linked to a SendKey.llb attachment, but none of them worked (404'd). I reported the posts to the moderator. To find a window, you can use the FindWindow() Windows API call. To set focus to a window, you can use the SetForegroundWindow() API call. Neither are very difficult to implement in a CLN. If the VI you're looking to target is a VI front panel that you can open a reference to, you can use the NativeWindow property:

Have you tried this? Simulating Keyboard Input to Generate an Event Programmatically

Like ShaunR hints at, the AE is basically a singleton, so it's entirely possible to do this without LVOOP. The only nicety that LVOOP adds (that I can think of) is dynamic dispatch, but I don't think that's integral to what you're doing. The coercion dot can indicate a loss of data (think of DBL cast to I32, for example). The best and easiest way to check in your case is to coerce the type, then pull it back off the array and compare it against the uncoerced value.

What license are these released under? The NI page doesn't mention.

How does the VIRegister performance compare to the performance of a LV2 global? Is there any benefit using VIRegisters, except that you wouldn't need to create your own VIG VIs?

I'd use the singleton to mediate the subscription (in FindQueue()) and have it move the queue ref to a different array (or mark it in use, depending on how complex you want your data structure). Require that the subscriber call a ReleaseQueue() method through the singleton when it's done with the queue ref.

Aye, typically I wouldn't disable it altogether. It might be conditionally disabled during a specific action or present a prompt tied to a proper shutdown procedure instead.

Isn't there a File > Remove from Library command? Is this programmatically accessible?

Having not used LapDog (and not much intention in the near future), I'd still agree that VariantArrayMsg seems unnecessary. There are few use cases where you're "doing it right" if you have to do that, I think, and is a corner case that, like you said, can be covered by the VariantMsg.

I'm very interested in your process, I read through your post and kind of have an itch to set my own up. How often do you find yourself rebuilding projects? How rigorous is your development cycle? Do you have software products, per se, or is each project as custom-built solution for a particular customer? The majority of our work is the latter, and with one specific target platform, so I'm struggling to find it as useful in our use-case. We do version our binary releases, but everything is done manually so I can appreciate (and am very much enticed by) the value of having all that done for me.

That sounds awesome.

I added some formatting and expanded it a bit. I was going to come up with an example of using completely different functions in each sub-expression, but got lazy.

. Graph_Problem - Fixed.LV82.vi

I agree. To me, calling a DLL through a CLN/ActiveX Automation/.NET should be treated the same as trying to read C:\foobar.txt - it's *not* LabVIEW's job to make sure it's there. I like the change in behavior LabVIEW's made wrt when you only use the DLL name. I use that paradigm to ensure that whereever my software is run is actually configured correctly. If LabVIEW goes and includes DLL in my build, not only is the principle violated, but it could break the DLL's functionality as well.

You're not making it very easy for someone to help you unless they've done this exact thing before. You should post a complete VI plus an XLS to test against.