wrote in message news:ddd5b5f2-7bb3-4e34-a232-cfdebea07e41@googlegroups.com... Le samedi 29 d�cembre 2012 00:51:24 UTC+1, Randy Brukardt a �crit : >> >> I reluctantly have to agree with Dmitry. We tried to hide all of the >> warts >> of Win32 with Claw, but that mainly made a different set of warts. I >> rather >> doubt it is possible to hide everything mainly because the event-driven >> model of programming simply does not mesh that well with "classical" >> sequential code (and the same is true for object-oriented code). And it's >> pretty much impossible to completely eliminate the event-driven nature of >> a >> GUI. (That's especially true for "modeless" windows/dialogs.) >> >> If someone knows how to pull it off, that's great. But I won't believe it >> until I see it. > >AZip ( http://azip.sf.net ) and TeXCAD ( http://texcad.sf.net ) are >complete >Windows applications, both even multi-document, and you won't find any >event >message processing in their sources. >Is it an evidence for you ? >NB: the GUI framework is GWindows... GWindows is essentially the same design as Claw, so of course it requires a lot of event processing. You're right that there probably isn't any raw event messaging processing (there isn't any need for most Claw programs either), but there are still lots of events (When_handlers in Claw terminology, these are overridden routines that handle events). I was talking about events in general, not "message" processing specifically. For instance, you have to have some sort of event handler in order to respond to the selection of a menu entry. GWindows supports using access-to-subprogram routines for this, as well as the overridden routines of Claw. But clearly either of them is an event handler (not necessarily directly corresponding to a message, so they might not be "message handlers"). The only realistic exception to requiring event handlers is to use some sort of case structure. Besides being less safe (it's easy to forget to handle something required), it's also very limiting, because you can only handle specific kinds of event this way (and only ones the framework knows about). That is, you could handle menu events with a case structure (Claw provides something like this), but then you can't handle keyboard input or mouse actions or data validations or whatever. That makes it a very limiting solution, and it definitely can't be the only one. Randy.