wxperl-users — For wxPerl users

Re: [wxperl-users] OS X App Installer

[Mattia B. <mat...@li...>]

On Mon, 07 Aug 2006 12:24:17 -0600
Mike Schroeder <Mik...@Do...> wrote:

> We have gone through several variations (PAR, PerlWrapper) of installers 
> for the OS X version of our wxPerl app in the pre-Intel days, but we are 
> having problems getting a working installer for Intel OS X 10.4.7 (which 
> now comes with wxPerl 0.22, but our app wants a more current version, 
> and we get weird path conflicts).

  Stupid question: do the path conflicts appear with the same (which?)
wxPerl version on PPC OS X 10.4.7? I guess not (or it would be too simple)
but asking does not hurt :-)

Regards
Mattia

[wxperl-users] OS X App Installer

[Mike S. <Mik...@Do...>]

We have gone through several variations (PAR, PerlWrapper) of installers 
for the OS X version of our wxPerl app in the pre-Intel days, but we are 
having problems getting a working installer for Intel OS X 10.4.7 (which 
now comes with wxPerl 0.22, but our app wants a more current version, 
and we get weird path conflicts).

My options seem to be to:
a) buy VISE X installer (http://www.mindvision.com/vise_x.asp ),
b) keep playing with PAR or PerlWrapper to resolve all the PATH issues, or
c) fund a bounty for getting PAR or PerlWrapper working *nicely* on 
Intel OS X 10.4.7

So my questions for the list are:

1) Any other suggestions?

2) Anyone interested in receiving some funding for a better OS X wxPerl 
installer? Perhaps an updated PerlWrapper xcode project that works with 
newer versions of wxPerl and wxWidgets that will work on 10.4.7?  
Perhaps that includes the wxlibs in the xcode project?? I'm open to 
providing some funding for this if someone is interested (and has some 
OS X experience too! :) )

3) Anyone have any ideas on a good way to build a Universal wxPerl app?

I know there has been discussion before about some of this, but I'm not 
sure it went anywhere...

Thanks in advance...

-- 
Mike Schroeder
DonorWare

Re: [wxperl-users] Faking Events for Testing in WxPerl

[Mattia B. <mat...@li...>]

On Fri, 04 Aug 2006 22:41:51 -0400
Ed Heil <ed...@do...> wrote:

  Hi,

> We've been talking about trying to put together a "test scripting
> language" for our big wxPerl application.
> 
> We'd like to be able to write  a file full of commands stated in some
> very simplistic code like --
> 
> 
> text-enter name "Smith"
> button-click update
> check name equals "Smith"
> 
> that sort of thing -- and have the program trigger the appropriate
> series of events, and make sure the right things happen.
> 
> I tried to put together a minimalist, "proof of concept" demo.  I put
> together in wxglade a tiny application with a couple buttons and other
> controls on it.  I made an event handler for the first button which
> called the function $frame->fake_event().  fake_event looks like this:
> 
> 
> sub fake_event {
>    my $self=shift;
>    my $entry = "Testing";
>    my $event=Wx::CommandEvent->new(wxEVT_COMMAND_BUTTON_CLICKED);
>    $event->SetEventObject($self->{button2});
> }
> 

  $window->GetEventHandler()->ProcessEvent( $event );

> I'd only gotten that far -- I hadn't figured out any more than
> generating the event and setting its EventObject -- and I ran that
> and got this --
> 
> C:\src>EventTester.pl
> 
> (I clicked on the button to trigger fake_event and...)
> 
> Can't locate object method "SetEventObject" via package
> "Wx::CommandEvent" at C:
> \src\EventTester.pl line 169.
> 
> C:\src>
> 
> 
> Uh oh.  SetEventObject is a method of Wx::Event, and Wx::CommandEvent is
> a subclass of Wx::Event, so that should have been found.
> 
> I've got two basic questions --
> 
> 1. For people who know wxWidgets better than I do -- does this seem like
> a profitable direction to go?  Is this a crazy, doomed idea or is it
> supposed to be possible to do this sort of thing?

  I think this will work for many common cases, so it is a reasonable
way to go; it does not cover 100% of the cases though. And while faking
(say) button events is trivial, wxTreeCtrl events might be more difficult
to fake.

  http://www.wefi.net/swWxGuiTesting/ uses the same approach. I wanted
to experiment with it (it even has an event recorder) but I could not
get it to compile. It would be probably be easier and cleaner to rewrite
it in Perl (because Perl is much more dynamic than C++, which I think
will help in this case).
 
> 2. Was that error ("Can't locate object method") just missing its perl
> wrapper, or was something deeper going wrong?

  Just missing a perl wrapper.

void
wxEvent::SetEventObject( object )
    wxObject* object

in Event.xs should suffice. Let me know if it works.

HTH
Mattia

[wxperl-users] Faking Events for Testing in WxPerl

[Ed H. <ed...@do...>]

