Click here to Skip to main content
Click here to Skip to main content

QuickDialogs - a library for creating dialogs quickly and elegantly

By , 23 May 2011
 

An options dialog created with quickdialogs

Introduction

Consider the ubiquitous Windows message box. It's possibly one of the most used and familiar pieces of UI in Windows, in no small part due to how easy it is to create one:

MessageBox(hwnd, "Hello, World", "Message", MB_OK);

Just take a moment to consider how wonderfully simple that is. You can create an entire window in one beautifully clean line of code. The downside becomes apparent after using it for a while - flexibility. With a messagebox, you have one blob of text, an optional icon, and a predefined set of buttons to choose from. And that's it. No edit boxes, no checkboxes, no other feedback. Now, there are quite a number of dialogs which require a little but more than the messagebox offers, however the compelling simplicity has led the messagebox to be used where a custom dialog would be more appropriate (square peg in round hole syndrome). A common example is rephrasing what you are asking so that it fits "Yes", "No", or "Cancel", or the even more horrific "Click OK to do x, or Cancel to do y".

QuickDialogs is a framework which aims to provide a much greater level of flexibility to building a dialog while keeping as much of the simple elegant syntax of the MessageBox API call as possible. The strengths of QuickDialogs is threefold:

  1. It's quick. Producing a simple dialog takes a bit more code than a message box, but much less code than a custom dialog.
  2. It's consistent. Because the dialog code handles all the layout for you, dialog boxes look and feel consistent without any effort.
  3. It's customizable. The library is based on templated classes, and many parts - the base window class, and the layout engine can be swapped out with your own custom classes. You can add your own controls to the dialogs.

It's important to note that it's not a general purpose window framework. It's designed to do one specific task (dialogs) well. If you want a good general window framework, look at WFC, MFC, or Win32++, or any of the many other excellent frameworks out there.

Background

The inspiration for this library came about from a similar library we have at work which does a very similar thing. However that library is written in pure C and uses varargs macros to accomplish dialog definition and instantiation in a single call. This means that there is no type safety and you have to know the parameters off by heart - crashes are frequent when constructing a dialog. It's also completely undocumented, and the code is not the most clear and concise in the world (I found a char**** in the depths of the code once, which is still the most indirection I've ever seen on a production code pointer).

I've wanted to rework it in my own image for a while, but couldn't think of a way to keep the concise syntax whilst making it readable and type-safe. It wasn't until I started playing with boost and saw some of the remarkable things with operator overloading done by Boost::Format and Boost::Spirit that I came up with the approach presented here.

How it works

QuickDialogs uses operator overloading to provide a type safe mechanism to insert an arbitrary number of controls onto a dialog. Controls are inserted using the stream insertion (<<) operator. All of the control's properties can be set through constructors, allowing dialogs to be written declaratively in only a couple of lines of code.

Layout is qualitative - rather than manually positioning controls, you just add the controls in, specifying this such as "I'd like the controls on the same line as each other", "centre this control", or "put these controls in a new column". Layout control is provided by the | operator, and by special controls columnbreak and sectionbreak, and alignment control is provided by the + and * unary operators. In order to accomplish this, controls are sized automatically.

Most of the classes are templated in order to handle Unicode flexibly and to provide customisation and extensibility - you can swap out the layout engine, change the base dialog window, and write your own controls without needing to modify the library*.

*Having said that, someone will immediately come up with a perfectly good idea which it doesn't handle. We'll cross that bridge when we come to it.

Using the code

First, you need to copy the header files into your include path. There are no CPP files required - the library is header only. Then #include <quickdialogs.h> in your project and you're good to go! Well, not quite. You will need to link to user32.lib, gdi32.lib, and comctl32.lib as well.

The best way to show how it works is by giving examples and then analysing them step by step. Let's start with a basic dialog.

dialog d("My first dialog");
d << "Hello, World!"
  << spacer()
  << *button("OK");
d.show();

Which gives us a basic message box:

A simple messagebox lookalike

