Boost logo

Boost :

From: John Torjo (john.lists_at_[hidden])
Date: 2004-08-23 03:02:17

Edward Diener wrote:
> John Torjo wrote:
>>>Borland's C++ Builder was very nice, but of course it wasn't
>>>standard C++.
>>>VC++ Managed C++ .NET is very nice but it is even further away from
>>>standard C++. In neither do you have to write hundreds of lines of
>>>code to do any GUI programming of significance. In order to have a
>>>really top-rate C++ GUI library I believe one needs reflection in
>>>C++ in order to do the sort of
>>Not true. It would be great if you had reflection, but it's not a
>>I'll show you (in about 3-4 months) that you don't need reflection to
>>set GUI properties at design time. It'll be just like VB, but only
>>better ;)
> I am very interested in this and would like very much to see how you will do
> this at design time. In particular I am interested in how event handlers can
> be set at design time. All without C++ reflection of course and using
> strictly the C++ standard, since you are confident that this can be done. My

You can emulate "design time". This is what both C++ Builder/ .Net do.
You set an event at design time, but behind the scenes, a new event
handler is created.

Now, you can easily set event handlers at compile time. It'll get even
better (look out for CUJ November issue ;)).

Having said that, you only need to come up with a wizard that
understands what events can be generated for a dialog, and make sure you
can edit them. Not very complex, especially knowing how easily you can
parse a C++ file for win32gui events.

> view of event handlers is that any "component" ( see below ) within such a
> system should be capable of handling any event generated by any other
> component; which is true of both C++ Builder and Managed C++/.NET.

I don't think you'd want any component to catch events generated by any
other component.
What I think you'd like is: handle on a dialog, any notification coming
from its controls. If the dialog does not/cannot handle this
notification, propagate it up the chain (dialog's parent, grand parent,

This is how win32gui handles events right now.

And I think this is how C++ Builder/.net handles events as well.

>>>easy RAD programming which C++ Builder and Managed C++ .NET provide.
>>>Needless to say, both use extensions to C++ to do reflection. This
>>>is not a knock on any of the GUI libraries mentioned, but after
>>>using C++ Builder and Managed C++ .NET, even despite their
>>>non-C++-isms, most C++ GUI libraries are very primitive by contrast.
>>I donot understand what you mean by the last sentence.
> In the sense that one has to do work at run-time when it could be done at
> design time. Please notice I said 'most', not all. If you, or anyone else,
> could come up with a RAD C++ GUI development environment which works with
> 98%+ conforming C++ compilers ( Como, gcc, VC++ 7.1, Intel etc. ) and

So far win32gui works for como, gcc, vc71.
I intend to port it to other *modern* compilers as I have the time. But
I think this will be most likely 3-5 months from now.

> enables one to easily set properties and events at design time, ala C++
> Builder and Managed C++/.NET, I would be very interested in it and would
> contribute to it any way that I can if I liked the design. By GUI I also
> means the sort of components ( properties and events along with traditional
> C++ method-based programming ) which are supported by C++ Builder and
> Managed C++. I think non-visual components are also very important and

It'll be possible. Also - I plan to allow it 3-4 months from now.


John Torjo
-- john_at_[hidden]
Contributing editor, C/C++ Users Journal
-- "Win32 GUI Generics" -- generics & GUI do mix, after all
-- v1.3beta released - check out splitter/simple_viewer,
    a File Explorer/Viewer all in about 200 lines of code!
Professional Logging Solution for FREE
-- (logging           - C++)
--         (viewing/filtering - Win32)
--        (debugging         - Win32)

Boost list run by bdawes at, gregod at, cpdaniel at, john at