wxperl-users — For wxPerl users

RE: [wxperl-users] Wx::ComboBox::SetValue ineffective when wxCB_R EADONLY is set

[Everett, T. <TEv...@AL...>]

-----Original Message-----
From:	Mattia Barbon [mailto:mb...@ds...]
Sent:	Friday, September 06, 2002 8:38 AM
To:	Everett, Toby
Cc:	wxp...@li...
Subject:	Re: [wxperl-users] Wx::ComboBox::SetValue ineffective when
wxCB_READONLY is set

> If this is under wxMSW, it is a known bug; I can reproduce it
> with CVS wxWindows 2.3.3 under Windows; wxGTK (and I assume wxMOTIF),
> seem to work fine. I am going to commit a fix for this in wxWindows;
> this should be in 2.3.3 release.
MSW = Microsoft Windows, right?  BTW, where is the best place to search for
known bugs?

> > insufficiently grateful, wxPerl does really rock!  I'm still stumbling
my
> Well, if reporting bugs (with testcases)
> is being ungrateful, I want more ungrateful people ;-)
It's a deal:)

> > way through the darkness, but I'm making reasonably good progress in
doing
> > my first test port of a Tk app.  There are definitely some Tk things I
miss
> > (-textvariable, for one:), but I will say the native look and feel is
>    ^^^^^^^^^^^^^
> Curious: what does it do?
It hooks a variable to the value of a widget.  You pass it a reference to a
scalar, like so:
<create_new_widget> . . . -textvariable => \$myvar . . .
Then, whenever you update $myvar, the value in the equivalent of a TextCtrl
or whatever changes.  Similarly, when you change the value in the widget
interactively, the value in $myvar changes.  I'm not quite sure how it's
done internally.  A widget->variable equivalent can be done like so:

EVT_TEXT($self, $_, sub {
  my($self, $event) = @_;
  $myvar = $widget->GetValue();
});

Here's another approach.  This relies upon Stephen Lidie's Tie::Watch.

===== Wx/TiedVariable.pm BEGIN =====
package Wx::TiedVariable;

use Tie::Watch;

sub Set {
  my($self, $ref) = @_;

  ref($ref) eq 'SCALAR' or die "Usage: Wx::TiedVariable::Set(\$widget,
\\\$scalar).";

  $self->SetValue($$ref);

  my $watch = $self->{"\0TIEWATCH"} = Tie::Watch->new(
    -variable => $ref,
    -fetch => sub {$self->GetValue()},
    -store => sub {$self->SetValue($_[1])},
  );
}

1;
====== Wx/TiedVariable.pm END ======

===== demo.pl BEGIN =====
use strict;

package MyFrame;
use Wx qw(:everything);
use Wx::Event qw(EVT_BUTTON);
use Wx::TiedVariable;

use vars qw(@ISA);
@ISA=qw(Wx::Frame);

sub new {
  my $class = shift;
  my $self = $class->SUPER::new(undef, -1, $0, [-1,-1], [-1,-1]);

  my $wx = $self->{wx} = {};

  $wx->{pnl} = Wx::Panel->new($self, -1);
  $wx->{szr} = $_ = Wx::BoxSizer->new(wxVERTICAL);
  $wx->{pnl}->SetSizer($_);
  $wx->{pnl}->SetAutoLayout(1);

  my $value = "foobar";

  $wx->{txtDemo} = $_ = Wx::TextCtrl->new($wx->{pnl}, -1, '', [-1,-1],
[-1,-1]);
  $wx->{szr}->Add($_, 0, wxALIGN_LEFT|wxALL, 5);
  Wx::TiedVariable::Set($_, \$value);

  $wx->{butEdit} = $_ = Wx::Button->new($wx->{pnl}, -1, "Edit");
  $wx->{szr}->Add($_, 0, wxALIGN_CENTRE|wxALL, 5);
  EVT_BUTTON($self, $_, sub {
    my($self, $event) = @_;
    $value = Wx::GetTextFromUser("Edit the value of \$value:", 'Value',
$value, $self);
  });


  $wx->{szr}->Fit($self);
  return $self;
}

package MyApp;
use Wx;

use vars qw(@ISA);
@ISA=qw(Wx::App);

sub OnInit {
  my $self = shift;

  my $frame = MyFrame->new();
  $self->SetTopWindow($frame);
  $frame->Show(1);
}

package main;
(my $app = MyApp->new())->MainLoop();
====== demo.pl END ======

Note that the calling syntax is Wx::TiedVariable::Set($widget, $$ref).  This
is intentional, because it would allow Set to be hooked into the Wx::
hierarchy at the right point using something akin to
*Wx::RightHierarchyPoint::SetTiedVariable = \&Wx::TiedVariable::Set;  Then
you could just use $widget->SetTiedVariable(\$value);  I just didn't know at
what point in the hierarchy GetValue and SetValue became active.