This is about twice the amount of code that we would need if we used the MessageBox API call, but it's still pretty small. Now let's look at each part of that code in turn:

  • dialog d("My first dialog");. This creates a new dialog with a caption.
  • d << "Hello, World!". This adds a new paragraph (static control) with the text "Hello", World".
  • << spacer(). The adds some vertical space between the last control and the next.
  • << *button("OK");. This creates an OK button. The * operator is an alignment operator (centre). The default alignment is stretched to fit the width. You can specify any text you want for the caption of the button. By default, the return value is equivalent to "OK".
  • d.show();. I'll leave working out the meaning of this one as an exercise for the reader ;).

Now let's try something a bit more functional:

bool check = false;
HICON ico = (HICON)LoadImage(NULL, "ChickenEgg.ico", 
             IMAGE_ICON, 0, 0, LR_LOADFROMFILE);

dialog d("My second dialog");
d << image(ico)
  << columnbreak()
  << spacer(20)
  << "Which came first, the chicken or the egg?"
  << sectionbreak()
  << spacer()
  << ~*(button("&Chicken", qdYes) | button("&Egg", qdNo) | button("&Don't Care", qdCancel))
  << spacer()
  << check_box("Don't ask me pointless questions again", check);
if (d.show() == qdYes)
{ /*...*/ }

This looks like:

Chicken or Egg dialog

This is where the flexibility of QuickDialogs shows through over classic message boxes. We have added custom buttons and a checkbox. Let's look at them in more detail:

  • We've added an image in - loaded from a custom icon file. Anything that can be expressed as a HBITMAP or HICON is allowed. All the standard icons you see in message boxes are available using the LoadIcon function (check MSDN for details).
  • Layout - notice the use of two new controls - columnbreak() and sectionbreak(). These are layout controls. The layout engine in QuickDialogs divides controls into columns and sections. If you want to add a new column, add a columnbreak, and the layout engine will create one in a sensible place. Similarly, if you want to start again on the left hand side below all the current columns, add a sectionbreak. Here, we're using it to line the question up next to the icon, and centre the buttons beneath both of them.
  • We've added a group of buttons, denoted by ~*(button("&Chicken", qdYes) | button("&Egg", qdNo) | ...). The grouping operator (|) is used to create a group of controls that appears on the same line. As before, we have centred the group with the * operator. The ~ operator is a special operator specific to groups - the uniform grouping operator. It makes all the group controls the same width and height (the width/height of the largest controls). This was designed with buttons like this in mind - it gives the buttons a uniform size, as you would expect to see in a dialog box. The buttons are fairly self-explanatory, but note that we specify the return value of the buttons (qdYes/qdNo/qdCancel).
  • The final point of note is the checkbox - check_box("Don't ask me pointless questions again", check). We pass in a bool by reference (check) - this serves two purposes. Firstly, it specifies the initial state of the checkbox (true for checked, false for unchecked). Secondly, it will contain the state of the checkbox when the dialog box returns. This simple "pass by reference" binding is used with all the controls that expect input/provide output.

Finally, something more complex: a tabbed options dialog:

int fontsize = 2; 
std::string autosaveinterval( "10 ");
char* fontsizecaptions[] = {  "Very Small ",  "Small ", 
      "Normal ",  "Large ",  "Very Large " };
bool bold = false, italic = false, underline = false, strikethough = false;
bool superscript = false, subscript = false, smallcaps = false, normal = true;
bool reloadonstartup = false, multiinstance = false, 
     splashscreen = true, lockfiles = false;
bool linenums = false, autosave = true;

dialog d( "Options ");
d  << (tab_control(0) + (tab("Font ")
       << (paragraph( "Font Size: ") | 
             combo_box(fontsize, fontsizecaptions, fontsizecaptions + 5))
                   << (groupbox( "Styles ")  << check_box("Bold", bold)
                         << check_box("Italic", italic)
                         << check_box("Underline", underline)
                         << check_box("Strikethrough", strikethrough)
                         << columnbreak()
                         << radio_button("Normal", normal)
                         << radio_button("Subscript", subscript)
                         << radio_button("Superscript", superscript)))
                + (tab("Other options ")  
                    << check_box("Reload last document at startup", reloadonstartup)
                        << check_box("Allow multiple instances to run", multiinstance)
                        << check_box("Display Splash screen", splashscreen)
                        << check_box("Keep files locked while editing", lockfiles)
                        << check_box("Show line numbers", linenums)
                        << (check_box("Autosave every", autosave) | 
                             edit(autosaveinterval, esNumber, 25) | paragraph("minutes"))))
                        << ~+(button( "&Apply", apply_changes, qdNone) 
                            | button( "&OK", qdOK, true) 
                            | button( "&Cancel", qdCancel));

