I'm wondering who is Win32GUI library intended for? Recently I've been searching for the best library to write GUI. Currently I'm trying Win32GUI. I must admit that it looks really nice. But I have two objections: libs are too big (my static debug lib compiled to 130MB!) and it's too closely tied to WinAPI - from the lib users' side. AFAIK the first is going to be handled soon, but what about the latter? I don't want to know much about WinAPI, really. Is Win32GUI going to hide all WinAPI stuff or maybe it's going in other direction? I'd rather have call to WinMain macro'ed to some kind of Win32GUIMain, etc. Creating a menu is still magic for me... and the resource script is just one big confusion, because I'd rather use Dev-C++ (or maybe now unsupported Digital Mars Compiler, which is free, fast and quite conformant with standard...) than MS Visual.
Finally, I'd like to thank John Torjo for the greate job!
win32gui is not intended to replace the win32 api - the goal is rather to make gui programming as easy and safe as possible. after all there are a huge number of windows developers and i think it would make no sense to abstract away all things the users are used to. for example creating dialogs (or, as you said, menus) is a common task everybody knows. but it is also quite often a messy task to handle all kinds of messages or WM_COMMANDs in a huge switch...
MFC for example does ease this, too. but it has some big drawbacks (message-maps, not STL-friendly, window classes can have only 1 base class, too close to winapi, ...). win32gui has very good answers to a lot of this issues - you are freed of knowing all the winapi-structs a lot of time. but unfortunately sometimes you have to code with this oldfashioned stuff since we haven't wrapped all parts of the winapi yet (which is a horrible task...) ;-)
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.