m3nth

Lucky you. You'll need a low-level keyboard hook since there's no pre-canned way to do it in Windows. That basically means writing your own DLL and exporting the functions you'll need to disable it. Or finding someone else's if you can. Here's a good reference, search for 'hook' http://msdn.microsoft.com/msdnmag/issues/0...qa/default.aspx

Do you need to disable it for your program and then re-enable it after your program is done? If so, this wouldn't work, but you can look at it: http://www.winguides.com/registry/display.php/905/

That's awesome!!!! So was the one about holding down the shift key and dragging the icon. Won't find those anywhere in the manual

I suggest you not use 3D plotting. Just a suggestion. It is not actually such a hugely complicated problem which is why people have coded it and added it to things like the logo animation that was posted. Look around a little, there's good info out there on how to do this without using a 3d mapping/rendering to make it look right.

Well, if "another VI" is a VI within your application, you can easily get a reference to the cluster and access the Controls[] property to get an array of references to each control in the property which you can check by label name usually (for loop + name comparison). That can get you the reference for a single control in your cluster which can be used to read or change the value. If "another VI" is a VI not within your application you can still get a reference by opening a VI reference and traversing the class tree, albeit slightly more complicated. It's basically the same as above though. I would look at some of the examples in the scripting forum on that note.

Nice. Someone was really paying attention on that one! Can't say I've never made that mistake before either--nice catch PJM.

I agree that is a GREAT observation :thumbup:

With the above advice in mind, if you just do things the way you normally do them, but use an llb to contain all your files and the top-level VI it will work right also (since an .exe is just a renamed .llb with the PE header and all that).

I get the same behavior for LV 7.1.1, looks like a bug to me. A workaround would probably be to use the window manipulation VI's to minimize programmatically, although I didn't try it myself.

Wow. That's pretty cool. And the code is so complicated it's making my head spin. nice

Wow. That's a good suggestion I hadn't thought of. I second!

That would be nice. Here's a quick mod to Michael's version which drags only selected text. - Select text using left click as normal - Drag text to string indicator using right click & hold Download File:post-360-1126099569.llb

The same loading dialog will popup even when the files are there if you loading a bunch of them or if the computer is slow. You can completely avoid it regardless by using a splash screen which displays a picture usually, then opens a VI Reference to the top level VIs you want to call (which loads them in the background without the dialog you were talking about) and then once everything is loaded the top-level VI's are called to run and the splash screen VI exits, leaving the top-level apps running. There is a splash screen example program somewhere on NI's website.

That was a great presentation. I couldn't count how many times I've had gripes about multiple items that were mentioned there... lots of good stuff pointed out and more importantly, how NI can maybe go about avoiding such things in the future.

No, not what 'p' is in SI, but why it is used to represent SI: d = decimal o = octal x = hex b = binary p = SI??

Wow... I'd give you a five-star rating for knowing that. I noticed the same thing on both counts: That LabVIEW takes much longer to load and that the error is obviously from Windows and not LabVIEW. What I didn't figure out is putting two and two together Thanks for the info :thumbup:

I'm not really sure where this post goes. Have you ever seen an ActiveX class integrated into LabVIEW? I believe the reports VIs for interfacing with MS Office and things like that use them. The methods and properties are available like a normal property node when using the class reference. These are really slick. I've seen LabVIEW hardware drivers implemented using these so you have the hardware functions available inside of LabVIEW... that kind of thing. My question is, how do you make one? How do you start from scratch and make something like that? Are there any good references to guide one through the process of making an ActiveX class and/or integrating it with LabVIEW? I'm sure I'll find some stuff on the web about ActiveX but I was wondering if anyone has experience on the LabVIEW integration end of things.

Well, a variant input can take anything you wire to it even though it doesn't technically adapt to that type. You could at least wire the variant to the flatten function and save whatever you decide to pass in.

And if you have to take the easy way out and use a global, don't use a LabVIEW global. Read up on LV2 or Functional globals, which are VI's that retain information in between calls (so they can be called anywhere to access that information, thus making them global). Regular LabVIEW globals are in general, a bad idea. Edited to add, btw...... this is probably in the wrong forum. Maybe the sysadmins can move it.

A huge second to this request. What a pain.... I can't remember how many times I've had that problem. Always always a pain in the neck.

Nice. Would you like that to be false? or false?

So you need the data to be acquired at 1200Hz with no buffering available? Perhaps if you did write a wrapper DLL it could just be a buffer that you could poll at a slower speed than the speed of your acquisition (like most normal DAQ routines).

Ok so that's the answer: The name is returned by the Object Inspector.vi in the Statistics Cluster and you can essentially do the same thing by just calling the Class Repository with the given reference and the Get Statistics enum for the Method input.

Wow. That sounds complicated. Rolf! Where's Rolf!? He might know. So you want to use LabVIEW code as an interrupt handler and then pass along a pointer to that LabVIEW code so it will be executed on an interrupt?? I have limited knowledge in this arena but I'm wondering if you can't implement your own interrupt handler in C using your own custom DLL or code interface node. That would let you come up with a block of code to execute as the handler that you could get a pointer to and pass along to your DLL. Then you could use that block of code in conjunction with some easier mechanism (Queue, Notifier, Occurence etc) to communicate back to LabVIEW that it needs to do something. That way you wouldn't have to directly have a pointer to a chunk of LabVIEW code, but it would still do nearly the same thing. You would also have the option of performing a poll then in LabVIEW which might even be easier than an interrupt driven chunk of code (but that might not be exactly what you need). Can you expand on how fast you need this to execute? Do you think a dedicated parallel loop in LabVIEW that was polling at a certain rate would be adequate? That sounds a lot lot easier than getting an interrupt handler to directly run LabVIEW code.

TTL is digital, not analog... you can't check voltages in between unless you're doing an analog acquisition.