The result of all this code looks like this:

Options Dialog - First Page Options Dialog - Second page

Whilst it looks more complex than the previous dialogs, most of this is exactly the same as we've seen before. The key new concept is the container controls.

  • There are two container controls used here - group boxes and tab controls. Groupboxes work the same way as dialogs - you can insert controls using the same set of operators. Tab controls are slightly different: a tab control contains only tabs (added with the "+" operator). A tab works as per dialogs and group boxes.
  • We use an event in the Apply button - it calls the apply_changes function to apply any changes to the dialog. You can use function objects as well, or lambdas if you're using C++0x.

All these dialogs are included in quickdialogs.cpp with the project so you can see how it works. I've also included a test dialog which uses every control so you can see an example of how they all work.

Points of Interest

  1. When looking for the best way to link a C++ class instance with a window class instance, I thought a nice straightforward way would be to use the User data that is stored with every window class (i.e., using SetWindowLongPtr(hwnd, GWLP_USERDATA, ptr)). However I found the hard way that, as Raymond Chen points out in his blog The Old New Thing, this data is actually reserved for the window class to use as private storage, and not for the user of the class to do (and the SysLink control makes use of it). A better solution is to use GetProp/SetProp, together with a global string atom to increase the lookup speed. Apparently, this is what .NET uses.
  2. Unicode. Although I have not discussed Unicode, the library is fully Unicode compliant. Each control has a Unicode equivalent (usually the same name preceded by a 'w'). You can use Unicode controls on a non-Unicode dialog, and vice versa. I can't think of why you would ever want to, but it was quite cool to implement.
  3. When wondering how to implement something, look at the .NET Framework. The .NET Framework has been astoundingly useful as a reference on how to do things, in particular how to auto-size controls. In these cases, .NET Reflector is your friend. Or it was, until they removed the free version. Look for ILSpy instead, which is a free, Open Source alternative with very similar functionality.
  4. Themes. Themes are a real pain in the arse to get working properly. It took some time and effort to get the various different button and static controls drawing correctly on themed tab controls. For anyone trying to get the same thing working, look at EnableThemeDialogBackground in the Windows API. Note that it only works on dialog boxes. Windows that have the same window class don't seem to work. You seem to need to put it in WM_INITDIALOG as well - it didn't seem to work anywhere else. You have no idea how annoying this was to fix.

Compiler Compatibility

The code is C++03 compliant (apart from a small lambda expression in the sample code...), but requires TR1. I've got clean, warning free compiles with the following platforms:

  • Microsoft Visual Studio 2010
  • Microsoft Visual Studio 2008 SP1 (SP1 is required for TR1)
  • Intel C++ 2011
  • GCC 4.5.2 (MinGW) with boost TR1 libraries.

I tried getting it to work under CLang using boost, but received a few errors compiling the type traits in boost, and after the monumental effort to convert a clean compile on VS2010 to a clean compile on GCC, I didn't feel like trying to find the right combination of CLang and boost. But it's not far off, so I would imagine that it will "just work" in a few versions' time.

It compiles as 32-bit in all compilers, and 64-bit in VS2010 and VS2008. I haven't tested 64-bit in any of the other compilers.

OS Compatibility

This has been tested on Windows XP, Windows Vista, and Windows 7.

In theory, it will work with Windows 2000, but I haven't tested this. If anyone feels the urge to use an 11 year old unsupported OS, let me know if it works.

