Windows messaging

[rolfk]

---

Jason P wrote:

It's the direct call part that I hadn't thought of, which made me realize I had a bit of a blind spot in my thinking.  My background is in physics, not programming - I got into LV long before I understood what was under the hood... and I still have a bad habit of using the crutches I used in the beginning.  Getting stuck with DLLs that aren't strictly necessary is part of that.  Speaking as someone who spends a significant amount time working on installers, I'm happy any time I can strip away extra parts. 

Jason

---

External DLLs are almost never superfluous. Calling directly into Windwos APIs while possible is in fact a clutch in most cases. Those APIs are not exactly meant to be called from a high level language like LabVIEW and quite often it is a lot of hassle since you have to call numerous APIs to do a single thing. My thum of rule iss anything above 4 APIs for a specific operation is a sure candidate for an external wrapper DLL (and of course as soon as an API is involved that takes complicated parameter types.

In my case however I do have a universal lvutil.dll that I add new generic functionality to when necessary, to reduce the number of external DLLs an application might need. However if I write a specific library of functionality such as IP6 network operation, ODBC access interface, WIA camera interface, TWAIN interface etc. I always put them in ther own DLL to separate the implementation of the various interfaces from each other even if several of them end up in the same application.

[jtaylor]

Hi Hamilton and Rolf,

Did either of you get the Windows Message Queue to compiler for later versions of LabVIEW? I'm running 2012 and am attempting a compile with VS 2010. The prototype and use of the Occur function is posting a lot of errors.

Thanks.

Jeff

[Hamilton_Woods]

That thread is a couple of years old (well, maybe 4 years).  No, I was not successful posting or reading Windows messages from Labview 8.5.  I ended up writing a middleware solution using VB.NET.  LabVIEW interacted with the VB.NET application using sockets and the VB.NET application interacted with the 3rd party software using Windows messages.

[jtaylor]

Thanks Hamilton. I have a custom USB HID device I'm using. Have a DLL written in C# and am interfacing it to LV. In C#, have no trouble adding on to WNDPROC to get the arrival departure notifications. In LV, get the notifications, but it seems the message data associated with the departure message isn't valid by the time I processit. Thought it may be a x32 vs x64 thingy, but now I think not since I'm running LV in x32.

Thanks for the response. I'm just not going detect devices leaving. I'll leave it up to the operator!  %)

[rolfk]

I didn't try to compile that library but I'm not sure what the problem might be with Visual C 2010. While the C code of the Windows Message example is indeed a little messy, I don't think there should be real trouble to compile that for LabVIEW 2012 and or Visual C 2010. One problem however could be if you try to compile it for 64 Bit Windows. In that case there are several issues both in the C code as well as in the LabVIEW interface that won't work out of the box.