On Sun, Sep 5, 2010 at 12:55, Pierre Morcello <pmorcell-cppfrance@yahoo.fr>wrote:
This is offlist. [...] The STL (written mostly by Stepanov) influenced it even more.
Yes. It's just so natural part of the standard nowadays that it's easy to forget. :) On Mon, Sep 6, 2010 at 02:15, Gottlob Frege <gottlobfrege@gmail.com> wrote:
On Sat, Sep 4, 2010 at 8:40 AM, Yakov Galka <ybungalobill@gmail.com> wrote:
Can you give me a real world example where you need the "capturing" phase for any reason other than a hack for some other design problem? I just can't think of any. Thank you.
http://www.adobe.com/devnet/actionscript/articles/event_handling_as3_03.html
- Global Shortcuts (like in Visual Studio)
This one is wrong! Let me describe in detail how I see the process of handling keyboard shortcut, commands (button clicks), etc..: 1) The event is sent to the focused window (e.g. a control in my XYZ document viewer). 2) Every event handler marks explicitly if it handles the event or not. 3) If the event is handled, no more processing is done (e.g. the control is a 'find' textbox, I pressed Ctrl+Left Arrow to move the cursor one word left). 4) Otherwise the event is passed to the parent (e.g. the control is a 'case-sensitive' checkbox). 5) The parent processes the shortcut key for 'Previous chapter'. If the user intends to execute 'Previous chapter' command but 3 happens, she must transfer the focus to the parent manually. That's the desired behavior! The point is that the implementer of the parent can't know if someone in the future will add a grand-grandchild that wants this event. If you implement the shortcuts with parent processing first, then you make it *impossible* for the user to use child's shortcuts. Of course, the problem is in 1. That is in a given system (e.g. Windows) there is no general way to check if the control processed the message or not. That's why you need hacks, and that's why I want a portable GUI library to do as much as possible towards implementing this behavior.
- Macro recording, both the start/stop shortcuts, and the recording of inputs - Automation
I guess these are done on a higher level than just capturing the input. I can't analyze these without a broader look on the implementation. I don't have experience with implemented these in any project.
- hacks - unknowns
For a framework, hacks and unknowns are valid reasons.
Agree. But hacks should remain hacks. I mean you shouldn't make your design less elegant because you want to make hacks easier to implement. Even if the 'unknowns' aren't hacks (as you've already mentioned + see below), the library should make the common case implicit.
[...]
I know that any framework that did child first ended up needing a parent-first hack, and anything that was parent-first needed child-first sometimes. Unfortunately I can't remember the particular reasons, but it seemed to always happen.
Unfortunately I can't remember either :). But I can think of two more cases when you need parent-first: - "Subclassing" without really subclassing. - Implementing some "key" indicator in the parent (e.g. handle Caps Lock). Best regards, Yakov Galka