Linux lovers, if you've got this far, well done, but this is Windows only. I have no Linux programming experience so you're out of luck, although I've just installed Ubuntu at home, so maybe in the future... The approach would in theory still work, so if anyone implements an equivalent library for their favourite Linux or cross platform widget toolkit, I'd love to hear about it.

Alternatives

  1. The venerable Windows messagebox is quick, simple, and entirely inflexible. But it is a part of every version of Windows and it is simple to use.
  2. In Windows Vista and above, you can use the TaskDialog API. This was introduced to solve much the same problem domain that this library covers. Advantages over QuickDialogs is that it is a standard OS part, and offers progress bars and command link buttons, which QuickDialogs currently doesn't. QuickDialogs offers a wider range of controls, much more flexibility of layout, and can be used on Windows XP as well. Depending on your goals, either is a good choice.

Future Plans

  1. Documentation - this article is currently it. I'd like to write something more substantial. I'm considering writing articles on how to customise the various parts of the framework, so thoughts and suggestions would be welcome.
  2. Resizable dialogs. It would be quite cool if the dialogs resized. Don't think it would be a lot of work, given the whole framework is built around automatic layout.
  3. More controls - Progress bars, ListViews, and the Vista command link controls. Requests for others (e.g., ComboBoxEx, Trackbars, Scrollbox) considered.
  4. TaskDialogs - I'd like to make the functionality a superset of the TaskDialog API, and have the ability to produce dialogs that look similar to those from the TaskDialog API. I haven't decided on an approach to this yet, so any suggestions would be appreciated.
  5. There are a few places where you can specify minimum sizes for different controls - currently these are all in pixels. I'd like to change this to use dialog units, which will make things resolution independent.
  6. There are still a few minor layout bugs. I'm tracking them down one by one...

History

  • 8th May: First version!
  • 22nd May: Fixed issues compiling with UNICODE defined and added "t" typedefs of the controls (thanks to _flix01_). Fixed embarrassing copy-paste error reported by marl.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Rotted Frog
Technical Lead
United Kingdom United Kingdom
Member

A youthful, enthusiastic (albeit dead) amphibian coder writing software for a financial information firm based in the UK.

 

Website may come in the future, if I have time...


Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralMy vote of 4memberG. Steudtel22 Mar '13 - 9:16 
well tought out,
flexible and by the look of it extensible.
Documentation is too poor for a five
GeneralMy vote of 5memberMatthew Faithfull18 Mar '13 - 22:38 
A truly excellent idea. I will probably need to ruthlessly recycle this in a few months time. Will go on my favourites list.
GeneralMy vote of 5memberFranc Morales13 Feb '13 - 20:26 
This is good work. Thank you for sharing, my friend.
GeneralMy vote of 5memberSnorri12 Feb '13 - 2:09 
Excellent work - love how operator overloading is raped to bits Smile | :)
QuestionThe article and code are very useful. [modified]memberkartalyildirim3 Mar '12 - 23:53 
The article and code are very useful.


modified 23 Mar '12 - 7:04.

QuestionMy 5memberPrafullaVedante8 Nov '11 - 22:47 
My 5
Prafulla Vedante

Questionradio_button_group() freezes in VS2008 Buildmembertbrammer3 Nov '11 - 6:40 
Great stuff Thumbs Up | :thumbsup: Thumbs Up | :thumbsup: !
But I noticed that the "Test Dialog" freezes if I click on one of the "Option C*" radio buttons.
GeneralMy vote of 5memberMember 466080521 Sep '11 - 16:36 
Excellent
SuggestionNice idea (my 5)! Concerning resizable dialogs ...memberDoc Lobster27 Jul '11 - 4:08 
... have a look at BeginDeferWindowPos(...) / DeferWindowPos(...) / EndDeferWindowPos(...). Opposite to SetWindowPos(...) these functions can be used to reposition child windows without too much flicker.
GeneralRe: Nice idea (my 5)! Concerning resizable dialogs ...memberRotted Frog29 Jul '11 - 16:05 
I'd not considered those functions, but will definitely do so when I get around to finishing the resizable support.
 
