Qt and the Win32 API.

[hickscorp]

Hello High Flyer, and thank you very much for your answer.

I didn't quite understand what a "wrapper between" might be.
You wrap something, not between things.
I also am not sure if you mean realy a device driver, or more lib which works with a device driver.

Right. i'm wrapping a DLL which provides access to a peripheral. i'm making a DLL itself which will make functions from the 1st DLL accessible from the Windev application.

In any case, if you are working with a device driver on any level, it is system specific, so you might as well use system specific code, at least in the parts that are system specific.

In this case, it's not the driver, as you pointed. It's a DLL provided with the driver, which provides I/O to a peripheral, but is coded to work only with windows. Too bad.

Under windows, you will have to create a message loop, if you want to process events.
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
If there are no windows in the application, you wont have HWND to give, and you will have to use NULL.
But if you make your own message loop, you can handle messages to "no windows" as well.

i'm not sure i understand... How will the 3rd party API be able to send me messages if i'm giving it a NULL HWND?
Let's say i create a message handler, how will i tell the 3rd party DLL to send the messages to this loop, since it's usually bound to the HWND object passed?

[Coises]

This is similar to (though more complex than) a problem on which I’m working. The HWND part is pretty simple.

If you create and instantiate a class derived from QWidget, you can use QWidget::winId to get an HWND (assuming you’re sure you’re running under Windows, of course). It doesn’t matter that you don’t want to see the window... you just never show it. Use QWidget::winEvent to capture the messages.

[faldzip]

It's a DLL provided with the driver, which provides I/O to a peripheral, but is coded to work only with windows. Too bad.

If it is Windows driver with an API provided in Windows DLL so it will work only for Windows and rather any cross platform wrapper will not work because for other platforms you need to have different driver and I don't think that DLL will work anywhere else. I don't know exactly what Windev application means. Is it coded in C# (so using .NET) or in C/C++ using WinAPI? If it is using WinAPI than i think you don't need Qt as well, just code in WinAPI as you DLL uses WinAPI and your app uses WinAPI...

[high_flyer]

i'm not sure i understand... How will the 3rd party API be able to send me messages if i'm giving it a NULL HWND?

Usually you have to give a function pointer to a call back.
There HWND can be null, and with your message pump you handle messages of type X and not on a window basis.
(like for example handling SetTimer() in a console application)

But I misunderstood your first post to some extent, and I too recommend to go the way Coises suggested.

But putting the extra effort in cross platform wrapper only makes sense, if he driver is also available on other platforms, and, that it uses the same API it does under windows.

[hickscorp]

Hello guys and thanks a lot for all these answers.

i've kinda figured that out now, with all your help and digging into the Win32 API... Now the problem extends to this thread: http://www.qtcentre.org/threads/2747...n-In-a-library
If you guys who helped me can be kind enough to have a look at the thread, i'll be eternally greatfull

Thanks again to you 3!
Me.

[faldzip]

But putting the extra effort in cross platform wrapper only makes sense, if he driver is also available on other platforms, and, that it uses the same API it does under windows.

As it uses HWNDs I don't really think that it is mentioned to be used anywhere but on Windows. My suspicions are that this app is made for Windows only and this driver and it's library (in DLL) i provided for Windows then using Qt there is rather adding some needless dependency which is used to "translate" WinAPI to Qt and than "translate back" to WinAPI, just to use Qt's classes, structs and functions as they are more user friendly and you don't have to learn WinAPI much. I don't know how complicated is the main task which has to be done, but if it is not a really big one then learning and using WinAPI without Qt would be the proper idea. For me it looks like adding new functionality for Java-only project using C++, just because you don't know and don't want to learn some Java...

[hickscorp]

As it uses HWNDs I don't really think that it is mentioned to be used anywhere but on Windows. My suspicions are that this app is made for Windows only and this driver and it's library (in DLL) i provided for Windows then using Qt there is rather adding some needless dependency which is used to "translate" WinAPI to Qt and than "translate back" to WinAPI, just to use Qt's classes, structs and functions as they are more user friendly and you don't have to learn WinAPI much. I don't know how complicated is the main task which has to be done, but if it is not a really big one then learning and using WinAPI without Qt would be the proper idea. For me it looks like adding new functionality for Java-only project using C++, just because you don't know and don't want to learn some Java...

i have all this reflexion in mind already thanks. But the question wasn't about that at all. The "Wrapper" will have to do very complex things (Not only just wrapping things). Handwriting recognition, MICR reading and patterns recognition. That's why i choose Qt, because i want all my objects to be easily cross-platform... i've already wrote the abstraction class for the scanner wrappers (The whole complex thing will work with the abstract class), and i'm now trying to create as many derived classes as there are scanners used by the customer... All in the same library. Of course, if one of them is only providing an API which is highly Win32 oriented, the first thing i'm doing is looking for very generic drivers. Too bad for me, there are none for the one giving me the problem.

Anyway, now the problem seem to more be about QCoreApplication and it's main processing loop, that's why i've posted the link to the other topic here: http://www.qtcentre.org/threads/2747...n-In-a-library .
Thanks a lot for your efforts and time trying to sort things out
Me.

[faldzip]

i have all this reflexion in mind already thanks. But the question wasn't about that at all. The "Wrapper" will have to do very complex things (Not only just wrapping things). Handwriting recognition, MICR reading and patterns recognition. That's why i choose Qt, because i want all my objects to be easily cross-platform...

What is the point in making cross-platform classes and mix them with WinAPI stuff in one library which depends on the Windows specific driver and library? I think that you should divide you project into two parts:
1. Your library doing all you want, like pattern recognition etc with some public pure-C++ API (you know, using std::strings, iostreams or whatever). This library will use Qt and standard C++ libraries so it would be fully cross-platform.
2. Now create wrapper for your driver and DLL which will be platform specific and will provide API that suits your previously created cross-platform library. In your case it will be written in C++ using WinAPI and will provide data for the library.

In this case new platforms and scanners will require new "wrapper" and will always use that one cross-platform library but in your solution, new scanner will require writing new library if your library has crossplatform classes but placed in one library with platform and device specific stuff...