We've been talking about trying to put together a "test scripting
language" for our big wxPerl application.

We'd like to be able to write  a file full of commands stated in some
very simplistic code like --


text-enter name "Smith"
button-click update
check name equals "Smith"

that sort of thing -- and have the program trigger the appropriate
series of events, and make sure the right things happen.

I tried to put together a minimalist, "proof of concept" demo.  I put
together in wxglade a tiny application with a couple buttons and other
controls on it.  I made an event handler for the first button which
called the function $frame->fake_event().  fake_event looks like this:


sub fake_event {
   my $self=shift;
   my $entry = "Testing";
   my $event=Wx::CommandEvent->new(wxEVT_COMMAND_BUTTON_CLICKED);
   $event->SetEventObject($self->{button2});
}


I'd only gotten that far -- I hadn't figured out any more than
generating the event and setting its EventObject -- and I ran that
and got this --

C:\src>EventTester.pl

(I clicked on the button to trigger fake_event and...)

Can't locate object method "SetEventObject" via package
"Wx::CommandEvent" at C:
\src\EventTester.pl line 169.

C:\src>


Uh oh.  SetEventObject is a method of Wx::Event, and Wx::CommandEvent is
a subclass of Wx::Event, so that should have been found.

I've got two basic questions --

1. For people who know wxWidgets better than I do -- does this seem like
a profitable direction to go?  Is this a crazy, doomed idea or is it
supposed to be possible to do this sort of thing?

2. Was that error ("Can't locate object method") just missing its perl
wrapper, or was something deeper going wrong?

Thanks, all --

Ed

Re: [wxperl-users] Threads

[Dan S. <da...@si...>]

At 8:18 PM +0200 8/3/06, Mattia Barbon wrote:
>   There are various way to work around this; all involve keeping tracks
>of created objects (Wx::Colour instances in this case) and doing something
>special at clone time. This solves the problem once you decide what
>special action you want to take.
>
>   Options:
>1 - the new thread is denied access to the parent thread objects
>     (tried and works; you should not access wxThings from multiple
>      threads anyway)

This would be the best option -- many GUIs don't like multiple 
threads issuing gui requests. (IIRC various versions of Windows and 
OS X have had this issue in the past, though I don't know about now)

-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
da...@si...                         have teddy bears and even
                                       teddy bears get drunk

Re: [wxperl-users] displaying currently open files in the Windowmenu

[Colin R. <Col...@bb...>]

I've done some poking around and I've found that this is a bug in Wx
rather than WxPerl. There's been an open bug since 2004 [1] but there
doesn't appear to have been much activity on it. I've added a comment
which describes the problem in more detail and has some notes about how
you might work around it.

colin

[1]
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1064351&gro=
up_
id=3D9863&atid=3D109863

Andrew wrote:
> On 7/15/06, Mattia Barbon <mat...@li...> wrote:
> > On Fri, 14 Jul 2006 13:56:23 +0100
> > Andrew <sob...@gm...> wrote:
> > > we have an app using wxPerl that uses a Wx::DocMDIParentFrame and
> > > Wx::DocMDIChildFrames.  Since upgrading from wxPerl 0.24 to 0.26,
> > > the window menu no longer displays a list of open files.
> >=20
> >   I think this is due to the last doc/view patch by Simon Flack.
> > You should contact him because I know next to nothing about DocView.
>=20
> I will ask him about this.
>=20
> > > It used to do this under wxPerl 0.24.  I notice that the demo
> > > application (Miscellanous->MDI) for wxPerl 0.26 also does not
> > > display currently open child frames in the Window menu.
> >=20
> >   I doubt it ever did. Please note the demo is about
> > Wx::MDIParent/ChildFrame, not Wx::DocMDIParent/ChildFrame
>=20
> Attached is a small test case, that demonstrates the window menu using
> either Wx::DocMDIParent or Wx::MDIParent (by varying a constant).
> The list of currently open windows works when it's run with wxPerl
> 0.24, but doesn't work with wxPerl 0.26 in both cases.
>=20
> > > Is this a bug in wxPerl 0.26 or is there something special that
> > > needs to be done to display currently open files in the Window
> > > menu?=20
> >=20
> >   I think the latter, but please ask Simon Flack (and please report
> > his answer on list).
>=20
> Based on this there appears to be a bug (or at least changed
> behaviour) in wxPerl 0.26 concerning the Window menu.  I will ask
> Simon and see if he has any ideas.
>=20
> cheers,
> Andrew

http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.=20
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.=20
Further communication will signify your consent to this.

[wxperl-users] Threads

[Mattia B. <mat...@li...>]

  Hi all,
the topic is abviously threads. This program:

==========
#!/usr/bin/perl -w

use strict;
use warnings;
use threads;
use Test::More tests => 4;

use Wx;

my $app = Wx::App->new( sub { 1 } );
my $color = Wx::Colour->new( 0, 10, 20 );

use Devel::Peek;

my $t = threads->create
  ( sub {
        ok( 1, 'In thread' );
    } );
ok( 1, 'Before join' );
$t->join;
ok( 1, 'After join' );

END { ok( 1, 'At END' ) };
=========

crashes after test 3 (after join). The reason is that when the thread is
started the perl-space variables are cloned, but the C++-space objects
are not, so bot threads think they hold the last reference to $color,
both try to free the underlying C++ object => segmentation fault.

  There are various way to work around this; all involve keeping tracks
of created objects (Wx::Colour instances in this case) and doing something
special at clone time. This solves the problem once you decide what
special action you want to take.

  Options:
1 - the new thread is denied access to the parent thread objects
    (tried and works; you should not access wxThings from multiple
     threads anyway)
2 - clone the C++ instances; for each variable do (more or less)
    $var = Wx::Colour->new( $var );
3 - give the new thread access to the original thread's C++ objects
    avoiding the double free (i.e. do what happens now, except for the
    segfault).
4 - other options?

  Any suggestions?

Thanks!
Mattia

  The list of classes needing special treatment is:
Wx::DataObject
Wx::DropTarget
Wx::FileSystem
Wx::FSFile
Wx::GridCellAttr
Wx::GridCellAttr
Wx::GridCellEditor
Wx::GridCellRenderer
Wx::HtmlEasyPrinting
Wx::Printer
Wx::XmlResource
Wx::Accelerators
Wx::Bitmap
Wx::Brush
Wx::Cursor
Wx::Font
Wx::Icon
Wx::Image
Wx::ImageList
Wx::Locale
Wx::Palette
Wx::Pen

Re: [wxperl-users] Packaging Wx::PdfDocument

[Mark W. <ma...@ne...>]

Hi,

I have already copied your files into my folders to get things working, but
I was looking for a more elegant solution to move forward.

I started this email with suggestions but I changed my mind, let me have a
look at this and give you something to start with ...

Regards
Mark



-----Original Message-----
From: wxp...@li...
[mailto:wxp...@li...] On Behalf Of Mattia
Barbon
Sent: 02 August 2006 09:03 PM
To: wxp...@li...
Subject: Re: [wxperl-users] Packaging Wx::PdfDocument

On Tue, 1 Aug 2006 21:59:23 +0200
"Mark Wardell" <ma...@ne...> wrote:

  Hi,

> I have started to follow Wx::GLCanvas but I can come up short trying 
> to use *.xsp files.
> 

> 1) How can I use xsubppp.pl from a 3rd party wxPerl module such as 
> Wx::PdfDocument?
> 2) How do I include the core wxPerl typemap.xsp? (I am assuming I need 
> to)

  At the moment you can't; I will need to split the XS++ parser from core
wxPerl and release it on CPAN. But not today...

  For now you can simply include scripts/xsubppp.pl and related files in
Wx::PdfDocument. I know it is not a very good soution, but it works for now.

HTH
Mattia

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
Techsay panel and you'll get the chance to share your opinions on IT &
business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
wxperl-users mailing list
wxp...@li...
https://lists.sourceforge.net/lists/listinfo/wxperl-users

Re: [wxperl-users] Packaging Wx::PdfDocument

[Mattia B. <mat...@li...>]

On Tue, 1 Aug 2006 21:59:23 +0200
"Mark Wardell" <ma...@ne...> wrote:

  Hi,

> I have started to follow Wx::GLCanvas but I can come up short trying to use
> *.xsp files.
> 

> 1) How can I use xsubppp.pl from a 3rd party wxPerl module such as
> Wx::PdfDocument?
> 2) How do I include the core wxPerl typemap.xsp? (I am assuming I need to)

  At the moment you can't; I will need to split the XS++ parser
from core wxPerl and release it on CPAN. But not today...

  For now you can simply include scripts/xsubppp.pl and related files
in Wx::PdfDocument. I know it is not a very good soution, but it works
for now.

HTH
Mattia

Re: [wxperl-users] Packaging Wx::PdfDocument

[Mark W. <ma...@ne...>]

Hi,

I have started to follow Wx::GLCanvas but I can come up short trying to use
*.xsp files.

I have the following line in my XS file:
INCLUDE: perl ../../script/xsubppp.pl --typemap=../../typemap.xsp
XS/PdfDocument.xsp |

But I get the error:
Can't open perl script "../../script/xsubppp.pl": No such file or directory

So my immediate problems seem to be:

1) How can I use xsubppp.pl from a 3rd party wxPerl module such as
Wx::PdfDocument?
2) How do I include the core wxPerl typemap.xsp? (I am assuming I need to)

Any help withh this greatly appreciated.

Regards
Mark

Re: [wxperl-users] Alien::wxWidgets 0.19 / Wx 0.54 on opensuse 10.1

[Mark D. <mar...@zn...>]

Mattia,