Thanks!
QuestionVery nice! Non modal support? [modified]membersupergoofy18 Jul '11 - 21:06 
Excellent work and very useful!
Looking at your code, I was trying to undestand the best way to create also non-modal dialogs or embedded sub-windows: any suggestion? Thanks!
 
Edit:
I tried by myself with this code:

template<typename _Chr, class _Layout>
class basic_unmodal_dialog : public container_operators<basic_unmodal_dialog<_Chr, _Layout> >
{
private:
std::basic_string<_Chr> _title;
typename window<_Chr, _Layout> *_wndptr;
public:
basic_unmodal_dialog()
: _wndptr(NULL)
{ }
virtual ~basic_unmodal_dialog(){
if (_wndptr)
delete _wndptr;
}
 
void show(HWND parent,RECT pos,_Layout layout = _Layout())
{
if(_wndptr)
return;
_wndptr=new window<_Chr, _Layout>(_title, parent, 0, false, container_operators<basic_unmodal_dialog<_Chr, _Layout> >::_controls, layout,true);
_wndptr->reworklayout(pos.right-pos.left);
_wndptr->show(parent,pos);
}
};

but I have some problem if I try for example to open another dialog (this time modal) from an event listener of a button:

unmodal_dialog ud;
 
ud<< (groupbox("Test")<<"Hello, World!"<<
spacer() <<
*button("Advanced",[=](abstractcontrol *wnd){
dialog d("My first dialog");
d << "Hello, World!" << spacer() << *button("OK");
d.show();
})
);
 
ud.show(GetSafeHwnd(),rcPos);

 
any suggestion? Thanks

modified on Thursday, July 21, 2011 12:00 PM

AnswerRe: Very nice! Non modal support?memberRotted Frog29 Jul '11 - 16:03 
Hi, I am sitting in a hotel room in sunny Bangkok at the moment and haven't got the code to hand, but as I recall, if you have a look at the window class you should be able to override or adapt that quite easily - the show method includes the modal dialog loop, so overriding it will allow you to use non-modal dialogs. You can use lambdas or function objects on the buttons to do any return value processing in click events.
GeneralMy vote of 5memberRadoslaw Bukowski4 Jul '11 - 9:48 
Nice idea!!!!
GeneralHmembery_boy16 Jun '11 - 16:58 
THANK YOU! Smile | :)
GeneralMy vote of 5mvpMd. Marufuzzaman15 Jun '11 - 19:56 
Excellent
GeneralMy vote of 5memberVadim Nazarenko14 Jun '11 - 19:47 
Thanks!
GeneralMy vote of 4memberdlmult14 Jun '11 - 16:48 
Yeah,it's useful.
GeneralMy vote of 5memberFebil Chacko Thanikal14 Jun '11 - 1:06 
my vote of 5
GeneralMy vote of 5 [modified]memberMizan Rahman7 Jun '11 - 21:36 
Great work Smile | :)
 
But also agree with this msg:
http://www.codeproject.com/Messages/3894775/Vote-of-5-but.aspx[^]
 
On another note, wouldn't it be simpler if your solution could take a string with HTML tags construct the dialog from the string? Just a thought.
 
Thanks for sharing.

modified on Wednesday, June 8, 2011 3:50 AM

GeneralRe: My vote of 5memberRotted Frog9 Jun '11 - 0:19 
Thanks for the vote.
 
HTML dialogs are an interesting idea, although there are a few things that make this difficult:
 
1. Need to parse the HTML. Even if we are parsing HTML snippets, this adds to the complexity significantly.
2. Difficult to customise. HTML has a well defines standard syntax, and there isn't really much scope for extending the syntax.
3. Dynamic dialogs become more difficult. You have to implement string operations in order to do custom dialogs and ensure that you close off tags correctly, and binding control return values to variables is difficult to do in any meaningful way.
4. Compile-time validation. If you get the HTML syntax wrong, you get an error at run-time. If you get the current syntax wrong, you get an error at compile-time.
 
