|This is sample code, right? All it's showing you is how to interact with your message pump in a WPF application, and what you should do in that message pump. It's possible the example also shows how to register for those messages, but I assume the scanner drivers are just broadcasting the messages. Path of least resistance, and all that.|
So let's strip away the layers of .NET abstraction, and look at what a Win32 app would need, because .NET doesn't negate the requirements of Win32. Be forewarned, my knowledge on this stuff is over 8 years old. I doubt it's changed that much, but don't exactly ask for working code samples.
So, what would a native app need? Well, you need a way to get the data from the drivers. In the code sample you provided, that appears to be done by m_Isdc. There's 1/2 of the job done.
The drivers are broadcasting messages out, so you'd need a message pump to catch those broadcasts, and your message pump needs to look for those messages. That code sample shows you how to tap in to your existing WPF message pump. I assume there's no WinForms example 'cause you'd just override your WndProc.
WPF isn't the relevant part. A message pump is all you need. If your application won't have a GUI, or you want to separate out the GUI from the I/O, you'll need to implement your own pump. Ideally not on the GUI thread. Easiest way to do this is to inherit a System.Windows.Forms.Form and System.Windows.Forms.ApplicationContext, override the WndProc and constructor respectively, then call your context from Application.Run. Optional: wrap all of this up in its own thread. Now you have to deal with multi-threading, so good luck with that.
How To Ask Questions The Smart Way
message edited by Razor2.3