--Toby Everett

Re: [wxperl-users] scalar reference objects?

[Mattia B. <mb...@ds...>]

> On Thu, 5 Sep 2002, Mattia Barbon wrote:
> > (BTW subclassing wxMenuBar is unusual, why do you need it?
> > just curious);
> 
> I just did it to separate the menubar code in its own module.
> For example, to do a minimal application with a menubar to
> trigger a dialog, I would have 1) a main script, 2) MyApp.pm,
> 3) MyFrame.pm, 4) MyMenuBar.pm, 5) MyDialog.pm, 6) MyPanel.pm,
> with Frame the parent of MenuBar and Dialog, and Dialog the
> parent of Panel. Maybe it's a little awkward if I have a dialog
> triggered by a menu event, though, because the dialog has the
> Frame for its parent and I end up doing things like this from
> the MenuBar subclass
> 
>     no strict 'refs';
>     EVT_MENU($parent, '...', \&{ref($parent) . 'OnMenuDialog'});
$parent->can( 'OnMenuDialog' ) looks cleaner to me, BTW

>     (so MyFrame isn't hardcoded, though still we have OnMenuDialog
>      hardcoded..)
> 
> to pass it back to the Frame class anyway. So maybe this is
> why it's unusual to subclass MenuBar.
Exactly, basically, once you start putting data in the menubar,
you realize that it would be much easier to put it in the frame
directly.

>     Anyway, MenuBar is not the only scalar class I tried to
> subclass. I also tried some dialogs like TextEntryDialog
> and SingleChoiceDialog. You might again say it's unusual
> to subclass these, as they are small and specific, but I like
> to treat all the dialog as objects when I do something like
> 
>     $d = MyDialog->new();
>     $d->Destroy();
> 
> then inside of MyDialog I did something like (it's from memory,
> hopefully you get the idea though)
> 
>     sub new {
>         ...
> 
>         if ($self->ShowModal() == wxOK) {
>             $self->{textfield} = $self->GetStringSelection();
>             ...
>         }
>         return $self;
>     }
> 
> Basically I mean I treat the Dialog as an object which had some
> attributes set by the user (as a CGI programmer, I think of the
> form submit button and $q->param() to get the CGI form values),
> then I use $d from above like
> 
>     if ($d->{textfield} =~ /whatever.../) {
>         ....
>     }
> 
> and so on. (Really I use Class::Accessor::Fast and Class::Fields
> modules to do easy AUTOLOAD of private and public attributes,
> so instead of $self->{textfield} = ... I have $self->textfield(...)
> and access simply with $self->textfield - so from the perspective
> the dialog parent it seems as if $d->textfield is an accessor
> method of an object.)

Well, de gustibus disputandum non est...

> > I can move wxMenuBar (or any other class) to subclassable (or
> > to not subclassable) it just requires some small work.
> 
> Speaking of this.. what is the trick?
> 
> I'm trying to understand what makes the objects be
> either a HASH or SCALAR reference. I grepped for 'bless'
> in the source code, and I think the only relevant case is
> function wxPli_make_object in ./cpp/helpers.cpp.
> It creates a new HASH, but how is a SCALAR object created?
it is never created, see below.