As far as I can see, the key advantage to HTML dialogs is that you can soft-code your UI. There are already very good frameworks out there that do this using XML (Mozilla use XUL, WPF can be made to do this to some extent, and I think Qt can construct its dialogs from XML files as well). I doubt I could do one that is better.
GeneralMy vote of 5memberJonas Hammarberg31 May '11 - 1:50 
Very well done Smile | :)
GeneralUnicode supportmember_flix01_21 May '11 - 22:07 
The article and code are very useful.
 
The only big problem I experience is that when I try to compile the code with "UNICODE" and "_UNICODE" defined I get errors (VC++ 2010).
 
Another minor issue I can think of is that when the "apply_changes" event is called, not all "dialog parameters" seem to be updated (I name "dialog parameters", the variables passed to the dialog itself: checkboxes seem to work good, but radio boxes and combo boxes seem to be updated only when the dialog exits). Is there another way to "read back" the state of the dialog controls from inside the "apply_changes" callback?
 
Beside these issues, the code is very useful and I gave you 4 points.
 
Other personal modifications I made (but they're just a question of personal taste):
1) Using http://www.codeproject.com/KB/cpp/CPPCallback.aspx[http://www.codeproject.com/KB/cpp/CPPCallback.aspx]
for callbacks.
2) Adding a "t" version for all the controls. As an example:
typedef basic_button<char> button;
typedef basic_button<wchar_t> wbutton;
 
#if (defined(_UNICODE) || defined(UNICODE))
typedef basic_button<wchar_t> tbutton;
#else
typedef basic_button<char> tbutton;
#endif

3) Moving "QuickDialog.h" outside the other header files (i.e. putting all the other stuff in an internal subfolder).
GeneralRe: Unicode supportmemberRotted Frog22 May '11 - 0:19 
Thanks for the feedback. I've just posted an update which fixes the bugs in unicode, and as a thank you I've added the t typedefs as well. Smile | :) . Update should be available in a day or two.
 
I was aware of the fact that not all the parameters are updated when you hit apply changes - some of the controls update their bound variables on change, and some of them only when the dialog returns. I originally tried to make sure the bound variables where always consistently up to date, but ran in to some problems doing this with the radio button class. I haven't looked at that part of the code for a little while but I think it might be fixable using the reflected messages architecture that pushes notifications and command messages back to the controls that instantiate them. I'll have another look this week and see if I can fix it.
 
Thanks for the link to the article on delegates - I looked at a few of these when I was implementing the article, but decided against using someone else's delegate class - I tried to keep the code STL only as much as possible. For this framework there are so few callbacks and they are called so infrequently that any performance advantages of faster delegates would be unnoticeable, so I didn't consider it a major tradeoff. Also, I could guarantee that the STL and TR1 libraries would compile and work on almost any platform without me having to think about it.
GeneralRe: Unicode supportmemberRotted Frog22 May '11 - 0:23 
Oh one more thing - a way to work round the apply_changes issue is to return from the dialog when the use clicks apply and then reshow it immediately after. That will restore the values of all controls as before (if you use tabs, it won't restore the current tab though...)
GeneralRe: Unicode supportmember_flix01_24 May '11 - 2:48 
Thank you very much for all your suggestions and fixes Smile | :)
GeneralTips about LinuxmemberSharjith18 May '11 - 9:56 
First of all, your work is excellent! My vote of 5. Just because you mentioned Linux, I would like to suggest you something. If you really make up your mind and get this done on Linux, the very same code would run on Windows too. The best choice of the toolkit to use for this would be Qt. Since you are using lower level abstractions to hide the Windows API details from the user by just letting the controls to be created and manipulated by simple C++ constructs, GTK+ also would be a good choice as a platform neutral toolkit. You can easily use OpenMotif to port your existing code relatively easily than Qt or GTK+ because of the Win32 sdk used but the cross platform functionality would be lost, although that doesn't matter since you have already written this for windows; future maintenance would require an update for both codes though which won't be required in case of Qt/GTK+. Overall, the concept is very good and I would really love to see this library working as platform independant one. Smile | :)
RegardsSmile | :)
N. Sharjith

