asbo

Try cmd /c ""C:\Program Files\OpenOffice.org 3\program\scalc.exe" "macro:///IES13148.Module1.PrintDocument(C:\Documents and Settings\test13.csv)"". My initial test was cmd /c ""c:\foo bar\hello.bat" bar baz" where hello.bat is simply @echo %1 and bar and baz are separate parameters. You can stick them together by putting them in quotes ("bar baz") but then the quotes are included in the output. You can nest quotes within those quotes without consequence ("foo "bar" baz") and the output is literal, even with a pair of double-quotes. You can actually drop the trailing quote for any of these parameters and it'll drop it in the output, but that's kind of taking advantage of the parser and you can't guarantee a particular outcome anymore. The ^ character is the escape character, but I couldn't get it to make any difference. This is all assuming your space in the path is going to mess things up, and that you'll need to encapsulate it in quotes, of course. There's an off-chance that OpenOffice would accept single quotes instead of double quotes to preserve the macro's parameter. Cop-out: is there any reason you can't use 8.3 filenames here?

What about cmd /c "C:\Program Files\OpenOffice.org 3\program\scalc.exe" macro:///IES13148.Module1.PrintDocument("C:\Documents and Settings\test13.csv")?

I thought I'd throw out there that the key bit here is the breakpoint - otherwise, all you've done is dropped a probe on a VI which is instantiated multiple times in parallel, and LabVIEW doesn't have a way of knowing which instance you want to look at. By placing the breakpoint, a specific instance can be brought to attention, at which point the probe you dropped is tied to that instance.

You've forgotten - that moment of disillusioned victory.

Don't overlook the possibility that it being implemented is what we see as the bug.

It'll be a sad joke, but a wonderful dream ...

Actually, we're talking about that very package over here, which offers a little bit more insight on it.

Thanks for the benchmark. Do you have any direction on where optimizations can start? I've not worked directly with the mySQL protocol before, but I suppose reading through some of that would give me some insight. I presume the "Row" case of the _return_packet VI is where you could use some pre-allocation. Maybe if I get some free time tonight I'll start playing with this.

What quantifies large or small recordsets?

Ahh - that's what it's called! I knew LV used something other than division for the node. Yes, that's the one

You could divide the number by 100 and use the quotient (integer result) of the operation.

Very cool. Thanks! Edit: Props go to hooovahh for this link, it messes with a few other things related to the console window.

Awesome! Do you have any code that will create a console window for output if there isn't a parent? Certainly would be handy for development.

LV8.6 is asking for a control typdef, Joystick.lvlib:ButtonState.ctl. I don't know if a license prohibits you from posting that here, though.

Are you passing relative paths? Referencing the help file on SCC/LVMerge I made that mistake at first as well (I was getting error code 7 out of NI_FileType.lvlib:Get File Type.vi). Using absolute paths worked fine, though. C:\Program Files\National Instruments\Shared\LabVIEW Merge>LVMerge.exe "C:\Program Files\National Instruments\Shared\LabVIEW Merge\base.vi" "C:\Program Files\National Instruments\Shared\LabVIEW Merge\theirs.vi" "C:\Program Files\National Instruments\Shared\LabVIEW Merge\mine.vi" "C:\Program Files\National Instruments\Shared\LabVIEW Merge\output.vi"

Is there any reason you can't call the LV app using something like "start /wait $exe"? start is a Windows-specific utility, but I'm sure other platforms (if you need them) have something similar.

It looks like you're heading in the right direction - still no luck in setting up LVMerge properly?

I had to go double check the Options panel to make sure I was thinking of 'tread' in the right way.

I don't see it anywhere either, but I'm not surprised - when exploits are found for a particular version of a web application it's easy to get burned listing the version somewhere. Whoo, google!

Since it's probably not just a single VI, it's best to package everything into a ZIP file and then attach it to your post.

I didn't know about this!

You can't just merge binary files (which VIs are, obviously) and while LV provides a merge tool, you'll usually spend more time sorting out the merge than just taking one version's changes and implementing it in the other by hand. As for locking, not really - the argument is made (for SVN, as well) that since locks are really only advisory, you should use "proper" forms of communication and collaboration. I don't agree - I think it's awesome to have an SCC which has a built-in mechanism for this situation. In theory, yes, that'd work. The reason I prefer locking is because it's very valuable to have the repository "know" when a developer is working on a particular object so that information can be distributed without any extra effort on the developer's part. I can't imagine having to e-mail around my multi-developer team everytime I was going to update a bunch of VIs - I only see that as useless overhead. Ideally, you never have developers working on the same extra area at once, but exceptions can (and always will) surface - if it's no skin off your back, why not use a system. I can see why you'd want to be able to make commits without necessarily pushing code, though; it's can be handy to have instantaneous versioning as you develop. There's no stigma involved because you're not actually committing WIP code to a public resource. So it looks like your decision weighs down to the flexibility of local version control versus a mechanism to control code concurrency.

These are the right questions to be asking - they're definitely problems OP is going to run into using Git. Since each developer has his own stand-alone repository, it would be very difficult to work concurrently on code; you don't know if anyone else is working on the same code until you've both sync'd with the master or pull'd one another's code. Either way, I think it would add a lot of unnecessary logistical problems that can easily avoided with existing, proven solutions. It's a really, really awesome system for files you can merge (a.k.a., text) but I think that (and some people on LAVA disagree) that using SCC with a locking paradigm is the right way to develop LabVIEW code.

Just out of curiosity, was there ever consideration given to the primitive having a context-menu option to offer access to either behavior?

Actually, it says "Ur computer needs" ...