Front page | perl.wxperl.users |
Postings from February 2013
On 02/15/13 20:59, Mark Dootson wrote: > On 15/02/2013 19:59, Dave Hayes wrote: > >> 1) Apparently Wx::ComboCtrl does not respect or use wxTE_PROCESS_TAB. >> Why? > > That's a decision of wxWidgets designers / maintainers. It seems > sensible to me as a combo box that captures tab key presses would be > quite an odd thing. Best roll your own from scratch if that is what you > want. Hm. By "roll your own", are you suggesting I write a widget from scratch? I believe I am attempting to do something like that, but my strategy is to stay with existing widgets and compose what I want from them. I think a bit of context may help. I want a TextCtrl which, when you hit TAB, finds a specific set of matches to what is already typed and presents these as selectable options to the user. The catch is that the user should be able to keep typing and narrow the selections in real time. I think the term for this is "autocompletion". Unfortunately, it's really opaque to me why when popping up a new window, it's seemingly impossible to intercept character events and/or redirect them to the parent text control after I've shown the popup. I'm thinking this idea might have been attempted before. In any case, since I'm still kind of naive to wxwidgets, it seems specious of me to try to write my own widget when I can't seem to handle the widgets that are already there. :D So, the question is, is there an existing control that will do what I want? If not, can you suggest a methodology which will? Am I missing some key idea which would make this entire struggle irrelevant? > wxComboPopup is a bit of a special case. It is implemented in wxWidgets > as a 'mix-in' - and we can't wrap that directly in wxPerl. It doesn't > inherit from anything (least of all wxEvtHandler) so above code would > never work. This explains a lot. Thanks. > As noted above, this isn't a particular issue for your ComboCtrl usage - > as you cannot attach events to the Wx::ComboPopup - which is just a thin > helper class. So I cannot give you a working example for the above > problem - you cannot attach events to a Wx::ComboPopup. Can I attach events to the underlying text control? > You want to handle the results of an EVT_CHAR in $popup in some parent > window of $popup. > > Personally I would say that you should not write code that relies on > child windows knowing what their parents are. So you ought to raise some > sort of custom commandevent in the child and handle that in the parent. So let me see if I understand this. In child widget A, I intercept EVT_CHAR and raise some custom event in A. I only specify a handler for this custom event in parentOf(A), which essentially either handles my TAB key behavior or inserts what characters are received by the event. Why can't I just redirect the EVT_CHAR to parentOf(A)? > $obj->GetParent() if you know that your direct parent is the window you > want. > > More usefully, if you want your top level parent (a frame or dialog) > my $frame = Wx::GetTopLevelParent($obj); > > If you want to get at a specific window but don't want to hang on to a > reference to it, get it by 'id'. > > my $savedid = $somewindow->GetId(); > .... > .... > .... later when $somewindow no longer in scope ... > > my $somewindow = Wx::Window::FindWindowById( $savedid ); These are very useful! Thank you, and thanks again for your help in disambiguating the toolkit usage. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< It is difficult to make things foolproof because fools are so ingenious.Thread Previous | Thread Next