GeneralRe: Tips about LinuxmemberxComaWhitex20 May '11 - 19:50 
Well Gtk wouldn't be good due to lack of Mac OS X themeing. Also, it's a pita to get running/compiling on Windows anyways. Qt would be the best choice due to it's excellent support on Windows, Linux, Mac, Mobile, etc.
GeneralRe: Tips about LinuxmemberSharjith20 May '11 - 20:15 
Well, that really makes more sense. I couldn't address Mac issues since that's one platform I never touched. Thanks xComaWhitex.
RegardsSmile | :)
N. Sharjith

GeneralRe: Tips about LinuxmemberxComaWhitex20 May '11 - 20:17 
No problem, I use Hackintosh, and realised it :P. Plus with Gtk+ you would have to install Xorg just to even run Gtk iirc.
GeneralRe: Tips about LinuxmemberRotted Frog22 May '11 - 13:43 
Thanks for the suggestions all. I've downloaded Qt and I'm having a play. If I get round to it, I'll post a Qt version up, in addition to the windows version.
GeneralRe: Tips about LinuxmemberSharjith23 May '11 - 8:47 
Sounds promising! Any help required, I'm happy to help. Thanks...
RegardsSmile | :)
N. Sharjith

GeneralRe: Tips about LinuxmemberMember 476041922 Jun '11 - 4:11 
I wouldn't post a different version, can you not just use conditional compilation to enable a linux and windows version to be supported by the same code base? Should be possible....
GeneralRe: Tips about LinuxmemberTomas Rapkauskas23 May '11 - 3:29 
also it could be used http://www.wxwidgets.org/
library for the Mac,Linux and Windows platforms.
GeneralRe: Tips about LinuxmemberSharjith23 May '11 - 8:52 
Wx is not doubt good but for a novice getting started on Windows is a real pain. You need to build and get it up and running all by yourself. Qt on the other hand is pretty simple given the seamless integration with Visual Studio/QtCreator and the ready binaries for both MinGW and VS that's available for download from the website.
RegardsSmile | :)
N. Sharjith

GeneralRe: Tips about LinuxmemberxComaWhitex23 May '11 - 15:29 
I wouldn't touch wxWidgets with a 10 foot pole. I've personally used it and I find the api very confusing, a pita to work with, I hate pascal casing, I hate message maps, the tutorials are never updated, lack a lot of stuff that Qt already has.
GeneralExecutablememberPatrick NAVARRA18 May '11 - 2:20 
Great job !
An executable will be much appreciated !
AnswerRe: ExecutablememberRotted Frog18 May '11 - 4:05 
Hi Patrick,
 
You can just unzip the code and just compile the solution in VS2008 SP1/VS2010. If you are compiling with GCC it's a bit more work, but can be done in a single call to gcc to compile quickdialogs.cpp. (You'll need to specify header and lib paths for the standard libraries, windows libs and boost though).
 
Getting an executable up is more hassle and more prone to viri, so prefer not to try. The library is entirely header based anyway so no binaries are necessary.
GeneralQuick Dialogmembergeoyar17 May '11 - 14:48 
I have couple of questions:
1. How do I initialize controls in the Quick Dialog?
2. What about controls the programmer derived from MFC classes (e.g. CWnd, CStatic, etc.)?
3. What about control handlers? How to write my code into them? Usually there are many helper functions inside the dialog class.
 
Usually it is no problem to place controls onto dialog surface: use the resource editor, and that is it.
Problem start when you begin to add some functionality in your dialog class.
geoyar

AnswerRe: Quick DialogmemberRotted Frog18 May '11 - 1:49 
Hi geoyar,
 
1. All controls are initialised using contructors - for input controls you can pass a parameter by reference which contains the initial value of the control - look at the way checkboxes are done in the examples to see how this works. The mechanism is the same for edit boxes or any other input control.
 
2. The library is not MFC so there is no specific support for MFC classes. However it is possible to derive a new abstractcontrol implementation which wraps an MFC control. If I have time, I'll post an example up here, but I can't promise anything. However most of the basic MFC controls are already implemented here in terms of the underlying Win32 controls - e.g. CStatic is covered by paragraph and image, so unless you have particular functionality or skinning that you want to use, I'd just use the Win32 controls, rather than create extra work.
 
