[C][C++][Win32API] Can someone recommend a C++ GUI library that would suit my needs?

Hello out there...

I will give you some background on my project before asking the question.

My current job now is automating test equipment. The device I'm working with now (a Lakeshore 335 Temperature Controller) had no provided source library in any language. So, I built my own Lakeshore class using the Win32API serial class (WriteFile, ReadFile) and standard C file I/O. This class was designed in a console environment.

Now, I'm porting my code to a gui environment. I need to be able to write status messages from the Lakeshore class to the form controls and be able to control a global instance of the Lakeshore class with the various forms. I've tried and failed twice with 2 different gui libraries.

Windows Forms Application: this class uses the System namespace (which is horrible and full of bugs). This class would not let me create form instances in other files.

Qt: this class did not like sharing instances either, but it was more flexible in terms of what you can do with it. I ended up having to merge the two classes into one set of files. It still doesn't load the program though.

One of the reasons I haven't used the Win32 API to make the gui is because I have a hard time visualizing a gui through code.

So, I am asking, is there a C++ or C gui library that has those capabilities?

This is not a beginner's question. I'm looking for an educated response.

Thanks.

Agent86

What do you mean by "This class would not let let me create form instances in other files."?

Quote:

---

Originally Posted by Agent86

I'm looking for an educated response.

---

The traditional way to build a native C++ GUI for Windows is to use the MFC library.

It's supplied with the VS 2015 Community Edition which is free.

If you want to stay closer to Win32 please consider WTL,

http://sourceforge.net/projects/wtl/

This is not for everyone but for someone as educated as you it might very well be the perfect match. :)

WTL rocks!!!

Sorry, for the less than educated response.

Afraid the main problem here is not a GUI library, but bad/improper architectural design. There's no such a thing "GUI environment". When it's about GUI, it's always about very concrete requirements about what GUI library/framework to be supported, and good chances are there will be no common solution. The most universal solution (and most complex one) is ActiveX control(s) I guess.

Besides, typical approach is separating aspects of talking-to-HW and visualizing-in-GUI. I really doubt somebody could help you with this non-trivial issue, as proper architecting is impossible without delving into too much details. While you provide those near to nothing.

Quote:

---

Originally Posted by Igor Vartanov

Afraid the main problem here is not a GUI library, but bad/improper architectural design. There's no such a thing "GUI environment". When it's about GUI, it's always about very concrete requirements about what GUI library/framework to be supported, and good chances are there will be no common solution. The most universal solution (and most complex one) is ActiveX control(s) I guess.

Besides, typical approach is separating aspects of talking-to-HW and visualizing-in-GUI. I really doubt somebody could help you with this non-trivial issue, as proper architecting is impossible without delving into too much details. While you provide those near to nothing.

---

I may have coined the wrong term. The environment I was talking about was console vs gui. I'm porting my class written for console code into a gui project. The whole situation boils down to accessing gui controls from my hardware class and accessing a global instance of my hardware class from inside the gui class. The architecture of the classes are basically the same. I would like to keep them as separate as possible, unless I am forced to.

Okay, your hardware class should be unaware of any visualization aspects, and operate only in terms of messages. There must be messages sent to hardware, and messages got from the hardware. The messages to be sent, in case those are quite rare ones, may be send directly to hardware class under some lock obtained exclusively to avoid overlapping.

With messages to be sent from hardware to controls the process may be not that simple. There might be different policies of delivery. The most simple, and the most rigid one, is making a strict dependency between particular message type and control type expected to visualize that. In this case somewhere you store the controls' window handles to be receiving the messages of particular type (in other words, you store control subscriptions for messages), and each time the message is ready, it gets sent to all subscribers of the same type.

Of course, there might be more sophisticated dispatching with message queue served by dispatcher instance providing inquirers with data on demand and implementing some message retention policy. In this case the most flexible schema is implemented, when hardware class knows nothing about GUI clients and talks to message dispatcher only. On the other hand, clients know nothing about hardware class being in touch with message dispatcher class only. To send a command, GUI controls send those to dispatcher, and the latter one decides how and when the command to be sent to hardware.

As I said before, there may be lots of tiny details that to stipulate your decisions and approaches in design, and nobody knows those details better than you. So all real architecting is yours. :)

You want to shoot for separation of concerns and pick one of the various patterns out there: View Model, View Model Document, Model View Controller, Model View Presenter, Model View - View Model. All of the patterns have subtle differences, but all have the same goal of keeping one components' business out of another components' business. Read up on these patterns, try some examples, and choose what's best for you.

Quote:

---

Originally Posted by Agent86

I'm porting my class written for console code into a gui project. The whole situation boils down to accessing gui controls from my hardware class and accessing a global instance of my hardware class from inside the gui class. The architecture of the classes are basically the same. I would like to keep them as separate as possible, unless I am forced to.

---

One way would be to keep the thin interface you already have. A console application essentially means communicating with an application by way of a two-way serial pipe. The user writes commands and receives replies from the program. A GUI can be added as intermediate between the user and the console application, essentially running the text based console for the user who is happily clicking away on graphic widgets.

The above is a very high-level systems solution often implemented using inter-process communication at the OS level but it's also possible to use the same principle within a single application. Then a two-way producer-consumer queue is used as communication link and a more structured and formalised message language is used for the commands/replies.

This could be something for you. You turn your current console application into an "engine" which is spawned off in its own thread from a main GUI application. All communication between GUI and "engine" takes place via a single messaging channel so separation is the highest possible.