Saverio

I'm not aware of any "trick" to change how LabVIEW calls ActiveX code. Nor am I aware of any "trick" to change the thread model of an already built ActiveX component.

Actually, that thread does answer the question. The fundamental issue is that the ActiveX calls are done in the UI thread. Once you take this into account, the results you are seeing are exactly what should be happening, and there's no mystery. If your ActiveX component doesn't have a user interface then you may be able to use an MTA model with a wrapper DLL that can be configured in terms of which thread to use per call.

I had posted a few messages already on ni.com and one here before reading this. If I see any more that I would respond to I will respond with a general

"I would have provided a response to this question, but I'm protesting SOPA and PIPA.", and provide a link back to here. I think that may be more effective than simply not answering.

Interestingly enough, someone with the username of "Melbourne" posted a request for "content" for this book some time ago. http://lavag.org/top...7-labview-text/

This page contains the various messages: http://msdn.microsoft.com/en-us/library/windows/desktop/ff468922?v=VS.85%29.aspx. The individual pages provide the hex values for the messages.

A few days ago I was looking for a way get the hash from the VI-file. After some time of searching i find this

website.

This was actually discussed in this thread and in this thread.

A VI in an executable doesn't have a special "tag" to indicate it's called dynamically, since any VI can be called dynamically, even if it happens to be on the block diagram of one VI that is in the executable - another VI may go ahead and call that subVI dynamically. A project build spec will have a list of VIs that are added to the build since they are called dynamically by the code, but this list also include support VIs that you always want to include in the executable, regardless of whether they're called dynamically or not. Thus, this list could be misleading.

What are you trying to ultimately find out? Perhaps there's an alternate solution.

Just tried takskill on the osk within a cmd window and it doesn't like it for some reason (access is denied!) but it does work on other applications, so it should work for what I want to do.

It's a security issue. See this thread for more information:

That's why there was an idea submitted to provide this.

An idea was posted on providing this feature: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Project-templates/idi-p/1316961

Ummm... slight problem with example... the value for the item "Test123_*.* (doesn't work)" is actually defined as "Test_*.*". No files in the test directory match that pattern, irrespective of the List Folder function. If I place a string control on the front panel and enter a pattern of "Test123_*.*" then the resultant array is ["test123_1.txt", "test123_2.txt"].

I guess there is no way to bypass these security concerns?

Yes. Use a different operating system.

The VISA example (http://imageshack.us...lpt1outalt.jpg/) produces an error on my PC. Not sure why...

Did you ground the necessary pins? Pins 11 and 12. See here: http://digital.ni.co...6257206000551CB

So, after all this do you still think this is easier than simply getting an off-the-shelf digital I/O module?

There are numerous topics on using Xbee with LabVIEW over at the NI forums. I suggest reading over some of those threads first. If you still need help, either post a follow-up here, or over there.

http://forums.ni.com/t5/forums/searchpage/tab/message?filter=location&location=Board%3A170&q=xbee

A warning about those VIs: Vista and Windows 7 impose more strict security on direct access to hardware. If you want to manipulate the parallel port, use VISA. There's an example that ships with LabVIEW.

That said, the likely reason is that the required DLL is not being copied to you application's data folder. This is not surprising, given that those VIs shouldn't be used in the first place. See here: http://digital.ni.com/public.nsf/allkb/496CD7613F331EA4862571E200633507

Oops. Read graph instead of chart. I have a genetic predisposition to hate charts for some reason.

Are you referring to the start? If so, the Range:Start will do that: http://zone.ni.com/reference/en-XX/help/371361H-01/lvprop/scl_rangestart/

There is a long-running thread over at NI with the user asking this question: http://forums.ni.com/t5/LabVIEW/Sending-SMS-using-labview/td-p/1793088

Why is 3,3v a problem?

I didn't say it was a problem. I said it needed to be checked. You would need a different resistor value and what's considered "high" would be different.

Chicken Seriously though. This is kindergarten stuff. But if you've never used a screwdriver as a chisel, then maybe it's better to just throw money at it.

And when your motherboard gets damaged because you connected something improperly, or did not properly ground, or did not properly account for potential overvoltages or voltage spikes, then we'll see what's cheaper: buying a new computer or buying a cheap digital I/O module.

P.S. I always use a screwdriver as a hammer.

Then you can connect 5V LEDs directly or just short them to ground (if using as digital in).

This would actually need to be checked. If a computer comes with a parallel port it's likely to be 3.3V, not 5V. I know the old Dells we still have in the lab are 3.3V parallel ports.

In the end, it's probably better to go with an off-the-shelf cheap USB-based digital I/O module. There's tons of these on the market.

Unfortunately, VISA doesn't let you toggle the RX and TX lines, as these are controlled by whatever UART is used.

Did you look at the serial port example that I pointed out? Or do you mean something else when you say "take over the serial port manually"?

You may wish to consider reviewing this article: https://decibel.ni.com/content/thread/10841

Of course, the next obvious question will be: "how do I control those lines from LabVIEW?".

Answer: Look at the shipping examples. Help -> Find Examples. Then search for "serial". Then open the example "Troubleshooting Serial Line Monitor".

The document you linked to does not imply that Type Cast is supposed to interpret a U8 integer as an ASCII character. It does no such thing. That's the first assumption you need to let go of. Because of the way Type Cast works you can use it to convert a U8 to an ASCII character. But that's only because the ASCII codes were originally based on single byte values. Second, the document that you linked to only applies to the "standard" ASCII set (i.e., to values less than 128). For values of 128 or greater you do not get the extended ASCII set. LabVIEW displays characters on string-based indicators using Multibyte Character Strings. You can read more here: https://decibel.ni.com/content/docs/DOC-10153