wxperl-users — For wxPerl users

Re: [wxperl-users] possible .12b4 bugs

[Chris I. <ch...@sp...>]

Ah-Ha.

The culprit seems to be wxWindows 2.33+, the 0.11 built against 2.29 =
does not seem to exhibit these problems.

  ----- Original Message -----=20
  From: Chris Ingrassia=20
  To: wxp...@li...=20
  Sent: Tuesday, November 19, 2002 12:56 PM
  Subject: [wxperl-users] possible .12b4 bugs



      Can anyone verify these so I know it's not just me?

  [0.12b4/Unicode PPM / ActivePerl 633 / Win2k]=20

      First off, the issue I sent a message about yesterday regarding =
the wxICON_INFORMATION and wxICON_QUESTION icon constants being swapped =
appears to be a non-issue in .12b4

      Second, wxSTAY_ON_TOP doesn't appear to work anymore.  Worked in =
0.10, but starting with 0.11 it seems to be broken.

      Third, I suspect there may be a memory leak or some other =
weirdness in the 0.12b4 binaries.  I'm sorry I can't provide much =
specific information, I'm developing an application that runs inside =
another application's activescript host and I don't have debug symbols =
for anything, it makes tracking things down a real pain.

      All I know is, using 0.11, everything (except for the icons and =
wxSTAY_ON_TOP) seemed to be fine.  If I plug in 0.12b4, I get =
intermittent crashes, and they're not always in the same DLL or =
executable when I look at a stack trace.  So wxPerl (or wxWindows) seems =
to be the variable in that equation.  I'm trying to investigate this a =
little further as time allows, but it's very tedious and time-consuming.

   =20

[wxperl-users] possible .12b4 bugs

[Chris I. <ch...@sp...>]

    Can anyone verify these so I know it's not just me?

[0.12b4/Unicode PPM / ActivePerl 633 / Win2k]=20

    First off, the issue I sent a message about yesterday regarding the =
wxICON_INFORMATION and wxICON_QUESTION icon constants being swapped =
appears to be a non-issue in .12b4

    Second, wxSTAY_ON_TOP doesn't appear to work anymore.  Worked in =
0.10, but starting with 0.11 it seems to be broken.

    Third, I suspect there may be a memory leak or some other weirdness =
in the 0.12b4 binaries.  I'm sorry I can't provide much specific =
information, I'm developing an application that runs inside another =
application's activescript host and I don't have debug symbols for =
anything, it makes tracking things down a real pain.

    All I know is, using 0.11, everything (except for the icons and =
wxSTAY_ON_TOP) seemed to be fine.  If I plug in 0.12b4, I get =
intermittent crashes, and they're not always in the same DLL or =
executable when I look at a stack trace.  So wxPerl (or wxWindows) seems =
to be the variable in that equation.  I'm trying to investigate this a =
little further as time allows, but it's very tedious and time-consuming.

 =20

[wxperl-users] WxPerl on MacOS X 10.2

[H. W. M. <mi...@lu...>]

Hello,

I'm looking at WxPerl as a step up from Perl/Tk for a cross-platform 
GUI app I've written.  I downloaded and installed wxWindows 2.3.3 on my 
MacOS X 10.2 system, but when I try to build WxPerl, I get:

...
Running Mkbootstrap for Wx::Grid ()
chmod 644 Grid.bs
rm -f ../../blib/arch/auto/Wx/Grid/Grid.bundle
LD_RUN_PATH="/usr/local/lib:/usr/lib" /distrib/mac/shared-ld-sh 
-undefined suppress -flat_namespace    -flat_namespace -bundle 
-undefined suppress -L/usr/local/lib Grid.o   -o 
../../blib/arch/auto/Wx/Grid/Grid.bundle   -L/usr/local/lib 
-lwx_mac-2.3 -lcc_dynamic
/bin/sh: /distrib/mac/shared-ld-sh: No such file or directory
make[2]: *** [../../blib/arch/auto/Wx/Grid/Grid.bundle] Error 127
make[1]: *** [subdirs] Error 2
make: *** [subdirs] Error 2

The only place shared-ld-sh exists is in the wxWindows source tree.

So, I guess before I do too much more working with it, I need to ask - 
does WxPerl work under OS X?

Thanks,
Wade

Re: [wxperl-users] wx installation problems

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

On Mon, 18 Nov 2002 11:21:04 +0100 so...@bl... wrote:

> i've exactly this problem:
> http://www.geocrawler.com/archives/3/8008/2002/5/0/8669779/
> 
> (win2000, perl v5.8.0, wxPerl-0.12b4)
> 
> ok, i extracted the ppm package and then run the script.
> then i got:
> 
> Can't locate object method "catfile" via package "MM" (perhaps you forgot
> to load "MM"?) at fast.pl line 14.
> 
> ok, after a little internet research i made a s/MM/File::Spec/g
> (http://archive.develooper.com/mak...@pe.../msg00457.html)
> 
> then (while trying again) i got the message:
> Writing C:\Perl\site\lib\auto\Wx\.packlist
> 
> if i now run a wx script i get:
> Can't locate Wx.pm in @INC
> 
> and yes, wx is nowhere...
> there's just a perl/site/lib/auto/wx/.packlist
> 
> any ideas? i know this doesn't happen (ppm bug(?)) with perl 5.6.X
> i have no reason to use perl 5.8... should i downgrade?
  I won't provide binary packages for perl 5.8.0 until 0.13 (my free
time is about none currently, and I have to get 0.12 out with some
decent testing...). Even if you manage to install PPMs with perl 5.8.0
they won't work (5.6.x and 5.8.x are binary incompatible).

Regards
Mattia

[wxperl-users] Icon constants

[Chris I. <ch...@sp...>]

    Hi -=20

    I'm using wxPerl 0.11(binary ppm)/wxWindows 2.3.3 on Win2k under =
ActivePerl 633.

    It seems that the icon constants wxICON_QUESTION and =
wxICON_INFORMATION are swapped.  When I use one, I get an icon =
corresponding to the other.

    This struck me as being a bug unless I'm doing something really =
crazy to cause this to happen.  Has anyone else seen this?

[wxperl-users] wx installation problems

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

i've exactly this problem:
http://www.geocrawler.com/archives/3/8008/2002/5/0/8669779/

(win2000, perl v5.8.0, wxPerl-0.12b4)

ok, i extracted the ppm package and then run the script.
then i got:

Can't locate object method "catfile" via package "MM" (perhaps you forgot=

to load "MM"?) at fast.pl line 14.

ok, after a little internet research i made a s/MM/File::Spec/g
(http://archive.develooper.com/mak...@pe.../msg00457.html)

then (while trying again) i got the message:
Writing C:\Perl\site\lib\auto\Wx\.packlist

if i now run a wx script i get:
Can't locate Wx.pm in @INC

and yes, wx is nowhere...
there's just a perl/site/lib/auto/wx/.packlist

any ideas? i know this doesn't happen (ppm bug(?)) with perl 5.6.X
i have no reason to use perl 5.8... should i downgrade?

greeting
marco

[wxperl-users] Core dump extravanza

[nadim <na...@kh...>]

Hi all,

before I get into the rough, I'd like to introduce myself shortly. (If yo=
u=20
are i a hurry to know the problems I have jump to section 5)

1/My name is Nadim Khemir, 35, work as a software engineer at CTechnologi=
es=20
OS group in Sweden. Program in C, C++, perl and other if I have to.

2/ I've been following wxPerl since it's beginning but I never had the ti=
me=20
to help or anything intressting to present. but things are changing or=20
hopefully will change. I want to use wxPerl for 'Smed' my favorite projec=
t=20
these last years.=20

I present 'Smed', shortly too, as some might be interested in it. Smed is=
=20
nothing fancy, it's a text editor (TE), my text editor. I have written=20
text editors since I was 15 and I guess I won't stop soon. Frankly I=20
dislike vi and emacs and most of the other editors I have tried. Not that=
=20
they are bad but my editors simply fits me better (not surprisingly :-).=20
Smed started as a C++ project evolved to include flex and vb then python=20
then I re-wrote it to use perl and then re-wrote it again to get rid of=20
most vd pieces. I developed, and used it +/- 5 years, on Win32-MFC. I=20
lately started to use Linux a lot and there is something missing in the=20
standard distribution, my text editor. So I set to re-write the editor=20
once more, this time using wxPerl  that is eliminating the C++ code=20
altogether.

3/ Smed will soon be released under GPL or something even less restrictiv=
e.=20
The project will be open to all good will. Let me know if you are=20
intressted or if you want to knwo what smed can do or will do.=20

4/ Smed is definitely a 'perl editor', it beats emacs flat when it comes =
to=20
support perl (specially as it is scriptable with perl) it also supports=20
other languages and frameworks (including wxWindows)

