Continued: Popup edit in a dialog

[ATS]

> A> > possible to specify what should happen next but I'm not especially
> A> > about it...
> A> 
> A> The situation is not so common, so maybe better to fix at wxDialog level. 
> 
>  I think I disagree. It's maybe not common but it's not specific to
> wxDialog at all and could equally well happen in any other situation. E.g.
> imagine a frame which uses this event to get F1 key presses inside it
> (presumably to show some kind of help) and some window which wants to
> handle F1 specially.

I should have written wxTopLevelWindowCmn instead of wxDialogCmn. My 
thoughts were concerned with dialogs closing when using popup edits, 
and I believe that can be fixed rather well with algo A. And it would 
extend to non modal dialogs as well. That was my perspective.


> A> > A> A 3rd alternative would bo useful: 
> A> > A> 3 - Stop processing EVT_CHAR_HOOK but give the key event to 
> A> > A> the control that has the focus. 
> A> > 
> A> >  Yes, definitely. The question is what would be the best API for it?
> A> 

OK, I see you're looking at the more general thing of event propagation. 
That's fine, but more general than the problem I was working with. 


> A> Thoughts? 
> 
>  I still don't see anything better than allowing the EVT_CHAR_HOOK handler
> to indicate whether it wants the key event to be generated or not. I.e. add
> wxKeyEvent::AllowNextEvent() which would set some internal flag to true (it
> would be false by default for compatibility). The strange name is due to
> the fact that I think this would be also useful for EVT_KEY_DOWN handlers:
> currently you have no choice about getting (or not) EVT_CHAR: if you skip
> the event, you get, otherwise you don't (at least this is the way I believe
> it works, I didn't test it). AllowNextEvent() could be helpful here if you
> didn't want to skip the event (to prevent the base class event handler from
> doing something with the key) but still wanted to get EVT_CHAR for it.

It's particular to wxKeyEvent, so maybe a name like: 

  AllowNextKeyEvent(bool do_allow) 

One could manipulate a 3 state flag: Default/Disable/Enable. In that way
the handler could decide precisely what should happen and there'd be 
default compatibility with old mode. 

One would have to reset the flag before calling EVT_KEY_DOWN. 


>  This is simple to implement for all of wxMSW, wxGTK and wxMac (the code
> for the last 2 is similar as EVT_CHAR_HOOK is generated by wx code) and I
> don't really see anything wrong with doing it like this, do you?

I think it's OK. It's a nice generic approach. 


> A> > A>   wxListCtrl::EndEditlabel( )
> A> > A> 
> A> > A> However... that function is broken on MSW.
> A> > 
> A> >  Hmm, it worked for me the last time I tested, did you test it 
> A> > your application?
> A> 
> A> No. But calling ::DestroyWindow( HWND hwnd ) with the handle from the 
> A> popup text ctrl solved the matter. 

Could be that native MSW list view control overrides it? It could 
change as MSoft ships different versions of these common control 
DLL:s. 


Regards
// ATS.