> I looked at XS/Menu.xs for MenuBar which is a SCALAR,
> and its `new' is barebones, just translates the C++ directly.
> On the other hand, XS/Frame.xs, XS/TreeCtrl.xs, XS/Panel.xs,
> those have RETVAL = new wxPliSOMETHING where SOMETHING is Frame,
> TreeCtrl, Panel, etc. I search around a little -- panel.h,
> helpers.h -- find these WXPLI_DEFAULT_CONSTRUCTOR and so on
> all call wxPli_make_object. Aha. But still, what about the
> SCALAR ones?
> 
> There is a comment in cpp/helpers.cpp of the wxPli_sv_2_object
> function in wxHashModule class that says "get 'this' pointer
> from a blessed scalar/hash reference". I grepped wxPli_sv_2_object
> and found it in ./typemap, but it was in the INPUT section. In the
> TYPEMAP section, I found both wxMenuBar and wxFrame are O_WXOBJECT,
> and in the OUTPUT section, O_WXOBJECT uses wxPli_object_2_sv.
> It's hurting my mind now.
:-)

create a class like this (this is for wxListCtrl):
class wxPliListCtrl:public wxListCtrl
{
    WXPLI_DECLARE_DYNAMIC_CLASS( wxPliListCtrl );
    WXPLI_DECLARE_SELFREF();
public:
    WXPLI_DEFAULT_CONSTRUCTOR( wxPliListCtrl, "Wx::ListCtrl", TRUE );
    WXPLI_CONSTRUCTOR_7( wxPliListCtrl, "Wx::ListCtrl", TRUE,
                         wxWindow*, wxWindowID, const wxPoint&,
                         const wxSize&, long, const wxValidator&,
                         const wxString& );
};

For wxMenuBar (which hasn't a default ctor, just 1-arg and 3-arg ones),
you should use CONSTRUCTOR_1 and CONSTRUCTOR_3 (they should be added
to helpers.h, it's a matter of cut'n'paste'n'modify. There are handy
macros (WXPLI_DECLARE_CLASS_X) that do this in the case of a
default ctor + X-args ctor, BTW.

Now, why does this work?
WXPLI_CONSTRUCTOR_X calls wxPli_make_object (create the hashref) and
stores it in the m_self attribute of the class (declared by
WXPLI_DECLARE_SELFREF() or WXPLI_DECLARE_V_CBACK()); in addition
WXPLI_DECLARE_DYNAMIC_CLASS( wxPliListCtrl ); adds the class information
for this class to the RTTI system used by wxWindows.

Now, when wxPli_object_2_sv comes to decide how to convert
the wxObject to a Perl-thing, it gets the RTTI class information
and sees that the class name starts with wxPl, it assumes it is
a wxPerl thing, and uses the additional information stored in
the wxPliClassInfo object to locate the m_self memeber, get the
hashref stored here, and return it. If that fails, it uses
sv_setref_pv to create a new SCALAR reference and returns it.

If you post a list of classes that you need to be HASH-ified,
I think I could do that for 0.12 .

Regards
Mattia

[wxperl-users] Behaviour change for 0.15

[Mattia B. <mb...@ds...>]

[ convention: MyFoo derives from Wx::Foo,
  e.g. MyFrame derives from Wx::Frame ]

Until now calling Wx::Button->new and MyButton->new
returned an HASH refence, so it was possible to use code like this:

my $b = Wx::Button->new( ... );
$b->{foo} = 1; $b->{BAR} = 2;
...

I'd like to deprecate that feature and have
Wx::Button->new( ... ) return a scalar reference,
while MyButton->new( ... ) will still return an
hash refernce; this will help saving some memory,
and is something that I wanted to do since some time,
but I always got more important things to do...

The plan is that there will be a
Wx::_work_as_before( bool ) function to preserve the
current behaviour; until 0.15 this function
will be on by default (but can be switched off),
starting from 0.16 it will be off by default
(but can be switched on).

Comments?
Mattia

Re: [wxperl-users] encoding of a wxTextCtrl (or the application)

[Mattia B. <mb...@ds...>]

> hello,
> is it possible to get the encoding of a textctrl or the current encoding=
?
> I think the encoding of a wxTextCtrl is 
> wxFONTENCODING_DEFAULT gives me 0
> wxFONTENCODING_SYSTEM gives me -1
The encoding used by wxTextCtrl is _SYSTEM

> but i'm pretty shure my stuff should have wxFONTENCODING_ISO8859_1 becau=
se
> i'm
> from switzerland and my textctrls shows me =E4, =F6 and =FC.
> 
> but i don't know how this things work...
Neither do I, but my guess is that _DEFAULT and _SYSTEM are placeholders,
i.e. using (say) _SYSTEM means that ISO-8859-1 is used (in your case).
I don't know how to determine which encoding _SYSTEM maps to, though.

Regards
Mattia

Re: [wxperl-users] Wx::ComboBox::SetValue ineffective when wxCB_READONLY is set

[Mattia B. <mb...@ds...>]

> It appears that both the value parameter in the constructor and
> Wx::ComboBox::SetValue are ineffective when wxCB_READONLY is set.
> Wx::ComboBox::SetSelection continues to work.
If this is under wxMSW, it is a known bug; I can reproduce it
with CVS wxWindows 2.3.3 under Windows; wxGTK (and I assume wxMOTIF),
seem to work fine. I am going to commit a fix for this in wxWindows;
this should be in 2.3.3 release.

> The documentation for wxComboBox::SetValue states:
> "NB: For a combobox with wxCB_READONLY style the string must be in the
> combobox choices list, otherwise the call to SetValue() is ignored."
> 
> The appended code should suffice to demonstrate.  And, in case I seem
Thanks!

> insufficiently grateful, wxPerl does really rock!  I'm still stumbling my
Well, if reporting bugs (with testcases)
is being ungrateful, I want more ungrateful people ;-)

> way through the darkness, but I'm making reasonably good progress in doing
> my first test port of a Tk app.  There are definitely some Tk things I miss
> (-textvariable, for one:), but I will say the native look and feel is
   ^^^^^^^^^^^^^
Curious: what does it do?

> greatly appreciated.

Thanks for the test case!
Mattia

[wxperl-users] encoding of a wxTextCtrl (or the application)

[<so...@bl...>]

hello,
is it possible to get the encoding of a textctrl or the current encoding?=


wxFONTENCODING_DEFAULT gives me 0
wxFONTENCODING_SYSTEM gives me -1

but i'm pretty shure my stuff should have wxFONTENCODING_ISO8859_1 becaus=
e
i'm
from switzerland and my textctrls shows me =E4, =F6 and =FC.

but i don't know how this things work...

greeting
Marco

Re: [wxperl-users] pardon my ignorance, wxNO_BORDER will remove the border if it can

[Scott L. <sla...@th...>]

On Wed, 4 Sep 2002, DH wrote:
> This is to whomever asked about a TextCtrl without a border
>
> pardon my ignorance, wxNO_BORDER will remove the border
> ( at least on windoze)

I tried on Linux, but no dice.
Thanks anyway, though.

Re: [wxperl-users] scalar reference objects?

[Scott L. <sla...@th...>]

On Thu, 5 Sep 2002, Mattia Barbon wrote:
> (BTW subclassing wxMenuBar is unusual, why do you need it?
> just curious);

I just did it to separate the menubar code in its own module.
For example, to do a minimal application with a menubar to
trigger a dialog, I would have 1) a main script, 2) MyApp.pm,
3) MyFrame.pm, 4) MyMenuBar.pm, 5) MyDialog.pm, 6) MyPanel.pm,
with Frame the parent of MenuBar and Dialog, and Dialog the
parent of Panel. Maybe it's a little awkward if I have a dialog
triggered by a menu event, though, because the dialog has the
Frame for its parent and I end up doing things like this from
the MenuBar subclass

    no strict 'refs';
    EVT_MENU($parent, '...', \&{ref($parent) . 'OnMenuDialog'});

    (so MyFrame isn't hardcoded, though still we have OnMenuDialog
     hardcoded..)

to pass it back to the Frame class anyway. So maybe this is
why it's unusual to subclass MenuBar.
    Anyway, MenuBar is not the only scalar class I tried to
subclass. I also tried some dialogs like TextEntryDialog
and SingleChoiceDialog. You might again say it's unusual
to subclass these, as they are small and specific, but I like
to treat all the dialog as objects when I do something like

    $d = MyDialog->new();
    $d->Destroy();

then inside of MyDialog I did something like (it's from memory,
hopefully you get the idea though)

    sub new {
        ...

        if ($self->ShowModal() == wxOK) {
            $self->{textfield} = $self->GetStringSelection();
            ...
        }
        return $self;
    }

Basically I mean I treat the Dialog as an object which had some
attributes set by the user (as a CGI programmer, I think of the
form submit button and $q->param() to get the CGI form values),
then I use $d from above like

    if ($d->{textfield} =~ /whatever.../) {
        ....
    }

and so on. (Really I use Class::Accessor::Fast and Class::Fields
modules to do easy AUTOLOAD of private and public attributes,
so instead of $self->{textfield} = ... I have $self->textfield(...)
and access simply with $self->textfield - so from the perspective
the dialog parent it seems as if $d->textfield is an accessor
method of an object.)


> I can move wxMenuBar (or any other class) to subclassable (or
> to not subclassable) it just requires some small work.

Speaking of this.. what is the trick?

I'm trying to understand what makes the objects be
either a HASH or SCALAR reference. I grepped for 'bless'
in the source code, and I think the only relevant case is
function wxPli_make_object in ./cpp/helpers.cpp.
It creates a new HASH, but how is a SCALAR object created?

I looked at XS/Menu.xs for MenuBar which is a SCALAR,
and its `new' is barebones, just translates the C++ directly.
On the other hand, XS/Frame.xs, XS/TreeCtrl.xs, XS/Panel.xs,
those have RETVAL = new wxPliSOMETHING where SOMETHING is Frame,
TreeCtrl, Panel, etc. I search around a little -- panel.h,
helpers.h -- find these WXPLI_DEFAULT_CONSTRUCTOR and so on
all call wxPli_make_object. Aha. But still, what about the
SCALAR ones?

