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

On Wed, 12 Mar 2008 14:51:56 +0000 (UTC) ATS <asteinarson@...> wrote:

A> EVT_CHAR_HOOK is sent directly to the TLW parent of the focus window.
A> So even introducing a new method AllowNextKeyEvent(), wxDialogCmn
A> still has to take the decision of allowing / skipping the next key
A> event.

 I thought that you would handle EVT_CHAR_HOOK yourself in your TLW and
decide whether Esc needs to be ignored or not by checking m_listctrl->
GetEditControl() != NULL.

 But it's true that it would be even better if it could be done
automatically. And for this we indeed need to ask the focused window (and
its parents) if it needs to intercept the key event even before
EVT_CHAR_HOOK.

A> And it needs some method to decide that. (what I proposed
A> earlier are such methods).

 Yes, I didn't like them because they were too specific but something
generic along the same lines (e.g. a virtual NeedsKey() method) could do
it.

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

 Hmm, this should work if we set m_propagationLevel to wxEVENT_PROPAGATE_MAX
for EVT_CHAR_HOOK events (otherwise the event would never get to the TLW as
it's not a command event and hence not propagated by default).

A> > A> Could be that native MSW list view control overrides it?
A> >
A> >  Looks doubtful but everything is possible, of course. In any case, if
A> > you're interested in this, please reproduce the bug in the listctrl sample
A> > and then I'll try to look at it.
A>
A> I found that wxListCtrl::EndLabelEdit() is not an API function. On my
A> system it clearly doesn't close the popup edit.

 Again, do you mean that it fails to work in the sample too? Sorry for
asking again but this is still not clear to me. Also, what exactly is your
system?

A> MSoft may very well change the processing of an WIN32 message from
A> version to version. The behavior of an API function like
A> ::DestroyWindow() is fix though.

 I really don't think there is a lot of difference between the 2 cases.

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

 It's certainly part of wx API so it would be nice if it worked... As the
comment there says, normally sending WM_CANCELMODE should do the trick but
it didn't do it for me. Maybe you should try changing the code to do it.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/


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