How to use Win32 API winbase.h functions

[AndrazS]

Is there any way of calling functions regarding System Services directly from LV using call library function node? I'm interested in flushing communication buffers using PurgeComm function inside of a winbase.h Win32 API:

[JimB.]

What communication buffers are you trying to flush? LabVIEW has native functions to do this. For example: https://zone.ni.com/reference/en-XX/help/371361R-01/lvinstio/visa_flush_i_o_buffer/

It's certainly possible to call that function, but it doesn't seem like something you should need to do.

[rolfk]

Jim already basically answered you.

Technically it is possible to call pretty much every Windows API by using the Call Library Node. But just because you can, doesn't mean you should.

For the function you propose you can see that the first parameter is a HANDLE. This must be a handle opened by calling CreateFile(). CreateFile is a general purpose function to open both files and also devices and a few other things under Windows. For PurgeComm() to be able to do its thing you need to have opened a COMM device with CreateFile(). 

You can of course do all that and start interfacing to the entire Windows COMM API to do your own serial port handling but in 99.9% of the cases this is wasted energy since LabVIEW comes with the VISA functions that let you control serial ports just fine and offers many many other functionality including a Flush function that basically does the same as the function you show.

And no you can not take a VISA handle and just pass it to PurgeComm(). While VISA does under the hood eventually call the Windows COMM API for serial port resources, the handle to do that is a private property of the VISA session that you can not access. That's because it is buried in a layered VISA driver architecture that clearly isolates things between the different layers and that is good software design.

[3d0g]

Ah but here's the thing, CreateFileA() couldn't care less about a NI MAX alias.

In other words, if the COM port, say COM113, is known, then CreateFileA() can open it and CloseHandle() can close it.

That said, I'd still like to hear the answer to the question, versus asking why would anyone want to do that?  That is so annoying, to me.  But then maybe that really is just me.

[LLindenbauer]

---

@3d0g wrote:

In other words, if the COM port, say COM113, is known, then CreateFileA() can open it and CloseHandle() can close it.

That said, I'd still like to hear the answer to the question [...]

---

There is not much to add to this. If you really must use the Windows API, then go to the documentation at https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-purgecomm to learn that the function uses Kernel32.dll. You drop your Call Library Function node, point it to Kernel32.dll and select the correct function. Set the correct parameters, pass in the correct values and you are done.

I have simplified the last step somewhat - in fact, you won't be done at all, since you need more calls to prepare the context, handle errors and do proper cleanup. There is no short answer and there are no shortcuts to take here. This forum has enough resources to learn how to do these things if you must do so.

---

@3d0g wrote:
... versus asking why would anyone want to do that?  That is so annoying, to me.  But then maybe that really is just me.

---

Because the problem is tedious to work through, easy to get wrong, and dangerous when done poorly. It has already been solved for you many times in ways which are safe, sane, and easily resusable. Therefore it would be a tremendous disservice not to question the motive and point to alternatives. Consider it like this: If you have to ask about it, you are probably stuck at an XY-Problem.

[rolfk]

---

@3d0g wrote:

That said, I'd still like to hear the answer to the question, versus asking why would anyone want to do that?  That is so annoying, to me.  But then maybe that really is just me.

You are absolutely right. As I wrote, in 99.9% of the cases trying to replace VISA through direct API calls is at least one if not all of these:

- a total waste of time

- replacing a stable interface with a self developed one that is almost certainly more prone to trouble if you are not a very experienced C programmer who knows everything and then same more about memory management, buffer overruns and how a C compiler actually aligns memory

- if you ever want to move to a non-Windows version of LabVIEW, start over all again to interface to the new serial port API on that platform

And since you can't open a port with CreateFile() that has been opened with VISA and vice versa (a Windows limitation as hardware ports are generally considered a non-shareable resource), this is an all or nothing thing. If you want to use one Windows API function on your serial port, you have to do everything on that port with Windows API calls.

I also wrote in my answer about that you have to call the Windows CreateFile() API to get the handle to use with PurgeComm() and other Windows COMM APIs. You seem to feel annoyed that I did only explain that and not provide ready made VIs or snippets. But my motivation to create examples for something I consider pretty much a waste of time is basically non-existent.

Besides, if someone can't go to the Microsoft site, lookup those functions I explain about and create the VI themselves, they should not even trying to play with this, as calling external functions through the Call Library Node can be a very dangerous thing to do. Especially if you don't really know what you are doing.

As long as someone is at the point where he thinks "Great, Call Library Nodes let me do all these crazy things that the LabVIEW developers didn't want to give me an alternate function for" (and quite often that can be simply done in LabVIEW anyhow) without feeling at least somewhat afraid to start with it, they have basically no idea about the dangers (or are so experienced that they won't ask questions here) and are simply not in a place they should try to do this for anything but educational purposes. Definitely never ever include such code in a production style app if it hasn't been reviewed and vetted by someone really in the know! Just because it finally doesn't crash anymore after lots and lots of trial and error is absolutely no guarantee that you got it right! Not every memory corruption is immediately fatal. It could corrupt things that will blow up minutes, hours or days later.

[3d0g]

"If you want to use one Windows API function on your serial port, you have to do everything on that port with Windows API calls."

Yes, and thank you for confirming that, rolfk.

I appreciate you're taking the time to pass along good information to myself and others here in the forum.  I read every word you say to me.

To what you have said, I see no other alternative than use the winapi.  However, you are clearly much more knowledgeable than I.  Here's the situation.  You know you have a new device and Windows has enumerated it and given it a COMn.  Were you to open MAX and refresh, yes, it would be there, but that's it.  That's all you have.  In C, knowing the COMn, you could communicate all day long with the added device.  But how about using LabVIEW?  Is it as easy as doing it with C, creating a dll, and then talking with it with a CLFN?  What are your thoughts, roflfk?  ...besides telling me I'm not germane to the thread and should've opened a new one, etc etc.  Yeah, I know that, but my time is limited, and frankly, I do see it as germane.

[3d0g]

It was once (at least once, actually) said to me anything that can be done in C can be done with LabVIEW.

But is this true?

It'd seem reasonable that it's true, as after all LabVIEW is rooted in C.

...as is the WinAPI...

Actually this would be a good question to post to the community, but I'm sure someone already has.

[3d0g]

done:  (hopefully the link works)

https://forums.ni.com/t5/LabVIEW/LabVIEW-serial-port-programming-using-the-WinAPI-and-CreateFile/td-...

[rolfk]

---

@3d0g wrote:

It was once (at least once, actually) said to me anything that can be done in C can be done with LabVIEW.

But is this true?

It'd seem reasonable that it's true, as after all LabVIEW is rooted in C.

---

Your reasoning is flawed and wrong. Just because LabVIEW is written in C does not mean that everything you can do in C can be done in LabVEW. There simply is no way to create for instance something like a full featured OS in LabVIEW. It would be almost equally stupid to try to write a text editor like Word in LabVIEW. Same about kernel device drivers.

Ok, I correct this. Given unlimited resources, time and money, one might maybe be able to do these three things in LabVIEW. But unlimited resources is something that doesn't exist either, so there you go!