Front page | perl.wxperl.users |
Postings from February 2013
RE: Modality and new windows
Thread Previous
|
Thread Next
From:
steveco.1959
Date:
February 18, 2013 13:59
Subject:
RE: Modality and new windows
Message ID:
6BB9DE603EE14E51A11EA9B8C49DCD5B@SACWS001
Hi Dave,
>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.
1) Usually I use Wx::Choice without autocompletion. But maybe my lists are
shorter.
Where my lists are longer I use a form like the one attached (and apologies
that it
is in Portuguese). As you see I have typed in "Anton", and it has reduced
the
list to all those with "Anton" in it. It would have worked equally well
as a control on one form with a Wx::ListCtrl below it. The advantage for
long lists
is that you can use multiple attributes to access it. This one is for
patients and I can use date-of-birth, partial (or full) name or unique
reference if I know it.
The key event I use is EVT_TEXT. (Maybe I should use EVT_CHAR? Anyone?)
http://wiki.wxwidgets.org/WxTextCtrl
Wx::Event::EVT_TEXT($patient_search_dlg,
$patient_search_dlg->{Ctl_Search_Description_Txt}, \&lookup_patient_id);
Where lookup_patient_id refreshes the controls (looking at it now, it seems
poorly named).
The issue of using Wx::ComboBox, is that you would have to dynamically
change
the options list (eg [@options]), which would mean refreshing the layout and
I guess the
list would collapse.
But I would expect that you could use EVT_TEXT with Wx::ComboPopup
> Hm. By "roll your own", are you suggesting I write a widget from scratch?
Mark, I thought there used to be a "Custom Control" example in the demo,
but I can't see it now. I remember some sort of vertical progress bar.
Do you remember seeing one? Maybe it was in one of the tutorials.
> $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 );
You can also set your own id using your own numbering system.
All the system assigned IDs are negative, so if you assign your own,
as long as they are positive, you will not clash with the system.
I use large numbers in series, eg:
my $patient_combo_id = 30000000 + $internal_reference;
Wx::Event::EVT_SOMETHING($patient_search_dlg,
$patient_search_dlg->{Ctl_Search_Description_Txt}, \&handle_patient_combo);
So that I can hide my own references in the ID.
Actually, here's a fairly self-contained piece of code:
############################################################################
#################
# attribute_exists is just an early warning of programming errors.
# Missing hash-objects are a bit invisible if you don't trap them.
Wx::Event::EVT_LIST_ITEM_SELECTED($i_frame, attribute_exists($i_frame,
"Ctl_Organ_Navigation_".$i_obs."_Lst"),
sub {
my ($i_frame2, $event) = @_;
# $gl_ID is a global hash with all the offsets.
my $i_list = $event->GetId() -
$gl_ID{data_diag_list_offset};
.
. (do stuff)
.
return ;
}
);
############################################################################
#################
Good luck,
Regards
Steve.
Thread Previous
|
Thread Next