5/ But before I get Smed to be in the standard linux or perl distribution=
=20
;-) I have to make it work. From this point I will refer to the wxPerl=20
version as Smed. Smed is a bunch of perl modules, setup files, etc adding=
=20
to around 100 files ; so it is very difficult to describe in details (I'l=
l=20
do that if necessary of course)

Smed runs on Windows but has the two following problems:
A- Display is too slow (compared to the C++ version).I can make it faster=
=20
in multiple ways, it's just that it's not time for tweaking yet.

B- Very surprisingly, Smed core dumps in the wxPerl dll. I cornered the=20
problem to these lines in a setup file.
2 Setup/Perl/WxKeywords.hive
#3 Setup/perl/CompleteWxKeywords.hive

The file named on the line is loaded into a perl hash, wxPerl is not=20
involved at all. When the bigget file (3) is loaded, Smed crashes in the=20
wxPerl dll. I am not pointing at anyone, I am just surprised. Now if you=20
think this is crazy read on. wxPerl was installed from an install file no=
t=20
compiled by me on the win32 platform.

Let's change platform and run Smed on Linux. here I compiled wxGTK-2.3.3=20
and Wx-0.11. Before running Smed I got into troubles.
A- When running any example, the script doesn't come back to the command=20
prompt, I have to  ^C it.

B- The wxPerl demo crashes with this message when I try the contrib/XRC:
perl: relocation error:=20
/usr/src/Wx-0.11/demo/../blib/arch/auto/Wx/XRC/XRC.so: undefined symbol:=20
wxXmlInitResourceModule__Fv

C- The wxPerl demo crashes with this message when I try the contrib/STC
Can't load '/usr/src/Wx-0.11/demo/../blib/arch/auto/Wx/STC/STC.so' for=20
module Wx::STC: /usr/src/Wx-0.11/demo/../blib/arch/auto/Wx/STC/STC.so:=20
undefined symbol: wxSTCNameStr at=20
/usr/local/lib/perl5/5.8.0/i686-linux-multi/DynaLoader.pm line 229.
 at /usr/src/Wx-0.11/demo/../blib/lib/Wx.pm line 129
Compilation failed in require at /usr/src/Wx-0.11/demo/wxSTC.pm line 46.
BEGIN failed--compilation aborted at /usr/src/Wx-0.11/demo/wxSTC.pm line=20
46.
Compilation failed in require at demo.pl line 162.
Segmentation fault

D- Smed starts and then crashes with this message:
=2E..
Loading setup file Setup/Perl/PerlTemplate.spl: setup function not define=
d.
Loading setup file Setup/Perl/PerlContextMenu.spl: setup function not=20
defined.
# above are normal warning messages
-------------------------------------------------------------------------=
-------
Segmentation fault

The main frame is not even displayed.

E- I was lining up those warning messages when I got the main frame to=20
display correctly, now the incredible code that made this possible was:

1>print "\nLoading setup file $setup_path/$_: " if $display_setup_files ;
2>my $sepppp =3D (50 - length("Loading setup file $setup_path/$_: ")) x '=
 ' ;
3>print $sepppp ;

I just added line 2 and 3!

As you might guess, I am really lost.

Nadim.



=20

Re: [wxperl-users] Inheritance from Frame... impossible?

[Mark W. <mwi...@ge...>]

Cool!

Thanks very much -  I didn't realize a workaround would be so 
straightforward :-)

Speaking as a newbie I'm finding WxPerl...er... I mean wxPerl... to be 
quite intuitive.  Thanks for making it freely available, and thanks 
again for taking the time to answer questions,

Cheers!

M


Mattia Barbon wrote:
> On Thu, 14 Nov 2002 15:55:32 -0600 Mark Wilkinson <mwi...@ge...> wrote:
>   I see the problem; the solution is for wxPerl to implement
> Wx::Frame::OnCreateStatusBar. I did not wrap it because I did not think of
> a situation like yours. Until next wxPerl release (hopefully soon...),
> you can put this in you class:
> 
> sub OnCreateStatusBar {
>     my( $this, $number, $style, $id, $name ) = @_;
>     my $statusBar = Wx::StatusBar->new($this, $id, $style, $name);
> 
>     $statusBar->SetFieldsCount($number);
> 
>     return $statusBar;
> }
> 


-- 
--------------------------------
"Speed is subsittute fo accurancy."
________________________________

Dr. Mark Wilkinson, RA Bioinformatics
National Research Council, Plant Biotechnology Institute
110 Gymnasium Place, Saskatoon, SK, Canada

phone : (306) 975 5279
pager : (306) 934 2322
mobile: markw_mobile at illuminae dot com

Re: [wxperl-users] Inheritance from Frame... impossible?

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

On Thu, 14 Nov 2002 15:55:32 -0600 Mark Wilkinson <mwi...@ge...> wrote:

> Hi all,
> 
> question #2 (can you tell I'm a WxPerl newbie?)
  Yes, it is written wxPerl ;-p

> Inheritance (at least from Wx::Frame) seems quite awkward, or even 
> impossible, if you have an AUTOLOAD function in your inherited module.
> 
> The following pseudo code shows the problem:
> 
> @ISA (Wx::Frame)
> 
> $self = SUPER::new(%args)
> print $self->GetTitle  # prints title as one expects
> print $self->SUPER::GetTitle  # also prints title, no worries
> 
> BUT!!!
> 
> print $self->CreateStatusBar(@args)  # this kills the script
> print $self->SUPER::CreateStatusBar(@args) # this also kills
> 
> The reason is that the latter calls cannot be trapped by the AUTOLOAD 
> and passed up to the parent object because the parent object immediately 
> makes a peculiar call to a method in its child (->OnCreateStatusBar), 
> which is not required to exist.  When this call fails, AUTOLOAD will try 
> to jump to the rescue and (if sensibly designed) will attempt to call 
> $self->SUPER::OnCreateStatusBar... but $self->SUPER has no value 
> (apparently because it is being called by the parent itself), so 
> $self->SUPER returns undef, and the $self->SUPER::OnCreateStatusBar call 
> causes an infinite recursion into the AUTOLOAD.
  I see the problem; the solution is for wxPerl to implement
Wx::Frame::OnCreateStatusBar. I did not wrap it because I did not think of
a situation like yours. Until next wxPerl release (hopefully soon...),
you can put this in you class:

sub OnCreateStatusBar {
    my( $this, $number, $style, $id, $name ) = @_;
    my $statusBar = Wx::StatusBar->new($this, $id, $style, $name);

    $statusBar->SetFieldsCount($number);

    return $statusBar;
}

> There appears to be two stumbling blocks here:  (1) that the parent 
> makes the OnCreateStatusBar call in the first place (realistically, if I 
> wanted to create my own StatusBar I would have overridden the 
> CreateStatusBar method in the first place)
  This was explained by Simon Flack a couple of messages below.

> and (2) that 
> OnCreateStatusBar must either not exist (which triggers AUTOLOAD) or 
> must return a StatusBar object if it does exist (which means that I 
> can't implement it in my inherited module without duplicating all of the 
> CreateStatusBar code).
  See above; the workaround (while still a _workaround_) is quite simple.

HTH
Mattia

Re: [wxperl-users] Constructor for Wx::App

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

On Wed, 13 Nov 2002 16:30:08 -0600 Mark Wilkinson <mwi...@ge...> wrote:

> Hi all!
> Is there any reason why the constructor for Wx::App doesn't pick up and 
> pass any arguments?  It seems that it might be useful to simply pass 
> %args along with the $this = $_[0]->SUPER::new();  on line 31.
  Why? This line calls Wx::_App::new, which calls the C++ constructor for
wxApp, which does not expect any arguments.

> ...or is there a good reason why this doesn't happen?
  No, simply there isn't any good reason (that I know of) for this to
happen...

Regards
Mattia

Re: [wxperl-users] Inheritance from Frame... impossible?

[Simon F. <sf...@fl...>]

On Thu, 14 Nov 2002 19:15:41 -0600 (CST), Mark Wilkinson wrote
> ooooookaaaaayyyyyyy....  But why is it not possible for (e.g.) 
> OnCreateStatusBar to simply return "undef" or something like that, 
> rather than having to return an actual StatusBar object?  that way I 
> could include that method (empty) in my object (to keep Autoload 
> happy) but it would still create the status bar from the Frame 
> object.  Is that behaviour deeply rooted in the C code, or is that 
> part of the wxPerl implementation?

Most of the behaviour is deeply rooted in the C code. wxPerl just exposes it 
in a way we can use. 

I've just had a peek in the wxWindows code... wxFrame::CreateStatusBar is 
just a convenient wrapper around OnCreateStatusBar(). As you guessed, 
OnCreateStatusBar() actually creates the status bar. But CreateStatusBar() 
keeps track of it and positions it. My guess it that it is designed this way 
to make it easier to change the behaviour. If you want a different type of 
statusbar, you just override OnCreateStatusBar() and you don't have to worry 
about the other things.

