John Torjo wrote:
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.
That is true, but there is the ability to create properties and event handlers before the program is running in a visual design time environment. That is why I believe one needs reflection in C++ in order to do this. While you are right that the design time environment is able to write code in files in order to create the handler, which the programmer will then fill in himself with whatever functionality he chooses, there is more to it. The design time environment must also hook the event handler to the event when the objects encapsulating the event and the event handler are created at run-time. In C++ Builder this is done by actually writing strings to a resource file, which afterward gets read in at run-time and, through reflection implemented as an extension to C++, the event handler and the event source are hooked together. In .NET, whose inner workings I understand less, I am pretty sure the same technique is being used but with .NET attributes holding special information which then works at run-time to hook handlers to events via delegation. Delegation is built into the .NET run-time as is reflection. Without run-time reflection in .NET I doubt this can be done, but I could be wrong. I know much can be done through boilerplate code, so it is possible that all the code to do this could be done by a design-time environment which creates enough code to make this automatically work at run-time. But even in this latter case, I think that run-time reflection makes a much cleaner environment in which to bridge the gap between a design-time/run-time environment than does boilerplate code.
Now, you can easily set event handlers at compile time. It'll get even better (look out for CUJ November issue ;)).
I understand this possibility and applaud your work, but it still is not design time programming ( yet ).
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.
See above. Perhaps the wizard can produce the correct code without reflection, as you hope to prove. I look forward to seeing how you get it done via templates.
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.).
I heavily disagree with this model. That's MFC/OWL and I would guess plenty of other GUI environments, and it is old. There is no reason why any component shouldn't be able to hook events.
This is how win32gui handles events right now.
And I think this is how C++ Builder/.net handles events as well.
You are completely wrong on this last point. Any C++ Builder component can hook an event ( called a __closure ). Any .NET component can hook an event ( called a delegate ). I am not trying to put down what seems to be your excellent work in any way, but you are conceptually following a model for event generation/event handling which has been superceded IMHO. If you like that model, fine. But I want to point out to you that a much better model, and much more in the spirit of C++, is to allow any functor to handle an event. And of course boost::signal<> is built around this idea. If your events are multi-casting, which I am sure they must be, there is no reason putting limitations on who can handle them unless you are using a means of event generation which is in itself restrictive in what it can do. All you end up doing is making programmers who want to use your GUI angry that they must find workarounds for event handling for many cases for which you haven't yet conceived.
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.
Sounds great ! I look forward to reading more about it.
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.
Good luck !