wxPerl CVS installs perfectly now.

Alien::wxWidgets makes it easy for a c/c++ / Linux novice like myself to
get a working wxPerl without having to worry about avoiding conflicts
with installed wxGTK rpms etc.

Well done and thank you very much!

Mark


Mattia Barbon wrote:
> On Sun, 30 Jul 2006 19:46:15 +0100
> Mark Dootson <mar...@zn...> wrote:
> 
>   Hello,
> 
>> I build Wx. Tests complete OK except that the html and net component
>> libraries can't be found. Not too surprising as I haven't run ldconfig,
>> but I thought Alien would get around this for me.
> 
>   Reproduced.
>  
>> Investigating the problem, I find that the Alien libraries are installed
>> to the path:
>>
>> .../Alien/wxWidgets/gtk_2_6_3/lib
>>
>> In Wx::Mini ,
>> our $alien_key = 'gtk2_2_6_3_gcc_3_4';
>>
>> If I edit Wx::Mini to change $alien_key and the paths in sub _alien_path
>> to include 'gtk_2_6_3' then all works perfectly without any ldconfig
>> required. (Which is brilliant!)
>>
>> For info, the config that gets installed is ../Config/gtk2_2_6_3_gcc_3_4.pm
>>
>> So I guess the problem is that the install path should be getting set to
>> ../Alien/wxWidgets/gtk2_2_6_3_gcc_3_4/
> 
>   That would be ideal, but it is not trivial. I chose to leave alien_key
> as it is (it is as intended) and change the search path in _alien_path to
> use 'gtk_2_6_3'. Fix is in CVS. Please test and report.
> 
> Thanks!
> Mattia

Re: [wxperl-users] Alien::wxWidgets 0.19 / Wx 0.54 on opensuse 10.1

[Mattia B. <mat...@li...>]

On Sun, 30 Jul 2006 19:46:15 +0100
Mark Dootson <mar...@zn...> wrote:

  Hello,

> I build Wx. Tests complete OK except that the html and net component
> libraries can't be found. Not too surprising as I haven't run ldconfig,
> but I thought Alien would get around this for me.

  Reproduced.
 
> Investigating the problem, I find that the Alien libraries are installed
> to the path:
> 
> .../Alien/wxWidgets/gtk_2_6_3/lib
> 
> In Wx::Mini ,
> our $alien_key = 'gtk2_2_6_3_gcc_3_4';
> 
> If I edit Wx::Mini to change $alien_key and the paths in sub _alien_path
> to include 'gtk_2_6_3' then all works perfectly without any ldconfig
> required. (Which is brilliant!)
> 
> For info, the config that gets installed is ../Config/gtk2_2_6_3_gcc_3_4.pm
> 
> So I guess the problem is that the install path should be getting set to
> ../Alien/wxWidgets/gtk2_2_6_3_gcc_3_4/

  That would be ideal, but it is not trivial. I chose to leave alien_key
as it is (it is as intended) and change the search path in _alien_path to
use 'gtk_2_6_3'. Fix is in CVS. Please test and report.

Thanks!
Mattia

[wxperl-users] Alien::wxWidgets 0.19 / Wx 0.54 on opensuse 10.1

[Mark D. <mar...@zn...>]

Hi,

Sorry I haven't got a fix for this minor problem, but I do have a
workaround.

I install Alien::wxWidgets 0.19 on SuSE Linux 10.1. I choose to build
wxWidgets when prompted. Everything gets downloaded - everything works OK.

I build Wx. Tests complete OK except that the html and net component
libraries can't be found. Not too surprising as I haven't run ldconfig,
but I thought Alien would get around this for me.

Investigating the problem, I find that the Alien libraries are installed
to the path:

.../Alien/wxWidgets/gtk_2_6_3/lib

In Wx::Mini ,
our $alien_key = 'gtk2_2_6_3_gcc_3_4';

If I edit Wx::Mini to change $alien_key and the paths in sub _alien_path
to include 'gtk_2_6_3' then all works perfectly without any ldconfig
required. (Which is brilliant!)

For info, the config that gets installed is ../Config/gtk2_2_6_3_gcc_3_4.pm

So I guess the problem is that the install path should be getting set to
../Alien/wxWidgets/gtk2_2_6_3_gcc_3_4/


If there's anything I can test let me know.

Regards

Mark

Re: [wxperl-users] Addition to Sizer.xs

[Mattia B. <mat...@li...>]

On Wed, 26 Jul 2006 10:55:49 +0200
"Mark Wardell" <ma...@ne...> wrote:

> Hello,
> 
> I have added Wx::SizerItem->IsShown() which was missing.
> 
> I hope this is the correct format.

  Indeed it is.

Thanks, applied!
Mattia

Re: [wxperl-users] Packaging Wx::PdfDocument

[Mattia B. <mat...@li...>]