There is a comment in cpp/helpers.cpp of the wxPli_sv_2_object
function in wxHashModule class that says "get 'this' pointer
from a blessed scalar/hash reference". I grepped wxPli_sv_2_object
and found it in ./typemap, but it was in the INPUT section. In the
TYPEMAP section, I found both wxMenuBar and wxFrame are O_WXOBJECT,
and in the OUTPUT section, O_WXOBJECT uses wxPli_object_2_sv.
It's hurting my mind now.

[wxperl-users] Wx::ComboBox::SetValue ineffective when wxCB_READONLY is set

[Everett, T. <TEv...@AL...>]

It appears that both the value parameter in the constructor and
Wx::ComboBox::SetValue are ineffective when wxCB_READONLY is set.
Wx::ComboBox::SetSelection continues to work.

The documentation for wxComboBox::SetValue states:
"NB: For a combobox with wxCB_READONLY style the string must be in the
combobox choices list, otherwise the call to SetValue() is ignored."

The appended code should suffice to demonstrate.  And, in case I seem
insufficiently grateful, wxPerl does really rock!  I'm still stumbling my
way through the darkness, but I'm making reasonably good progress in doing
my first test port of a Tk app.  There are definitely some Tk things I miss
(-textvariable, for one:), but I will say the native look and feel is
greatly appreciated.