> Not being able to use Autoload is... inconvenient... and quite un-
> perlish ;-)
> 
> Thanks for your reply!
> 
> If you come up with any other ideas please let me know, but I think 
> I have expended all options other than removing AUTOLOAD completely 
> :-(

It really depends on what you're doing/what you need AUTOLOAD for. You could 
perhaps move your frame specific code to it's own package with only the 
things you are overriding from the default Wx::Frame.

--simon

Re: [wxperl-users] Inheritance from Frame... impossible?

[Mark W. <mwi...@ge...>]

ooooookaaaaayyyyyyy....  But why is it not possible for (e.g.) 
OnCreateStatusBar to simply return "undef" or something like that, rather 
than having to return an actual StatusBar object?  that way I could 
include that method (empty) in my object (to keep Autoload happy) but it 
would 
still create the status bar from the Frame object.  Is that behaviour 
deeply rooted in the C code, or is that part of the wxPerl implementation?

Not being able to use Autoload is... inconvenient... and quite un-perlish 
;-)

Thanks for your reply!

If you come up with any other ideas please let me know, but I think I have 
expended all options other than removing AUTOLOAD completely :-(

M



On Thu, 14 Nov 2002, Simon Flack wrote:

> On Thu, 14 Nov 2002 15:55:32 -0600, Mark Wilkinson wrote
> 
> > Inheritance (at least from Wx::Frame) seems quite awkward, or even 
> > impossible, if you have an AUTOLOAD function in your inherited module.
> > 
> [snip]
> > print $self->CreateStatusBar(@args)  # this kills the script
> > print $self->SUPER::CreateStatusBar(@args) # this also kills
> >
> > The reason is that the latter calls cannot be trapped by the 
> > AUTOLOAD and passed up to the parent object because the parent 
> > object immediately makes a peculiar call to a method in its child (-
> > >OnCreateStatusBar), which is not required to exist.  When this call 
> > fails, AUTOLOAD will try to jump to the rescue and (if sensibly 
> > designed) will attempt to call $self->SUPER::OnCreateStatusBar... 
> > but $self->SUPER has no value 
> > (apparently because it is being called by the parent itself), so 
> > $self->SUPER returns undef, and the $self->SUPER::OnCreateStatusBar 
> > call causes an infinite recursion into the AUTOLOAD.
> 
> As I understand it there's currently no way around this. 
> $self->SUPER::foo() will not work if foo() is a virtual c++ method and 
> your object is capable of running $self->foo(). This is due the callback 
> methods that allow us to override some of the c++ wxWindows methods. 
> These callbacks check if your object can do foo(). In your case, 
> $self->can('OnCreateStatusBar') returns true due to the AUTOLOAD.
>  
> > This seems unusually "clunky"...  is there a way around this behaviour?
> 
> I'm not a c++ expert so I couldn't say.
> 
> The way around this behaviour is to not use AUTOLOAD.
> 
> Hope this helps.
> 
> --simon
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing 
> your web site with SSL, click here to get a FREE TRIAL of a Thawte 
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users
> 

Re: [wxperl-users] Inheritance from Frame... impossible?

[Simon F. <sf...@fl...>]

On Thu, 14 Nov 2002 15:55:32 -0600, Mark Wilkinson wrote

> Inheritance (at least from Wx::Frame) seems quite awkward, or even 
> impossible, if you have an AUTOLOAD function in your inherited module.
> 
[snip]
> print $self->CreateStatusBar(@args)  # this kills the script
> print $self->SUPER::CreateStatusBar(@args) # this also kills
>
> The reason is that the latter calls cannot be trapped by the 
> AUTOLOAD and passed up to the parent object because the parent 
> object immediately makes a peculiar call to a method in its child (-
> >OnCreateStatusBar), which is not required to exist.  When this call 
> fails, AUTOLOAD will try to jump to the rescue and (if sensibly 
> designed) will attempt to call $self->SUPER::OnCreateStatusBar... 
> but $self->SUPER has no value 
> (apparently because it is being called by the parent itself), so 
> $self->SUPER returns undef, and the $self->SUPER::OnCreateStatusBar 
> call causes an infinite recursion into the AUTOLOAD.

As I understand it there's currently no way around this. 
$self->SUPER::foo() will not work if foo() is a virtual c++ method and 
your object is capable of running $self->foo(). This is due the callback 
methods that allow us to override some of the c++ wxWindows methods. 
These callbacks check if your object can do foo(). In your case, 
$self->can('OnCreateStatusBar') returns true due to the AUTOLOAD.
 
> This seems unusually "clunky"...  is there a way around this behaviour?

I'm not a c++ expert so I couldn't say.

The way around this behaviour is to not use AUTOLOAD.

Hope this helps.

--simon

[wxperl-users] Inheritance from Frame... impossible?

[Mark W. <mwi...@ge...>]

Hi all,

question #2 (can you tell I'm a WxPerl newbie?)

Inheritance (at least from Wx::Frame) seems quite awkward, or even 
impossible, if you have an AUTOLOAD function in your inherited module.

The following pseudo code shows the problem:

@ISA (Wx::Frame)

$self = SUPER::new(%args)
print $self->GetTitle  # prints title as one expects
print $self->SUPER::GetTitle  # also prints title, no worries

BUT!!!

print $self->CreateStatusBar(@args)  # this kills the script
print $self->SUPER::CreateStatusBar(@args) # this also kills

The reason is that the latter calls cannot be trapped by the AUTOLOAD 
and passed up to the parent object because the parent object immediately 
makes a peculiar call to a method in its child (->OnCreateStatusBar), 
which is not required to exist.  When this call fails, AUTOLOAD will try 
to jump to the rescue and (if sensibly designed) will attempt to call 
$self->SUPER::OnCreateStatusBar... but $self->SUPER has no value 
(apparently because it is being called by the parent itself), so 
$self->SUPER returns undef, and the $self->SUPER::OnCreateStatusBar call 
causes an infinite recursion into the AUTOLOAD.

There appears to be two stumbling blocks here:  (1) that the parent 
makes the OnCreateStatusBar call in the first place (realistically, if I 
wanted to create my own StatusBar I would have overridden the 
CreateStatusBar method in the first place), and (2) that 
OnCreateStatusBar must either not exist (which triggers AUTOLOAD) or 
must return a StatusBar object if it does exist (which means that I 
can't implement it in my inherited module without duplicating all of the 
CreateStatusBar code).

This seems unusually "clunky"...  is there a way around this behaviour?

Any advice appreciated!

Mark


-- 
--------------------------------
"Speed is subsittute fo accurancy."
________________________________

Dr. Mark Wilkinson, RA Bioinformatics
National Research Council, Plant Biotechnology Institute
110 Gymnasium Place, Saskatoon, SK, Canada

phone : (306) 975 5279
pager : (306) 934 2322
mobile: markw_mobile at illuminae dot com

[wxperl-users] Constructor for Wx::App

[Mark W. <mwi...@ge...>]

Hi all!
Is there any reason why the constructor for Wx::App doesn't pick up and 
pass any arguments?  It seems that it might be useful to simply pass 
%args along with the $this = $_[0]->SUPER::new();  on line 31.

...or is there a good reason why this doesn't happen?

Cheers all!

M


-- 
--------------------------------
"Speed is subsittute fo accurancy."
________________________________

Dr. Mark Wilkinson, RA Bioinformatics
National Research Council, Plant Biotechnology Institute
110 Gymnasium Place, Saskatoon, SK, Canada

phone : (306) 975 5279
pager : (306) 934 2322
mobile: markw_mobile at illuminae dot com

[wxperl-users] test please ignore

[nadim <na...@kh...>]

Re: [wxperl-users] Wx::ListCtrl events

[Simon F. <sf...@fl...>]

[snip]

> > Anyway, here's a minimal sample to demonstrate... 
> Thanks for the sample! "Unfortunately" it works for me
> (wxMSW, latest CVS) (by "works" I means that the dialog box
> says "OK"); maybe you are on wxGTK, or maybe this has been fixed
> in wxWindows CVS?

I'm using the wx2.3.3 snapshot on MSW. I'll try with an up-to-date cvs 
branch. It's not a big problem because I can access what I need.

The strange thing is, I have another Wx::ListCtrl that does work as expected 
with the same binary. That listctrl's style is wxLC_REPORT as opposed to 
wxLC_ICON. I'll try my sample tomorrow as an wxLC_REPORT and see if it still 
does the same thing.

Thanks

Simon

Re: [wxperl-users] Wx::ListCtrl events

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

On Wed, 6 Nov 2002 20:05:11 +0000 Simon Flack <sf...@fl...> wrote:

> Hi,
> 
> I'm getting unexpected behaviour from Wx::ListCtrl events. It may just
> be that I am expecting the wrong thing...
> 
> I thought that I could fetch the item/item text from the Wx::ListEvent
> object 
> that my event handling sub receives. But that doesn't seem to work. It
> does 
> appear to give me correct GetIndex() though. Which helps because I can
> then 
> fetch the text in a more long-winded way.
> 
> The wxWindows docs are a little unclear on this topic (for example it
> simply says "The text" for wxListEvent::GetText() :)
> 
> Anyway, here's a minimal sample to demonstrate... 
Thanks for the sample! "Unfortunately" it works for me
(wxMSW, latest CVS) (by "works" I means that the dialog box
says "OK"); maybe you are on wxGTK, or maybe this has been fixed
in wxWindows CVS?

Regards
Mattia

[wxperl-users] Wx::ListCtrl events

[Simon F. <sf...@fl...>]

Hi,

I'm getting unexpected behaviour from Wx::ListCtrl events. It may just be 
that I am expecting the wrong thing...

I thought that I could fetch the item/item text from the Wx::ListEvent object 
that my event handling sub receives. But that doesn't seem to work. It does 
appear to give me correct GetIndex() though. Which helps because I can then 
fetch the text in a more long-winded way.

The wxWindows docs are a little unclear on this topic (for example it simply 
says "The text" for wxListEvent::GetText() :)

Anyway, here's a minimal sample to demonstrate... 




#!/usr/bin/perl
use Wx;
package MyApp;
use strict;
use vars qw(@ISA);
@ISA=qw(Wx::App);
use Wx qw( :id :misc :listctrl :icon wxOK );
use Wx::Event qw( EVT_CLOSE EVT_LIST_ITEM_SELECTED );

sub OnInit {
  my( $this ) = @_;
  my( $dialog ) = Wx::Dialog->new( undef, -1,  "List Ctrl Event Test",
                                 wxDefaultPosition, [200,150] );
  EVT_CLOSE( $dialog, sub { $_[0]->Destroy() } );

  $this->{LIST} = new Wx::ListCtrl( $dialog, -1, wxDefaultPosition,
                                    [180, 120], wxLC_ICON );
  $this->{LIST}->InsertStringItem( 0, "Just another Perl hacker!" );
  EVT_LIST_ITEM_SELECTED( $dialog, $this->{LIST}, \&OnSelectItem );

  $this->SetTopWindow( $dialog );
  $dialog->Show( 1 );
  1;
}

sub OnSelectItem {
  my ($dialog, $listevent) = @_;
  my $listctrl = Wx::wxTheApp()->{LIST};

  # Get the listitem from the Wx::ListEvent...
  my $eventitem = $listevent->GetItem;

  # Now get the item from the list control:
  my $item_index = $listevent->GetIndex;
  my $realitem = $listctrl->GetItem( $item_index );

  unless ( $realitem->GetText eq $eventitem->GetText ) {

    my $message = <<ERROR;
      real_item->GetText (expected output):
          %s

      event->GetText: %s
      event->GetItem->GetText: %s
ERROR

    $message = sprintf($message, $realitem->GetText, $listevent->GetText,
                       $eventitem->GetText);

    Wx::MessageBox( $message, "Error", wxOK | wxICON_EXCLAMATION, $dialog );
  } else {
    Wx::MessageBox( "OK", $0, wxOK, $dialog ); 
  }
}


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

[wxperl-users] wxChoice Clipping

[Chris I. <ch...@sp...>]

    Hello all, I'm using wxPerl 0.11/wxWindows 2.3.3 on Win2k, using =
ActivePerl 633.

    I was wondering if there was a way to cause a wxChoice control to =
dynamically expand it's dropdown area to fit the longest string that was =
contained in it.  I don't see any such property that does this, and I =
have not been successful searching the list archives for other solutions =
to this problem.

    I would think that somewhere along the line this would have been =
noticed by other people as well, so if anyone has some hints, they would =
be greatly appreciated.

    My initial thought was to force all my wxChoice controls to use a =
custom subclass that would resize the choice control based on the =
largest string inserted into it, but I'd prefer to avoid this if =
possible.

    Thanks in advance.

-Chris

Re: [wxperl-users] wxKeyEvent in a Wx::Dialog

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

On Tue, 5 Nov 2002 19:05:47 +0000 Simon Flack <sf...@fl...> wrote:

> Hi,
> 
> I'm trying to add a key_down event to a dialog, but it never seems to
> happen. 
> I'm trying to get the window to close if I press ESC.
 Just add a button with id == wxID_CANCEL, and it will "just work"
(unless you have an EVT_BUTTON( wxID_CANCEL ), of course.

> I've just dound the answer after reading the source:
> wxDialog::OnCharHook 
> does what I want according to the docs. But it doesn't say that it only
> works 
> if the dialog has a button with the id: wxID_CANCEL.
> 
> Anyway, I suppose the next question is, is it possible to add a key_down 
> event to a Wx::Dialog? (or any other kind of wxKeyEvent).
  I don't think it is possible (to a wxDialog).
Try asking wx-users, though.

Regards
Mattia

Re: [wxperl-users] wxKeyEvent in a Wx::Dialog

[Simon F. <sf...@fl...>]

Just to clean up my spelling, and make myself a bit more clear:

I've got the window close on ESC key working, but am wondering if it's 
possible to add events to trap other keys.

Thanks


__ promises to proof read in the future __



> I'm trying to add a key_down event to a dialog, but it never seems 
> to happen. I'm trying to get the window to close if I press ESC.
> 
> I've just dound the answer after reading the source: 
> wxDialog::OnCharHook does what I want according to the docs. But it 
> doesn't say that it only works if the dialog has a button with the 
> id: wxID_CANCEL.
> 
> Anyway, I suppose the next question is, is it possible to add a 
> key_down event to a Wx::Dialog? (or any other kind of wxKeyEvent).
> 
> Thanks
> 
> Simon

[wxperl-users] wxKeyEvent in a Wx::Dialog

[Simon F. <sf...@fl...>]

Hi,

I'm trying to add a key_down event to a dialog, but it never seems to happen. 
I'm trying to get the window to close if I press ESC.

I've just dound the answer after reading the source: wxDialog::OnCharHook 
does what I want according to the docs. But it doesn't say that it only works 
if the dialog has a button with the id: wxID_CANCEL.

Anyway, I suppose the next question is, is it possible to add a key_down 
event to a Wx::Dialog? (or any other kind of wxKeyEvent).

Thanks

Simon

[wxperl-users] wxPerl 0.12b4 not on Win98/95

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

Hi,

I think it's obvious for those having worked with Unicode on Win32 platforms before, but it was new to me: I used 0.12b4, compiled the application with PerlApp, tested it on a Windows 98 machine and I got a wxWindows error saying that the Unicode version will only work on Windows NT/2000/XP.

I presume that it's wise to publish the final 0.12 version in two Windows binary versions: one unicode enabled, only working on NT/2000/XP, and one 'general' version, working on all Win32 platforms.
-- 
 ---------------------------------------------------------------------- 
| Jouke Visser            | http://jouke.pvoice.org  (personal)        |
|                         | http://www.pvoice.org    (pVoice & pStory) |
| Perl GUI Geek           | http://wxperl.pvoice.org (wxPerl)          |
 ---------------------------------------------------------------------- 

Re[2]: [wxperl-users] Unicode tests

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

On Tue, 29 Oct 2002 12:14:00 +0100 (CET) Mattia Barbon <mb...@ds...> wrote:

> 02 12:14:00 +0100 (CET)
> Status:  O
> 
> On Tue, 29 Oct 2002, Jouke Visser wrote:
> 
> <app crashing, wxLocale related>
> 
> >It seems that both are related. I can't really give you a testcase.
> From 
> >what I deduced so far the problem is as follows:
> >
> >I have a preferences window in my app. If I change the language (and 
> >therefore the locale), there is no problem as long as the locale-change 
> >doesn't produce that "Locale 'xx' can't be set" error. If it does, the 
> >app crashes without any error or warning. It doesn't even produce that 
> >Locale-set error. But when I restart the application, it has remembered 
> >my locale-change, produces the Locale-set error, and when I change it 
> >again, the same thing happens: I can change to whatever language I
> want, 
> >as often as I want, until I choose a language that produces the same 
> >error again and it crashes again without that error.
> >
> >If you want to I can send you the complete source of my app, but I
> think 
> >that causes too much confusion. If you really need example code, I can 
> >try to strip out all code that's not related to this issue and send it 
> >to you then.
> 
>   I think this characterisation is good enough, I will let you know if 
> still I can't reproduce.
  I still can't reporduce it.
Now I need your sources (stripped down if possible).

Thanks
Mattia