On Tue, 25 Jul 2006 21:26:25 +0200
"Mark Wardell" <ma...@ne...> wrote:

  Hello,

> Am I trying to use too much of wxPerl's customised build environment and
> should I steer more towards a vanilla XS environment? Or would it not be
> better to open up the wxPerl XS build environment to make it easier to
> create/wrap independent wxWidgets code such as this?
>  
> I have often looked at other wxWidgets code (such as wxAUI, wxIFM and
> wxTreeListCtrl ) and tried to integrate them into wxPerl but it is looks
> like such an obscure black art (to a lesser skilled XS hacker) that I really
> struggle to get started. Wx-Sample does not get me very far at all, I keep
> going back to it thinking I have missed something but it is very limited.

  Please see Wx::GLCanvas. This should answer at least some of your
questions.

Regards
Mattia

Re: [wxperl-users] Additions to Wx::Grid

[Mattia B. \<mattia\.barbon\@libero\.it\> <mat...@li...>]

  Hello,

> I have wrapped a few of the newer methods added to the Wx::Grid class:
> 
> Wx::Grid::EnableDragColMove
> Wx::Grid::GetCellOverflow
> Wx::Grid::GetDefaultCellOverflow
> Wx::Grid::SetDefaultCellOverflow

> I have not used #if WXPERL_W_VERSION_GE at all as I do not know when th=
ese
> methods were introduced, apart from EnableDragColMove which I believe w=
as
> just added now in 2.7.0.

  Looking into $WXWIDGETS/docs/changes.txt might help, as well as
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx 
 =3D> generic =3D> grid.h

> All tested and working on wxWidgets-MSW-2.7.0-rc1

  This patch will probably apply cleanly (I am not at home now to try);
a couple of suggestions: it is usually a good idea to attach patches as
well as inlining them (inlined =3D> quick to review, attached =3D> always=

safe from mail clients). I (and most open source projects I know) prefer
unified diffs instead of context diffs (the one you used). Context diff
is good, unified is better :-)

Thanks!
Mattia
=0A=0A=0A________________________________________________________________=
___=0ASalva ora il tuo preventivo Direct Line e assicurati lo sconto extr=
a 5+5% sulla polizza auto entro il 31 Luglio=0Ahttp://click.libero.it/dir=
ectline=0A

Re: [wxperl-users] Differences using wxWidgets 2.7.0

[Mattia B. <mat...@li...>]

On Tue, 25 Jul 2006 11:42:24 +0200
"Mark Wardell" <ma...@ne...> wrote:

  Hello,

> I have made these changes and generated this patch file using WinCvs (so I
> hope the format is correct) and the problems described below are now fixed.

> I do not know what side effects may be caused by these changes so please
> advise if these changes are the recommended way as per the 'Mattia' way of
> doing things.

  :-D
yes they are (after all, this is the way it is done in other
wxWindow-derived classes). The Create() method is missing, though (added).

  Applied.

Thanks!
Mattia

[wxperl-users] Packaging Wx::PdfDocument

[Mark W. <ma...@ne...>]

Hello,
 
I am having another go at packaging Wx::PdfDocument. Up until now I have
simply copied my source tree into ext/pdf and simply added --enable-pdf to
the standard wxPerl Makefile.PL command line arguments. But I would like to
package it properly so the community can benefit from the code.
 
Some of the shortcomings are:
 
If I use "Wx::build::MakeMaker::Core" I get an error that "script\pipe.pl"
cannot be found. Is it not possible to use this module? Should I simply use
"Wx::build::MakeMaker"?
 
I also include files such as "cpp/wxapi.h" and
"ext/print/cpp/pr_constants.cpp" and I have tried to use the xsp syntax and
xsubppp.pl but this depends on locating the wxPerl source files.
 
Do I need to create an ENV to locate the wxPerl source folders or would it
be better to copy more of the wxPerl source helper files to
/perl/site/lib/build+cpp?
 
Am I trying to use too much of wxPerl's customised build environment and
should I steer more towards a vanilla XS environment? Or would it not be
better to open up the wxPerl XS build environment to make it easier to
create/wrap independent wxWidgets code such as this?
 
I have often looked at other wxWidgets code (such as wxAUI, wxIFM and
wxTreeListCtrl ) and tried to integrate them into wxPerl but it is looks
like such an obscure black art (to a lesser skilled XS hacker) that I really
struggle to get started. Wx-Sample does not get me very far at all, I keep
going back to it thinking I have missed something but it is very limited.
 
PLEASE HELP, a few more pointers and I may finally crack this.
 
Many thanks
Mark

Re: [wxperl-users] Additions to Wx::Grid

[Mattia B. <mat...@li...>]

On Tue, 25 Jul 2006 12:49:13 +0200
"Mark Wardell" <ma...@ne...> wrote:

  Hi again,