3. There are simple control handlers for buttons, checkboxes and radio buttons, which take functions or function objects as parameters. There are some examples in quickdialogs.cpp if you download the source code. However the event functionality is quite limited.
 

It's worth reiterating at this point that this is not a general purpose dialog framework. Its main goal is to make better static dialog boxes (i.e. more powerful message boxes) and easier on the fly dialog creation. If you want complex dialogs with complete flexibility, then best to stick to the dialog editor or other general purpose window framework. I'm using both dialog resources and quickdialogs in my code - it's a case of choose which is better for the job.
GeneralMy vote of 5memberClaudio Nicora16 May '11 - 23:12 
This is the most useful code I've found for plain Win32 (no MFC, ATL,...) in the last couple of years. Thank you so much!
RantVote of 5, but ...memberjean Davy16 May '11 - 22:23 
"a library for creating dialogs quickly and elegantly", I agree for qualifying "elegantly, I had a quick look at the code, looks fine, congratulations !
 
On the other side, there is your syntax/API learning curve, for easy dialog I don't think that there is so much time to save compared to the classic WYSIWYG editor, and for sophisticated dialog that can easily grow with many many lines of code.
Furthermore, I think that both solutions can't be mixed, am I right ?
 
Anyway, that can give ideas, congratulations again !
jean Davy
The less you do, the more you do

GeneralRe: Vote of 5, but ...memberRotted Frog17 May '11 - 3:19 
You are right, both solutions can be mixed.
 
The main use case I had in mind for this was for simple message-box style dialogs, the sort where dialog resource based items are overkill, but messagebox doesn't cut the mustard. My thought is that it works quite well for that, although you are right, there is a learning curve.
 
The second use case is for dynamic on the fly dialog construction from external parameters, where you might otherwise have to write the window by hand or construct an in memory dialog template from scratch (yuck).
 
For sophisticated dialogs, a wysiwyg approach is going to be quicker, and is certainly more flexible, but for small dialogs, I don't think this can be beaten (shameless self congratulations, I know).
JokeStrange codemembermarl16 May '11 - 21:00 
Looks good, but too much italic Smile | :)
 
<< check_box("Italic", italic)
<< check_box("Underline", italic)
<< check_box("Strikethrough", italic)
<< columnbreak()
<< radio_button("Normal", normal)
<< radio_button("Subscript", italic)
<< radio_button("Superscript", italic)))

GeneralRe: Strange codememberRotted Frog17 May '11 - 3:22 
Ooops. An excellent example of the evils of copy-paste coding. Kids - if you're reading this, don't end up like me...
GeneralMy vote of 5memberDennis Dykstra16 May '11 - 16:18 
Great job! Excellent development work and a very clear, concise explanation.
GeneralMy 5member.dan.g.16 May '11 - 13:49 
A very interesting idea. How about adding native support for loading text from resources?
.dan.g.
 
AbstractSpoon Software
abstractspoon2_at_optusnet_dot_com_dot_au

GeneralRe: My 5memberjean Davy16 May '11 - 22:05 
dialog d("My second dialog");
d << image(ico)
  << columnbreak()
  << spacer(20)
  << CString( (LPCSTR)ID_WHICH_CAME_FIRST_BLA_BLA_BLA ) //"Which came first, the chicken or the egg?"
  << sectionbreak()
jean Davy
The less you do, the more you do

GeneralMy vote of 5memberAlain Rist10 May '11 - 20:42 
Interesting and refreshing approach, go ahead Smile | :)
cheers,
AR
GeneralGreatmemberigch10 May '11 - 20:32 
Great one - but any chance to export or create wrapper for .NET?
GeneralRe: GreatmemberRotted Frog11 May '11 - 6:50 
Not for .NET unfortunately, although I was considering doing a C# one as well. Might take me a little while though...

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web04 | 2.6.130523.1 | Last Updated 23 May 2011
Article Copyright 2011 by Rotted Frog
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid