« Return to Thread: Continued: Popup edit in a dialog

Re: Re[2]: Continued: Popup edit in a dialog

by ats :: Rate this Message:

> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-unsubscribe@...
For additional commands, e-mail: wx-users-help@...

« Return to Thread: Continued: Popup edit in a dialog