Oh, and here's a cute tidbit.  Minimalist code for tossing up a GUI error
message:
require Wx;
*Wx::App::OnInit = sub {1};
my $temp = Wx::App->new();
Wx::MessageBox($errormsg, "Fatal Error", wxOK|wxICON_ERROR, undef); 

--Toby Everett



use strict;

package MyFrame;
use Wx qw(:everything);

use vars qw(@ISA);
@ISA=qw(Wx::Frame);

sub new {
  my $class = shift;
  my $self = $class->SUPER::new(undef, -1, $0, [-1,-1], [-1,-1]);

  my $wx = $self->{wx} = {};

  $wx->{pnl} = Wx::Panel->new($self, -1);
  $wx->{szr} = $_ = Wx::BoxSizer->new(wxVERTICAL);
  $wx->{pnl}->SetSizer($_);
  $wx->{pnl}->SetAutoLayout(1);

  my @list = qw(red orange yellow green blue purple);

  $wx->{cmbDemo} = $_ = Wx::ComboBox->new($wx->{pnl}, -1, $list[2], [-1,-1],
      [-1,-1], \@list, wxCB_DROPDOWN|wxCB_READONLY);
  $wx->{szr}->Add($_, 0, wxALIGN_CENTRE|wxALL, 5);
#  $wx->{cmbDemo}->SetValue($list[2]);
#  $wx->{cmbDemo}->SetSelection(2);

  $wx->{szr}->Fit($self);
  return $self;
}

package MyApp;
use Wx;

use vars qw(@ISA);
@ISA=qw(Wx::App);

sub OnInit {
  my $self = shift;

  my $frame = MyFrame->new();
  $self->SetTopWindow($frame);
  $frame->Show(1);
}

package main;
(my $app = MyApp->new())->MainLoop();

RE: [wxperl-users] Minor inconsistency using MenuItem and EVT_MEN U

[Mattia B. <mb...@ds...>]

> -----Original Message-----
> From:	Mattia Barbon [mailto:mb...@ds...]
> Sent:	Thursday, September 05, 2002 9:32 AM
> To:	Everett, Toby
> Cc:	wxp...@li...
> Subject:	RE: [wxperl-users] Minor inconsistency using MenuItem and
> EVT_MEN	U
> 
> > Ah, OK, I didn't understand you were talking about wxMenuItem (I somehow
> missed
> > the second half of the subject - sorry).
> > The answers are that passing -1 to the menuitem ctor is not going to work
> -
> > unfortunatley - it is a wxWindows feature (or limitation, depending on
> your POV).
> > The other problem (having to call ->GetId on the menuitem) will be fixed
> in the
> > next wxPerl release.
> Am I correct in guessing that the otherwise undefined value ID_SEPARATOR is
> actually -1?  Interestingly, when Microsoft uses ID_SEPARATOR in MFC, it
Yes

> uses 0 (see VC98\MFC\Include\AFXRES.H).
> 
> Is there a reliable way of querying wxWindows for an unused id?  One way of
> doing it would be to increment starting at wxID_HIGHEST and to use
> FindWindow to ensure that there isn't already something using the id (just
> in case one of the randomly assigned ids happens to conflict).
wxNewId and wxRegisterId appear to do what you want. Unfortunately
they are not wrapped (yet). Will be in the next release. Until then
your method looks like the only alternative.

Regards
Mattia

RE: [wxperl-users] Minor inconsistency using MenuItem and EVT_MEN U

[Everett, T. <TEv...@AL...>]

-----Original Message-----
From:	Mattia Barbon [mailto:mb...@ds...]
Sent:	Thursday, September 05, 2002 9:32 AM
To:	Everett, Toby
Cc:	wxp...@li...
Subject:	RE: [wxperl-users] Minor inconsistency using MenuItem and
EVT_MEN	U

> Ah, OK, I didn't understand you were talking about wxMenuItem (I somehow
missed
> the second half of the subject - sorry).
> The answers are that passing -1 to the menuitem ctor is not going to work
-
> unfortunatley - it is a wxWindows feature (or limitation, depending on
your POV).
> The other problem (having to call ->GetId on the menuitem) will be fixed
in the
> next wxPerl release.
Am I correct in guessing that the otherwise undefined value ID_SEPARATOR is
actually -1?  Interestingly, when Microsoft uses ID_SEPARATOR in MFC, it
uses 0 (see VC98\MFC\Include\AFXRES.H).

Is there a reliable way of querying wxWindows for an unused id?  One way of
doing it would be to increment starting at wxID_HIGHEST and to use
FindWindow to ensure that there isn't already something using the id (just
in case one of the randomly assigned ids happens to conflict).

--Toby Everett

Re: [wxperl-users] wxNO not exported?

[Mattia B. <mb...@ds...>]

> Nope...I'm looking for wxYES, wxNO and wxCANCEL, which should be valid
> returnvalues for a wxMessageBox (see the wxWindows documentation). wxYES
> works, but what about wxNO?
Added now to CVS...

Regards
Mattia

Re: [wxperl-users] scalar reference objects?

[Mattia B. <mb...@ds...>]

> Something I've found annoying is that some classes are
> implemented as scalar references. Say I want to
> subclass Wx::MenuBar. Because it is a scalar reference
> instead of the normal hash reference, I can't do this:

<snip>

> I think since wxWindows philosophy/API is very object-oriented,
> that perhaps (unless there is a technical reason forbidding it)
> those classes should be hash refs.
Well, wxPerl classes are arbitrarily divided in "subclassable" and
"not subclassable";
Subclassable:
1a. ->new returns an hash ref
1b. wxPerl always returns the original hash ref from
    wxWindows methods (f.e. from ->GetChildren or ->GetParent)
Not subclassable:
2a. -> new returns a scalar ref
2b. wxPerl creates a new scalar ref every time it needs to return
    such an object from wxWindows methods

Having 1b requires a small but nonzero amount of work, so I try not to
have it without necessity (BTW subclassing wxMenuBar is unusual,
why do you need it? just curious); I could have 1a and 2b, but that would
be confusing
----
my $a = Wx::MenuBar->new(...);
$frame->SetMenuBar( $a );
my $b = $frame->GetMenuBar;
# $a is an hash ref, $b is a scalar ref, OR another hash ref,
# different from the first one
----

I can move wxMenuBar (or any other class) to subclassable (or to not
subclassable) it just requires some small work.

Regards
Mattia

RE: [wxperl-users] Minor inconsistency using MenuItem and EVT_MEN U

[Mattia B. <mb...@ds...>]

> Just in case there are questions, I'm running wxPerl 0.11, wxWindows 2.2.9,
> from the PPM package on the website, under ActivePerl build 623.
Thanks

> The following code (as small as I could get it - what is the completely
> minimal Wx "Hello World" program?) reproduces the problems - both can be
This si small enough; thanks!

> demonstrated by swapping in a 0 for the 1 in the respective trinary
> conditionals.  In the case of passing -1 to Wx::MenuItem::new, the menuitem
> simply never shows up in the menu.  In the case of passing $mexit instead of
> $mexit->GetId to EVT_MENU, the event binding isn't implemented.
Ah, OK, I didn't understand you were talking about wxMenuItem (I somehow missed
the second half of the subject - sorry).
The answers are that passing -1 to the menuitem ctor is not going to work -
unfortunatley - it is a wxWindows feature (or limitation, depending on your POV).
The other problem (having to call ->GetId on the menuitem) will be fixed in the
next wxPerl release.

Thanks for your time.
Mattia

Re: [wxperl-users] wxNO not exported?

[Jouke V. <jo...@pv...>]

wxYES_NO is the *style* you want to use for a wxMessageBox...it's not 
the *result*

DH wrote:

>I ran into that a couple of months back.  That is why I use
>
>    wxYES_NO
>
>I guess I should add this to my tips ;)
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>http://finance.yahoo.com
>

-- 
 ---------------------------------------------------------------------- 
| Jouke Visser            | http://jouke.pvoice.org  (personal)        |
|                         | http://www.pvoice.org    (pVoice & pStory) |
| Perl GUI Geek           | http://wxperl.pvoice.org (wxPerl)          |
 ---------------------------------------------------------------------- 

Re: [wxperl-users] wxNO not exported?

[DH <cra...@ya...>]

I ran into that a couple of months back.  That is why I use

    wxYES_NO

I guess I should add this to my tips ;)

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: [wxperl-users] wxNO not exported?

[Jouke V. <jo...@pv...>]

>
>
>well, i use wxID_[(YES)|(NO)|(CANCEL)] for my dialogs and assume that's
>right.
>
>what return do you get from the wxMessageBox when you click ok?
>wxYES -> 32
>wxID_YES -> 5103
>wxID_NO -> 5104
>wxID_CANCEL -> 5101
>
>if you get 5103 then the wxID_XYZ's are ok. else i can't help.
>
Well, my lunch-break-private-project-hacking-time is over...;-) I will 
check on it tonight and let you know...

