# Windows Programming

## Recommended Posts

tandlar    130

Hi Guys,

Just wondering if I am looking to make some tools for WIndows (3d editor, particle editor) is the Charles Petzold book still the best thing to go by?

Not interest in Windows 8 programming, just xp 7.

Thanks

#### Share this post

##### Share on other sites
Buckeye    10747

For the types of tools you mention, as they appear to have little to do with the Windows API, Petzold's likely to be as good as any for bitmaps, etc.

You don't mention what sort of 3D objects you may want to code an editor for, but there are probably better options than the Windows API for that purpose - e.g., an existing 3D editor such as Blender, etc. Unless your intent is for intellectual exercise and you really want to code your own "tool," something like OpenGL or Direct3D may be a better choice.

#### Share this post

##### Share on other sites

If you are asking about how to make GUIs for desktop applications, I really like Qt.

Here's a screenshot of a 2D tile-based editor I'm working on using Qt. The center of the editor uses a different API for drawing (SFML and OpenGL); you can make widgets be OpenGL-drawn as well as have Qt-drawn widgets.

Qt is also cross-platform for Windows, OSX, and Linux. Supposedly it's also recently gained cross-platformness for iOS and Android, but I'm not sure how well it works.

Edited by Servant of the Lord

#### Share this post

##### Share on other sites
SmkViper    5396
Petzold's Programming Windows, 5th Edition is still kind of the de-facto standard for basic C Win32 coding, though he's not going to cover anything added to Windows since XP or so due to the age of the book. Note that the sixth edition of the same book is Windows 8 Modern UI only which, IMHO, is a mistake where he should have just called it a new book rather then a new edition cause of all the confusion it will cause.

Outside of that, MSDN is a good Win32 reference, though it won't usually help you with the big picture it can help you do certain things once you have a basic idea of what you want. Though a lot of more modern features require a basic knowledge of how to use COM.

You can, of course, skip all that using UI frameworks like MFC (yes, it's still relevant and up-to-date for C++ coders), Windows Forms or WPF (for .NET languages), or third party libraries like the aforementioned Qt.

If you are going to do 3d stuff you're probably also going to have to integrate DirectX or OpenGL, as none of these frameworks support accelerated 3d rendering (Qt might, I'm not familiar with it). WPF can handle some 2d stuff rather competently, but it's more geared for vector work over bitmap.

#### Share this post

##### Share on other sites
SeanMiddleditch    17565
Pure Win32 or pure X11/POSIX are not good choices for building UIs, especially for tools. Seriously consider using a higher-level tool like Qt. Having built-in events, MVC, and so on will make a huge difference in the quality of your tools

#### Share this post

##### Share on other sites
tandlar    130

Thanks for the information guys.  I had worked on some tools back in the day but it was a combination of win32 and directx.  I will look into some of the things you suggest like QT.

It is mainly as a hobbyist thing on the side.  The one thing that I've always disliked is having to rely on learning someone else's tool, someone else's file format, and just when I get stuck on something having to wait for response or not getting a response.

Also when I say 3d editor it would be the standard 3 2d windows with one 3d window.  There are other options, but I've always wanted to make my own as mentioned above :).

Thanks Guys :)

#### Share this post

##### Share on other sites
ChaosEngine    5185

If your tool is Windows only, you might consider using C# and winforms (or possibly even WPF). It's a much nicer language than C++ to build UIs in and you can still interface with your C++ engine code easily enough using C++/CLI.

#### Share this post

##### Share on other sites
Glass_Knife    8636

If you are asking about how to make GUIs for desktop applications, I really like Qt.

Here's a screenshot of a 2D tile-based editor I'm working on using Qt. The center of the editor uses a different API for drawing (SFML and OpenGL); you can make widgets be OpenGL-drawn as well as have Qt-drawn widgets.

Qt is also cross-platform for Windows, OSX, and Linux. Supposedly it's also recently gained cross-platformness for iOS and Android, but I'm not sure how well it works.

If you don't stop talking about how awesome Qt is, I may have to start using it.  I didn't realize it had a built-in GUI API.  Is that something like Swing for C++?  And how does it do on the cross-platform issues like Look-and-Feel and input handling?

This is me getting Qt and QtCreator confused.  But I wasn't thinking about the Qt GUI stuff being enabled with QtCreator.  Looks like some powerful stuff.

Edited by Glass_Knife

#### Share this post

##### Share on other sites
SmkViper    5396

If you are asking about how to make GUIs for desktop applications, I really like Qt.

Here's a screenshot of a 2D tile-based editor I'm working on using Qt. The center of the editor uses a different API for drawing (SFML and OpenGL); you can make widgets be OpenGL-drawn as well as have Qt-drawn widgets.

Qt is also cross-platform for Windows, OSX, and Linux. Supposedly it's also recently gained cross-platformness for iOS and Android, but I'm not sure how well it works.