> I have wrapped a few of the newer methods added to the Wx::Grid class:
> 
> Wx::Grid::EnableDragColMove
> Wx::Grid::GetCellOverflow
> Wx::Grid::GetDefaultCellOverflow
> Wx::Grid::SetDefaultCellOverflow

  Thanks, applied!

Mattia

[wxperl-users] Addition to Sizer.xs

[Mark W. <ma...@ne...>]

Hello,

I have added Wx::SizerItem->IsShown() which was missing.

I hope this is the correct format.

Regards
Mark

Index: Sizer.xs
===================================================================
RCS file: /cvsroot/wxperl/wxPerl/XS/Sizer.xs,v
retrieving revision 1.46
diff -u -r1.46 Sizer.xs
--- Sizer.xs	18 Jun 2006 11:13:14 -0000	1.46
+++ Sizer.xs	26 Jul 2006 08:46:28 -0000
@@ -498,6 +498,9 @@
 wxSizerItem::IsWindow()
 
 bool
+wxSizerItem::IsShown()
+
+bool
 wxSizerItem::IsSizer()
 

Re: [wxperl-users] Differences using wxWidgets 2.7.0

[Mark W. <ma...@ne...>]

John,

The SubclassFactory is exactly the mechanism I am using but it wasn't
working for subclasses of Wx::Grid. This was my hack to get around the
problem at the time.

But I have learnt quite a bit more about the XS layer, so you will see in
later mails I have now added code to Grid.XS to wrap the default constructor
(without parameters).

Thanks for your input.

Regards
Mark

-----Original Message-----
From: wxp...@li...
[mailto:wxp...@li...] On Behalf Of John Ralls
Sent: 25 July 2006 05:49 PM
To: wxperl-users
Subject: Re: [wxperl-users] Differences using wxWidgets 2.7.0


On Jul 25, 2006, at 12:16 AM, Mark Wardell wrote:

> Hello,
>
> Further investigation has revealed that $this->FindWindow( $name ) 
> returns a HASH ref for all other controls I have tested but ONLY 
> returns a SCALAR ref for controls of type Wx::Grid.
>
> I use this _BAD_ method of reblessing as a way of initialising 
> subclassed controls (as below) that I am loading from XRC and have no 
> other way of initialising them. SubclassFactory provides a way to 
> override the default
> ->new() method (with no parameters), but there is no other way to
> override a
> Create or Show to provide any further customisation. So I am forced to 
> manually Init each control in my OnInitDialog handler.
>
> if (my $grid = $self->FindWindow('DiscountGrid')) {
> 	bless $grid, 'Grid::DiscountGrid';
> 	print "Grid::DiscountGrid => $grid\n";
> 	$grid->InitControl( $self );
> }
>
> I suppose I could prevent the reblessing by simply declaring the 
> subclassing in the XRC definition but I would still have the problem 
> of FindWindow returned a SCALAR instead of a HASH and I need the HASH 
> as I use a lot of code like below:
>
> $self->{Option1} = $var;
>
> Can anyone offer any pointers where I can start looking or possible 
> alternative solutions.
>
> Thanks in advance.
>
> Mark

Yeah, http://wxperl.pvoice.org/kwiki/index.cgi?SubclassingXRC.

Perl's OO works, but it's a hack, and a bit fragile because it doesn't
enforce anything (which is why you can rebless in the first place, but also
why it will produce interesting results sometimes).  
If you declare
your subclass the documented way (either with use base or by putting the
superclass in the @ISA) then call SUPER::new in your own new (or don't write
a new at all) then your subclass object will be correctly blessed.

Regards,
John Ralls

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
Techsay panel and you'll get the chance to share your opinions on IT &
business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
wxperl-users mailing list
wxp...@li...
https://lists.sourceforge.net/lists/listinfo/wxperl-users

Re: [wxperl-users] Differences using wxWidgets 2.7.0

[John R. <jr...@ce...>]

On Jul 25, 2006, at 12:16 AM, Mark Wardell wrote:

> Hello,
>
> Further investigation has revealed that $this->FindWindow( $name )  
> returns a
> HASH ref for all other controls I have tested but ONLY returns a  
> SCALAR ref
> for controls of type Wx::Grid.
>
> I use this _BAD_ method of reblessing as a way of initialising  
> subclassed
> controls (as below) that I am loading from XRC and have no other  
> way of
> initialising them. SubclassFactory provides a way to override the  
> default
> ->new() method (with no parameters), but there is no other way to  
> override a
> Create or Show to provide any further customisation. So I am forced to
> manually Init each control in my OnInitDialog handler.
>
> if (my $grid = $self->FindWindow('DiscountGrid')) {
> 	bless $grid, 'Grid::DiscountGrid';
> 	print "Grid::DiscountGrid => $grid\n";
> 	$grid->InitControl( $self );
> }
>
> I suppose I could prevent the reblessing by simply declaring the  
> subclassing
> in the XRC definition but I would still have the problem of FindWindow
> returned a SCALAR instead of a HASH and I need the HASH as I use a  
> lot of
> code like below:
>
> $self->{Option1} = $var;
>
> Can anyone offer any pointers where I can start looking or possible
> alternative solutions.
>
> Thanks in advance.
>
> Mark