In any case, if you are right, there should be an update in the 
documentation (at least I'll add it to the wiki :)

-- 
 ---------------------------------------------------------------------- 
| Jouke Visser            | http://jouke.pvoice.org  (personal)        |
|                         | http://www.pvoice.org    (pVoice & pStory) |
| Perl GUI Geek           | http://wxperl.pvoice.org (wxPerl)          |
 ---------------------------------------------------------------------- 

RE: Re: [wxperl-users] wxNO not exported?

[<so...@bl...>]

>Nope...I'm looking for wxYES, wxNO and wxCANCEL, which should be valid
>returnvalues for a wxMessageBox (see the wxWindows documentation). wxYES=

>works, but what about wxNO?

well, i use wxID_[(YES)|(NO)|(CANCEL)] for my dialogs and assume that's
right.

what return do you get from the wxMessageBox when you click ok?
wxYES -> 32
wxID_YES -> 5103
wxID_NO -> 5104
wxID_CANCEL -> 5101

if you get 5103 then the wxID_XYZ's are ok. else i can't help.

greeting
Marco

Re: [wxperl-users] wxNO not exported?

[Jouke V. <jo...@pv...>]

Nope...I'm looking for wxYES, wxNO and wxCANCEL, which should be valid
returnvalues for a wxMessageBox (see the wxWindows documentation). wxYES
works, but what about wxNO?

so...@bl... wrote:

 >>I've just tried to use the wxNO to check the returnvalue of a
 >>wxMessageBox, where Perl told me that my 'bareword wxNO' wasn't allowed
 >>while use strict. Which is perfectly OK, if it weren't the case that i
 >>had declared use Wx qw(:everything). Changing the check to see if it
 >>didn't equal wxYES (one way or the other, if you have two possibilities
 >>to click on, it would give the same result...), the script compiles
 >>perfectly.
 >>
 >
 >think you're looking for:
 >wxID_OK and wxID_CANCEL
 >
 >hope it helps
 >
 >greeting
 >Marco
 >
 >
 >
 >-------------------------------------------------------
 >This sf.net email is sponsored by: OSDN - Tired of that same old
 >cell phone?  Get a new here for FREE!
 >https://www.inphonic.com/r.asp?r_______________________________________________
 >wxperl-users mailing list
 >wxp...@li...
 >https://lists.sourceforge.net/lists/listinfo/wxperl-users
 >

-- 
  ----------------------------------------------------------------------
| Jouke Visser            | http://jouke.pvoice.org  (personal)        |
|                         | http://www.pvoice.org    (pVoice & pStory) |
| Perl GUI Geek           | http://wxperl.pvoice.org (wxPerl)          |
  ----------------------------------------------------------------------

RE: [wxperl-users] wxNO not exported?

[<so...@bl...>]

>I've just tried to use the wxNO to check the returnvalue of a
>wxMessageBox, where Perl told me that my 'bareword wxNO' wasn't allowed
>while use strict. Which is perfectly OK, if it weren't the case that i
>had declared use Wx qw(:everything). Changing the check to see if it
>didn't equal wxYES (one way or the other, if you have two possibilities
>to click on, it would give the same result...), the script compiles
>perfectly.

think you're looking for:
wxID_OK and wxID_CANCEL

hope it helps

greeting
Marco

[wxperl-users] wxNO not exported?

[Jouke V. <jo...@pv...>]

Hi,

I've just tried to use the wxNO to check the returnvalue of a 
wxMessageBox, where Perl told me that my 'bareword wxNO' wasn't allowed 
while use strict. Which is perfectly OK, if it weren't the case that i 
had declared use Wx qw(:everything). Changing the check to see if it 
didn't equal wxYES (one way or the other, if you have two possibilities 
to click on, it would give the same result...), the script compiles 
perfectly.
Question: bug?

I'm using wxPerl 0.11 (PPD package) with Activestate Perl.

-- 
 ---------------------------------------------------------------------- 
| Jouke Visser            | http://jouke.pvoice.org  (personal)        |
|                         | http://www.pvoice.org    (pVoice & pStory) |
| Perl GUI Geek           | http://wxperl.pvoice.org (wxPerl)          |
 ---------------------------------------------------------------------- 

[wxperl-users] wxPerl tutorial at YAPC::Europe

[Jouke V. <jo...@pv...>]

For the people attending YAPC::Europe 2002 in Munich, I'll be giving a 
wxPerl tutorial there. It won't be going into the guts of wxPerl 
(because I don't know what's really going on deep inside), but it will 
be an introduction to creating GUIs using wxPerl.

Jouke

[wxperl-users] pardon my ignorance, wxNO_BORDER will remove the border if it can

[DH <cra...@ya...>]

This is to whomever asked about a TextCtrl without a border

pardon my ignorance, wxNO_BORDER will remove the border ( at least on windoze)

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

RE: [wxperl-users] Patterns, anyone?

