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

> A> It's particular to wxKeyEvent, so maybe a name like:
> A>
> A>   AllowNextKeyEvent(bool do_allow)
>
>  The "not allow" is the default, is it really useful to be able to do this
> explicitly? It's not difficult to implement this, of course, but by keeping
> the API as simple as possible we minimize the potential for confusing
> people.

The flag is not needed, provided that both of EVT_CHAR_HOOK-and EVT_KEY_DOWN
defaults to _not_ sending the next event if processed.

But... we have overseen something:

EVT_CHAR_HOOK is sent directly to the TLW parent of the focus window.
So even introducing a new method AllowNextKeyEvent(), wxDialogCmn
still has to take the decision of allowing / skipping the next key
event. And it needs some method to decide that. (what I proposed
earlier are such methods).

The alternative is to send the EVT_CHAR_HOOK message to the focused
window instead of the TLW parent.

In these cases, WXK_ESCAPE is consumed by wxListCtrl or wxTreeCtrl.
wxTextCtrl alone cannot determine if it's a popup edit (do allow next
key event) or a plain edit (suppress it). It is really the list or tree
control that is in position to decide this.  

This would make the change a bit bigger.


> A> Could be that native MSW list view control overrides it?
>
>  Looks doubtful but everything is possible, of course. In any case, if
> you're interested in this, please reproduce the bug in the listctrl sample
> and then I'll try to look at it.
>

I found that wxListCtrl::EndLabelEdit() is not an API function. On my
system it clearly doesn't close the popup edit. MSoft may very well
change the processing of an WIN32 message from version to version.
The behavior of an API function like ::DestroyWindow() is fix though.

Not being an API function it doesn't matter much to me.


Regards
// ATS

>  Regards,
> VZ
>





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