Yeah, http://wxperl.pvoice.org/kwiki/index.cgi?SubclassingXRC.

Perl's OO works, but it's a hack, and a bit fragile because it  
doesn't enforce anything (which is why you can rebless in the first  
place, but also why it will produce interesting results sometimes).  
If you declare
your subclass the documented way (either with use base or by putting  
the superclass in the @ISA)
then call SUPER::new in your own new (or don't write a new at all)  
then your subclass object will be correctly blessed.

Regards,
John Ralls

[wxperl-users] Additions to Wx::Grid

[Mark W. <ma...@ne...>]

Hi Mattia,

I have wrapped a few of the newer methods added to the Wx::Grid class:

Wx::Grid::EnableDragColMove
Wx::Grid::GetCellOverflow
Wx::Grid::GetDefaultCellOverflow
Wx::Grid::SetDefaultCellOverflow

I have not used #if WXPERL_W_VERSION_GE at all as I do not know when these
methods were introduced, apart from EnableDragColMove which I believe was
just added now in 2.7.0.

All tested and working on wxWidgets-MSW-2.7.0-rc1

Cheers
Mark

<patch>
*** Grid.xs	15 Sep 2005 21:08:54 -0000	1.25
--- Grid.xs	25 Jul 2006 10:30:02 -0000
***************
*** 171,176 ****
--- 189,198 ----
      bool enable
  
  void
+ wxGrid::EnableDragColMove( enable = true )
+     bool enable
+ 
+ void
  wxGrid::EnableDragColSize( enable = true )
      bool enable
  
***************
*** 225,230 ****
--- 247,257 ----
      int row
      int col
  
+ bool
+ wxGrid::GetCellOverflow( row, col )
+     int row
+     int col
+ 
  wxGridCellRenderer*
  wxGrid::GetCellRenderer( row, col )
      int row
***************
*** 310,315 ****
--- 337,345 ----
    OUTPUT:
      RETVAL
  
+ bool
+ wxGrid::GetDefaultCellOverflow( )
+ 
  wxColour*
  wxGrid::GetDefaultCellTextColour()
    CODE:
***************
*** 784,789 ****
--- 814,823 ----
      THIS->SetDefaultCellFont( *font );
  
  void
+ wxGrid::SetDefaultCellOverflow( oflo )
+     bool oflo
+ 
+ void
  wxGrid::SetDefaultCellTextColour( colour )
      wxColour colour
  
</patch>

Re: [wxperl-users] Differences using wxWidgets 2.7.0

[Mark W. <ma...@ne...>]

Hi Mattia,

I have made these changes and generated this patch file using WinCvs (so I
hope the format is correct) and the problems described below are now fixed.

I do not know what side effects may be caused by these changes so please
advise if these changes are the recommended way as per the 'Mattia' way of
doing things.

Many thanks
Mark

*** Grid.xs	15 Sep 2005 21:08:54 -0000	1.25
--- Grid.xs	25 Jul 2006 08:59:53 -0000
***************
*** 11,16 ****
--- 11,17 ----
 
############################################################################
#
  
  #include <wx/grid.h>
+ #include "cpp/overload.h"
  
  MODULE=Wx PACKAGE=Wx::GridCellCoords
  
***************
*** 44,51 ****
  
  MODULE=Wx PACKAGE=Wx::Grid
  
  wxGrid*
! wxGrid::new( parent, id, pos = wxDefaultPosition, size = wxDefaultSize,
style = wxWANTS_CHARS, name = wxPanelNameStr )
      wxWindow* parent
      wxWindowID id
      wxPoint pos
--- 45,69 ----
  
  MODULE=Wx PACKAGE=Wx::Grid
  
+ void
+ new( ... )
+   PPCODE:
+     BEGIN_OVERLOAD()
+         MATCH_VOIDM_REDISP( newDefault )
+         MATCH_ANY_REDISP( newFull )
+     END_OVERLOAD( "Wx::Grid::new" )
+ 
+ wxGrid*
+ newDefault( CLASS )
+     PlClassName CLASS
+   CODE:
+     RETVAL = new wxGrid();
+     wxPli_create_evthandler( aTHX_ RETVAL, CLASS );
+   OUTPUT: RETVAL
+ 
  wxGrid*
! newFull( CLASS, parent, id, pos = wxDefaultPosition, size = wxDefaultSize,
style = wxWANTS_CHARS, name = wxPanelNameStr )
!     PlClassName CLASS
      wxWindow* parent
      wxWindowID id
      wxPoint pos



-----Original Message-----
From: wxp...@li...
[mailto:wxp...@li...] On Behalf Of Mark
Wardell
Sent: 25 July 2006 09:17 AM
To: 'Mattia Barbon'
Cc: 'wxperl-users'
Subject: Re: [wxperl-users] Differences using wxWidgets 2.7.0

Hello,

Further investigation has revealed that $this->FindWindow( $name ) returns a
HASH ref for all other controls I have tested but ONLY returns a SCALAR ref
for controls of type Wx::Grid.

I use this _BAD_ method of reblessing as a way of initialising subclassed
controls (as below) that I am loading from XRC and have no other way of
initialising them. SubclassFactory provides a way to override the default
->new() method (with no parameters), but there is no other way to 
->override a
Create or Show to provide any further customisation. So I am forced to
manually Init each control in my OnInitDialog handler.

if (my $grid = $self->FindWindow('DiscountGrid')) {
	bless $grid, 'Grid::DiscountGrid';
	print "Grid::DiscountGrid => $grid\n";
	$grid->InitControl( $self );
}

I suppose I could prevent the reblessing by simply declaring the subclassing
in the XRC definition but I would still have the problem of FindWindow
returned a SCALAR instead of a HASH and I need the HASH as I use a lot of
code like below:

$self->{Option1} = $var;

Can anyone offer any pointers where I can start looking or possible
alternative solutions.

Thanks in advance.

Mark

-----Original Message-----
From: Mattia Barbon [mailto:mat...@li...]
Sent: 24 July 2006 09:13 PM
To: Mark Wardell
Cc: 'wxperl-users'
Subject: Re: [wxperl-users] Differences using wxWidgets 2.7.0

On Mon, 24 Jul 2006 19:30:41 +0200
"Mark Wardell" <ma...@ne...> wrote:

  Hello,

> I have some code as below:
>  
>  if (my $grid = $dialog->FindWindow(MyGrid')) {
>   bless $grid, 'Grid::MyGrid';
>   print "Grid::MyGrid => $grid\n";
> }
>  
> Using wxPerl 0.54 on wxWidgets 2.6.3 I get:
> Grid::MyGrid => Grid::MyGrid=HASH(0x7015a00)
>  
> Using wxPerl 0.54 on wxWidgets 2.7.0 I get: 
> Grid::MyGrid => Grid::MyGrid=SCALAR(........)

  Honestly I have no idea why this should be so; the different wxWidgets
version should not influence this.

Regards
Mattia

P.S.: reblessing like this is _BAD_


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's
Techsay panel and you'll get the chance to share your opinions on IT &
business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
wxperl-users mailing list
wxp...@li...
https://lists.sourceforge.net/lists/listinfo/wxperl-users

Re: [wxperl-users] Differences using wxWidgets 2.7.0

[Mark W. <ma...@ne...>]

Hello,

Further investigation has revealed that $this->FindWindow( $name ) returns a
HASH ref for all other controls I have tested but ONLY returns a SCALAR ref
for controls of type Wx::Grid.

I use this _BAD_ method of reblessing as a way of initialising subclassed
controls (as below) that I am loading from XRC and have no other way of
initialising them. SubclassFactory provides a way to override the default
->new() method (with no parameters), but there is no other way to override a
Create or Show to provide any further customisation. So I am forced to
manually Init each control in my OnInitDialog handler.

if (my $grid = $self->FindWindow('DiscountGrid')) {
	bless $grid, 'Grid::DiscountGrid';
	print "Grid::DiscountGrid => $grid\n";
	$grid->InitControl( $self );
}

I suppose I could prevent the reblessing by simply declaring the subclassing
in the XRC definition but I would still have the problem of FindWindow
returned a SCALAR instead of a HASH and I need the HASH as I use a lot of
code like below:

$self->{Option1} = $var;

Can anyone offer any pointers where I can start looking or possible
alternative solutions.

Thanks in advance.

Mark

-----Original Message-----
From: Mattia Barbon [mailto:mat...@li...] 
Sent: 24 July 2006 09:13 PM
To: Mark Wardell
Cc: 'wxperl-users'
Subject: Re: [wxperl-users] Differences using wxWidgets 2.7.0

On Mon, 24 Jul 2006 19:30:41 +0200
"Mark Wardell" <ma...@ne...> wrote:

  Hello,

> I have some code as below:
>  
>  if (my $grid = $dialog->FindWindow(MyGrid')) {
>   bless $grid, 'Grid::MyGrid';
>   print "Grid::MyGrid => $grid\n";
> }
>  
> Using wxPerl 0.54 on wxWidgets 2.6.3 I get:
> Grid::MyGrid => Grid::MyGrid=HASH(0x7015a00)
>  
> Using wxPerl 0.54 on wxWidgets 2.7.0 I get: 
> Grid::MyGrid => Grid::MyGrid=SCALAR(........)

  Honestly I have no idea why this should be so; the different wxWidgets
version should not influence this.

Regards
Mattia

P.S.: reblessing like this is _BAD_