If you don't stop talking about how awesome Qt is, I may have to start using it.  I didn't realize it had a built-in GUI API.  Is that something like Swing for C++?  And how does it do on the cross-platform issues like Look-and-Feel and input handling?

This is me getting Qt and QtCreator confused.  But I wasn't thinking about the Qt GUI stuff being enabled with QtCreator.  Looks like some powerful stuff.

No GUI API is going to actually get you a true "native" UI feel without you doing some work to design your menus, layouts, etc to match the desired platform. The most they can do is abstract away the particulars of how common controls work and possibly shore up holes in particular platforms with custom controls.

For example, on a OSX your menu bar is at the top of the screen and child windows float freely, whereas in Windows the menu bar is at the top of the main window with child windows constrained to the parent window's bounds (for an MDI program). Another example is that OSX uses a "Quit" menu option to leave a program, whereas Windows will use "Exit".

As far as I understand it, Qt will implement the UI using native controls, which helps match the look-and-feel of the host OS, whereas something like Swing doesn't even try and will use custom controls for everything with an intent of keeping the program's look consistent, even if it drastically mismatches the host.

#### Share this post

##### Share on other sites

If you don't stop talking about how awesome Qt is, I may have to start using it.  I didn't realize it had a built-in GUI API.  Is that something like Swing for C++?  And how does it do on the cross-platform issues like Look-and-Feel and input handling?

There's the Qt libraries, and then later on they made QtCreator, which is an IDE (a really good one, as far as non-Visual Studio IDEs go), that includes things like a great GUI wizard builder. Qt can supposedly be used with other IDEs like Visual Studio, but it may require jumping through some hoops to get it working (they run a preprocessor on parts of the .cpp files to enable some features).

Qt (the API, which pre-dates the IDE) includes a huge number of cross-platform libraries using a consistent interface, kinda like Boost, but is most famous for it's GUI stuff. Apart from using the wizard, you can also easily create the GUIs programmatically, either manually positioning widgets, or (a better idea) using nested 'layouts', to automatically organize widgets horizontally, vertically, in grids, or so on.

Qt Layout Management

QWidget *window = new QWidget;
QPushButton *button1 = new QPushButton("One");
QPushButton *button2 = new QPushButton("Two");
QPushButton *button3 = new QPushButton("Three");
QPushButton *button4 = new QPushButton("Four");
QPushButton *button5 = new QPushButton("Five");

QHBoxLayout *layout = new QHBoxLayout;
layout->addWidget(button1);
layout->addWidget(button2);
layout->addWidget(button3);
layout->addWidget(button4);
layout->addWidget(button5);

window->setLayout(layout);
window->show();


(Note: Qt uses alot of calls to 'new', but manages the pointers to free them, so you use few, if any, calls to 'delete'.

In this example, 'window' will end up owning the pointers to the QPushButtons, because 'window' becomes their parent)

Cross-platform look-and-feel is handled by "styles". The widgets are often native widgets (so you can do things like get the HWND on Windows, if needed), and look native on whatever platform you are on, by Qt choosing, at runtime, the proper style without you doing anything. However, you can also tell Qt to use a specific style if you want.

Some of the layouts and widgets also rearrange things automaticly (which you can override) for different platforms - like placing OSX 'Ok' and 'Cancel' buttons in the proper location compared to Window's 'OK' and 'Cancel' buttons.

In addition to overall application 'styles', which can be difficult to customize, each individual widget can be styled using a domain-specific language called 'style sheets', inspired by CSS (but nowhere near as unwieldy and butchered as CSS) to theme things exactly as you want. I'm not a fan of CSS, but I like Qt's stylesheets.

In the screenshot I previously posted, the top tabbar/filemenu and the toolbar at the bottom are examples of where I used stylesheets to make them look 20% cooler. Also note that the "Notes" button in the lower-right is different (in appearance only) from the native Windows-themed buttons half an inch above it. Both are QPushButtons. Same as the icon-only and icon-and-text buttons on the bottom bar - all are QPushButtons by styled different and optionally assigned icons.

Here's a screenshot I manually touched up a month or so ago, showing how I use different drawing techniques for different parts of the editor.

And, ofcourse, you can have custom QWidget-derived widgets that uses Qt's QPainter class to draw it manually, or you can use OpenGL or DirectX to draw one or more widgets.

The only downside is, Qt works well for desktop applications like game editors, but isn't fast enough for things like 3D or 2D games that require smooth motions and high framerates. Qt is fast and responsive, but most of the frametime is stolen by Qt itself, so my 2D RPG won't be compiled with Qt, just SFML (OpenGL under the hood), but my editor is made in Qt, using SFML (and OpenGL) to draw the game view.