[Everett, T. <TEv...@AL...>]

-----Original Message-----
From:	Everett, Toby [mailto:TEv...@AL...]
Sent:	Wednesday, September 04, 2002 12:58 PM
To:	'wxp...@li...'
Subject:	RE: [wxperl-users] Patterns, anyone?

> Ahhh!!!  The light just blinded me.  I know why EVT_* requires you to pass
> $self.  So it knows upon what object to call the subroutine - otherwise
the
> called subroutine wouldn't have access to $self.  Basically, you can think
> of there being two coding paradigms that were available when the EVT_*
> syntax was written: one in which EVT_* would be responsible for building
the
> closure and one in which the user would buildsthe closure.  Here's two
ways
> that that EVT_* could have been written:
>
> EVT_BUTTON($self, $button, \&method);
> EVT_BUTTON($button, sub {$self->method(@_)});

I've decided that there are other reasons why EVT_* requires you to pass
$self in some circumstances - for instance, EVT_CLOSE has to know which
frame's CLOSE you're hooking, right?  On the other hand, I think my original
logic holds for situations like EVT_BUTTON, where a handle to the button is
being passed in addition to $self.

--Toby Everett

RE: [wxperl-users] Patterns, anyone?

[Everett, T. <TEv...@AL...>]

-----Original Message-----
From:	Scott Lanning [mailto:sla...@th...]
Sent:	Tuesday, September 03, 2002 11:38 PM
To:	Everett, Toby
Cc:	'wxp...@li...'
Subject:	Re: [wxperl-users] Patterns, anyone?

> On Tue, 3 Sep 2002, Everett, Toby wrote:
> [...]
> > My next goal was to use anonymous subroutines as much as possible.
>
> I think a problem with that is if your interface does
> the same thing from several different places -- toolbar,
> menubar, treectrl -- then you duplicate code.
> Plus I think nesting anonymous subroutines is ugly,
> but that's just me. :)

I agree that when your interface does the same thing from multiple places
that it is a Good Thing(TM) to factor the code.  I usually end up with an
anonymous subroutine wrapper rather than simply referencing the class
method, though.

Ahhh!!!  The light just blinded me.  I know why EVT_* requires you to pass
$self.  So it knows upon what object to call the subroutine - otherwise the
called subroutine wouldn't have access to $self.  Basically, you can think
of there being two coding paradigms that were available when the EVT_*
syntax was written: one in which EVT_* would be responsible for building the
closure and one in which the user would buildsthe closure.  Here's two ways
that that EVT_* could have been written:

EVT_BUTTON($self, $button, \&method);
EVT_BUTTON($button, sub {$self->method(@_)});

In the first one, the tri-value syntax EVT_BUTTON guarantees the passed
subroutine will be called with $self and $event.  In the second one, the
bi-value syntax EVT_BUTTON only guarantees that the passed subroutine will
be called with $event.  If the passed subroutine needs access to $self, you
have to create a closure and package $self into it.  The first approach to
EVT_BUTTON encourages methods as handlers, whereas the second has a strong
tendency to favor closures.

Here's something interesting to think about, though.  The "normal"
EVT_BUTTON syntax I see in use everywhere inhibits subclassing.  Let's say
that you have a MyFrame class that creates a button and then defines the
method OnButton to handle that button click.  The normal code in that
situation would be:

EVT_BUTTON($self, $button, \&OnButton);

That works fine until you create MyFrame_SubClass, a subclass of the MyFrame
class, and try to override the OnButton method _without_ overriding the code
that calls EVT_BUTTON.  In that situation, because the code that calls
EVT_BUTTON is executing in the MyFrame package, \&OnButton is a reference to
the MyFrame::OnButton subroutine.  Even though $self is of class
MyFrame_SubClass, EVT_BUTTON is going to call $self->$coderef($event), where
$coderef is equivalent to MyFrame::OnButton.  Which means that
MyFrame_SubClass::OnButton gets ignored.  On the other hand, things work if
you use a closure like so:

EVT_BUTTON($self, $button, sub {$self->OnButton($_[1])});
or, more correctly (in case for whatever reason there are multiple
parameters beyond $self):
EVT_BUTTON($self, $button, sub {(shift)->OnButton(@_)});

In that situation, because the matching of the OnButton method name to the
implementing subroutine is delayed until the closure is executed, you ensure
the method can be overridden easily.

Of course, I could be completely wrong in my analysis above, but I'm
reasonably certain I'm not.  Although I haven't tested the above theory,
when I co-wrote Class::Prototyped, I ended up learning more about the guts
of the Perl OO stuff than I think really wanted to know.  I'm not looking
forward to tracking down the problems 5.8.x is bringing - the test cases are
failing, and I need to sit down for a weekend and model 5.8.x's behavior
well enough to get it working again :(.

--Toby Everett