
Edward Diener wrote:
John Torjo wrote:
.
Borland's C++ Builder was very nice, but of course it wasn't standard C++.
True.
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 necessity.
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, etc.). 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. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)