Qt uses signals-and-slots for sending messages between widgets (which works very well, but took me some time to get used to), and widgets also have virtual event functions that can be overridden for things like mouse movement, drag-and-drop, or repainting events.

Qt has a bit of a learning curve, since there are so many features and the libraries are so huge, but you can knock up GUI interfaces very quickly, either for mock-ups or for actual applications, so you can focus on coding the actual features behind the UI (or you can waste hours nitpicking your interface to make it look "cooler" like I do, instead of getting actual work done. ).

Edited by Servant of the Lord

#### Share this post

##### Share on other sites

For example, on a OSX your menu bar is at the top of the screen and child windows float freely, whereas in Windows the menu bar is at the top of the main window with child windows constrained to the parent window's bounds (for an MDI program). Another example is that OSX uses a "Quit" menu option to leave a program, whereas Windows will use "Exit".

And Qt, if you let it, will abstract those kinds of native differences (at least in theory! I'm a Windows-only user, so far).

"QMenuBar on Mac OS X is a wrapper for using the system-wide menu bar. If you have multiple menu bars in one dialog the outermost menu bar (normally inside a widget with widget flag Qt::Window) will be used for the system-wide menu bar."

On OSX, the Qt filemenus do use OSX's top-of-the-screen (instead of top-of-the-window) position, and Qt abstracts common keyboard shortcuts (if you want it to) to use the platform-specific menu spellings and shortcuts, and the platform-specific layouts of buttons. For example:

(Windows interfaces have the preferred option on the left, and the 'cancel' option on the right. Macs put extra space between 'Don't save' and 'Cancel')

It's probably not perfect, but your code should be able to compile fine (I've never done it before) on Linux, OSX, and Windows, and then you'll probably have to spend some time tweaking things a little bit with #ifdefs, but hopefully not much!

Oh, and LGPL ftw! As long as you dynamically link to the libraries (and share any modifications to the libraries themselves), you can use Qt in commercial code.

You'll have to talk to a programmer who actually release things cross-platform to get more details about the abstractions and any difficulties they run into.

#### Share this post

##### Share on other sites
Chad Smith    1343

(or you can waste hours nitpicking your interface to make it look "cooler" like I do, instead of getting actual work done. ).

Guilty!

And that's why I don't program UI's.  haha.  I always seem to spend all my time making the UI's look cool or saying "Ooo, look at this cool new feature!  My GUI needs this" instead of actually making it useful.  haha.

#### Share this post

##### Share on other sites
SimonForsman    7642

For example, on a OSX your menu bar is at the top of the screen and child windows float freely, whereas in Windows the menu bar is at the top of the main window with child windows constrained to the parent window's bounds (for an MDI program). Another example is that OSX uses a "Quit" menu option to leave a program, whereas Windows will use "Exit".

And Qt, if you let it, will abstract those kinds of native differences (at least in theory! I'm a Windows-only user, so far).

"QMenuBar on Mac OS X is a wrapper for using the system-wide menu bar. If you have multiple menu bars in one dialog the outermost menu bar (normally inside a widget with widget flag Qt::Window) will be used for the system-wide menu bar."

On OSX, the Qt filemenus do use OSX's top-of-the-screen (instead of top-of-the-window) position, and Qt abstracts common keyboard shortcuts (if you want it to) to use the platform-specific menu spellings and shortcuts, and the platform-specific layouts of buttons. For example:

(Windows interfaces have the preferred option on the left, and the 'cancel' option on the right. Macs put extra space between 'Don't save' and 'Cancel')

It's probably not perfect, but your code should be able to compile fine (I've never done it before) on Linux, OSX, and Windows, and then you'll probably have to spend some time tweaking things a little bit with #ifdefs, but hopefully not much!

Oh, and LGPL ftw! As long as you dynamically link to the libraries (and share any modifications to the libraries themselves), you can use Qt in commercial code.

You'll have to talk to a programmer who actually release things cross-platform to get more details about the abstractions and any difficulties they run into.

Personally i havn't had any problems with cross platform pure QT apps (Windows, Linux, i havn't tried on Mac yet), it just works as long as you stick to the QT libraries for everything. (It is a really awesome framework and QTCreator is probably the best free IDE on the market (imo it even beats VS Express since VS Express lacks plugin support)

#### Share this post

##### Share on other sites
SmkViper    5396
That's pretty cool that Qt handles some of that.

And I wasn't implying that it wouldn't compile or work, just that different platforms have different UI... "rules" that can be hard for a library to enforce from a generic layout.

Heck, not even OSs keep the same rules version-to-version. And some companies love to break the OS design guidelines cause it's "cool"... *cough*internet browsers*cough*.

#### Share this post

##### Share on other sites
Glass_Knife    8636

Next time I'm making a C++ editor or something like that I'm going to give this stuff a try.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

## Sign in

Already have an account? Sign in here.

Sign In Now