|
|
Comments and Discussions
|
|
 |

|
well tought out,
flexible and by the look of it extensible.
Documentation is too poor for a five
|
|
|
|

|
A truly excellent idea. I will probably need to ruthlessly recycle this in a few months time. Will go on my favourites list.
|
|
|
|

|
This is good work. Thank you for sharing, my friend.
|
|
|
|

|
Excellent work - love how operator overloading is raped to bits
|
|
|
|

|
The article and code are very useful.
modified 23 Mar '12 - 7:04.
|
|
|
|
|
|
|

|
... have a look at BeginDeferWindowPos(...) / DeferWindowPos(...) / EndDeferWindowPos(...). Opposite to SetWindowPos(...) these functions can be used to reposition child windows without too much flicker.
|
|
|
|

|
I'd not considered those functions, but will definitely do so when I get around to finishing the resizable support.
Thanks!
|
|
|
|

|
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
|
|
|
|

|
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.
|
|
|
|
|

|
THANK YOU!
|
|
|
|
|
|
|
|

|
Great work
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
|
|
|
|

|
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.
|
|
|
|

|
Very well done
|
|
|
|

|
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).
|
|
|
|

|
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. . 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.
|
|
|
|

|
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...)
|
|
|
|

|
Thank you very much for all your suggestions and fixes
|
|
|
|

|
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.
Regards
N. Sharjith
|
|
|
|

|
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.
|
|
|
|

|
Well, that really makes more sense. I couldn't address Mac issues since that's one platform I never touched. Thanks xComaWhitex.
Regards
N. Sharjith
|
|
|
|

|
No problem, I use Hackintosh, and realised it :P. Plus with Gtk+ you would have to install Xorg just to even run Gtk iirc.
|
|
|
|

|
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.
|
|
|
|

|
Sounds promising! Any help required, I'm happy to help. Thanks...
Regards
N. Sharjith
|
|
|
|

|
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....
|
|
|
|
|

|
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.
Regards
N. Sharjith
|
|
|
|

|
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.
|
|
|
|

|
Great job !
An executable will be much appreciated !
|
|
|
|

|
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.
|
|
|
|

|
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
|
|
|
|

|
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.
|
|
|
|

|
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!
|
|
|
|

|
"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
|
|
|
|

|
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).
|
|
|
|

|
Looks good, but too much italic
<< 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)))
|
|
|
|

|
Ooops. An excellent example of the evils of copy-paste coding. Kids - if you're reading this, don't end up like me...
|
|
|
|

|
Great job! Excellent development work and a very clear, concise explanation.
|
|
|
|

|
A very interesting idea. How about adding native support for loading text from resources?
|
|
|
|

|
dialog d("My second dialog");
d << image(ico)
<< columnbreak()
<< spacer(20)
<< CString( (LPCSTR)ID_WHICH_CAME_FIRST_BLA_BLA_BLA ) << sectionbreak()
jean Davy
The less you do, the more you do
|
|
|
|

|
Interesting and refreshing approach, go ahead
cheers,
AR
|
|
|
|

|
Great one - but any chance to export or create wrapper for .NET?
|
|
|
|

|
Not for .NET unfortunately, although I was considering doing a C# one as well. Might take me a little while though...
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
|
A library for creating simple dialogs declaratively with minimal overhead.
| Type | Article |
| Licence | CPOL |
| First Posted | 10 May 2011 |
| Views | 29,890 |
| Downloads | 1,565 |
| Bookmarked | 110 times |
|
|