wxperl-users — For wxPerl users

[wxperl-users] ListCrtl Events

[Marcus <li...@wo...>]

I get an undefined subroutine when using
"Wx::Event::EVT_LIST_ITEM_RIGHT_CLICK". Is it implemented?

EVT_LIST_ITEM_SELECTED works fine. I'm trying to have two separate
events for a list:
1) single left-click
2) right-click (to open a pop-up menu)

Are there any other ways currently available to achieve this?
(By default it seems a right click is also processed as as a list item
selection.)

Thanks,

Marcus

Re: [wxperl-users] WX::FileConfig

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

> I tried the following inside OnInit, but I don't see a file in the
> application directory. Has it been created in some mysterious place?
> (It didn't write to the registry).
If I pass an absolute file name, it works; looking at the docs for
wxConfigBase::wxConfigBase I see that there is a wxCONFIG_USE_RELATIVE_PATH 
flag; if you want a relative file name this is what you need.

Regards
Mattia

RE: [wxperl-users] wxPerl and Perl 5.8 threads

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

> Build notes:
> 
> > > I was unable to link the XRC module for some reason.  I suspect some
> > > inconsistency in the build process for wxWindows, but haven't
> > sorted it out
> > > yet.  Don't really care so much about it, just mentioning in passing.
> > It'd be nice to discover why, how did you compile wxWIndows/wxPerl?
> > What if you follow the updated build instructions at
> >
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wxperl/wxPerl/docs/install.tx
> t?rev=1.12&content-type=text/vnd.viewcvs-markup
> 
> Ah, well, that makes a BIG difference.  The install.txt file that comes with
> the wxPerl 0.10 source archive doesn't have quite so much detail in it and I
> didn't think to double-check online.  I was building via the IDE as well,
I know its not your fault... I, personally, wouldn't have found it
( if I didn't knew it already )

> not using the command line (occasionally that is dangerous, as the makefile
> isn't automatically generated).
> 
> So, OK, I loaded a fresh copy of Wx-0.10 source and started from scratch to
> catch all my notes (which I had collected earlier and then lost):
> 
> When running Makefile.PL there are some GetOptions() variables that need to
> be initialized in build/wxConfig.pm to get rid of some warnings:
> 	$extra_libs   = '';
> 	$extra_cflags = '';
> Probably others as well, but these are the ones that made noise for me.
> Obviously this isn't crucial.  There is also a warning:
> 	Subroutine MY::post_initialize redefined
> 		at C:/TEMP/Wx0.10/build/wxConfig.pm line 114.
> which probably isn't going away.
This is fixed in CVS

> I get an error regarding wxGetFontFromUser not being available.  In
> XS/FontDialog.xs it is wrapped with #if WXPERL_W_VERSION_GE( 2, 3, 2 ).  I
> have wxWindows 2.3.2 (from a development snapshot, not from CVS) but it
> doesn't have wxGetFontFromUser, so I change the conditional to check for
> 2.3.3 and move on (I suppose I'll get around to downloading another snapshot
> at some point).
as it is this
 
> Similarly for IsFixedWidth in GDI.C.  Changed 2.3.2 to 2.3.3 and moved on.
and this

> When I run the nmake test I get:
> 
> Failed Test       Stat Wstat Total Fail  Failed  List of Failed
> ---------------------------------------------------------------
> t\1_load.t           2   512     1    1 100.00%  1
> t\2_inheritance.t    2   512    ??   ??       %  ??
> t\3_attr.t           2   512     1    1 100.00%  1
>
> The error appears to be that it can't locate Wx/Grid.pm.  The Grid DLL is
> built, but Grid.pm isn't in the path during the test.  Haven't dug any
> deeper yet.
This is a bug in wxPerl build system that has been uncovered by the new
MakeMaker in 5.8.0; it has been fixed in CVS

> > > So all (or most) of the sample programs run.  The demo runs except for
> > > whatever I had to comment out because XRC isn't there (I
> > think).  All good.
> > You should not need to comment anything out, BTW
> 
> Actually, I went back and re-ran this and there are a number of things not
> connecting right now.  Wx::Help.pm and Wx::Html.pm aren't available for some
> reason (didn't install?  depend on XRC?).  So I had to comment out a bunch
The above bug

> of stuff to get the demo to run at all.  Again, I haven't taken the time to
> track this down.  I'm using WxPerl 0.10 (from a source download, not from
> CVS).
If you want it to build with 5.8.0 you need to use CVS

> I'm guessing this is similar to the issue with Grid.pm, as I can find
> HTML.dll in the installed tree but not HTML.pm.
Yes, this is the same problem

Regards
Mattia

RE: [wxperl-users] wxPerl and Perl 5.8 threads

[Marc M. A. <mm...@Do...>]

Build notes:

> > I was unable to link the XRC module for some reason.  I suspect some
> > inconsistency in the build process for wxWindows, but haven't
> sorted it out
> > yet.  Don't really care so much about it, just mentioning in passing.
> It'd be nice to discover why, how did you compile wxWIndows/wxPerl?
> What if you follow the updated build instructions at
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wxperl/wxPerl/docs/install.tx
t?rev=1.12&content-type=text/vnd.viewcvs-markup

Ah, well, that makes a BIG difference.  The install.txt file that comes with
the wxPerl 0.10 source archive doesn't have quite so much detail in it and I
didn't think to double-check online.  I was building via the IDE as well,
not using the command line (occasionally that is dangerous, as the makefile
isn't automatically generated).

So, OK, I loaded a fresh copy of Wx-0.10 source and started from scratch to
catch all my notes (which I had collected earlier and then lost):

When running Makefile.PL there are some GetOptions() variables that need to
be initialized in build/wxConfig.pm to get rid of some warnings:
	$extra_libs   = '';
	$extra_cflags = '';
Probably others as well, but these are the ones that made noise for me.
Obviously this isn't crucial.  There is also a warning:
	Subroutine MY::post_initialize redefined
		at C:/TEMP/Wx0.10/build/wxConfig.pm line 114.
which probably isn't going away.

I get an error regarding wxGetFontFromUser not being available.  In
XS/FontDialog.xs it is wrapped with #if WXPERL_W_VERSION_GE( 2, 3, 2 ).  I
have wxWindows 2.3.2 (from a development snapshot, not from CVS) but it
doesn't have wxGetFontFromUser, so I change the conditional to check for
2.3.3 and move on (I suppose I'll get around to downloading another snapshot
at some point).

Similarly for IsFixedWidth in GDI.C.  Changed 2.3.2 to 2.3.3 and moved on.

When I run the nmake test I get:

Failed Test       Stat Wstat Total Fail  Failed  List of Failed
---------------------------------------------------------------
t\1_load.t           2   512     1    1 100.00%  1
t\2_inheritance.t    2   512    ??   ??       %  ??
t\3_attr.t           2   512     1    1 100.00%  1

The error appears to be that it can't locate Wx/Grid.pm.  The Grid DLL is
built, but Grid.pm isn't in the path during the test.  Haven't dug any
deeper yet.

> > So all (or most) of the sample programs run.  The demo runs except for
> > whatever I had to comment out because XRC isn't there (I
> think).  All good.
> You should not need to comment anything out, BTW

Actually, I went back and re-ran this and there are a number of things not
connecting right now.  Wx::Help.pm and Wx::Html.pm aren't available for some
reason (didn't install?  depend on XRC?).  So I had to comment out a bunch
of stuff to get the demo to run at all.  Again, I haven't taken the time to
track this down.  I'm using WxPerl 0.10 (from a source download, not from
CVS).

I'm guessing this is similar to the issue with Grid.pm, as I can find
HTML.dll in the installed tree but not HTML.pm.

-----------------------------------------------------------------------

Usage (threading) notes:

> The problem here is that wxWindows expects threads to be worker threads;
> they should not create windows; they should communicate with the
> main thread
> via Wx::PostMessage (see the threads sample in the demo).

Well, this is what I figured...

> > Which naturally leads to the idea of posting  windows events
> > that are commands to create windows and so forth.  Which ends up looking
> > like an event-driven program and not a multi-threaded program.

...but that leaves me frustrated.  Not necessarily at WxPerl.  I think I'm
frustrated with the Perl 5.8 threading model (which is apparently the one
that is being implemented in Parrot for Perl 6).  It doesn't provide shared
data by default.  It may actually be implemented using threads, but it has
the user experience of using processes.  But that's a personal problem. ;)

I have to admit, it's been a while since I did any low-level GUI
programming.  I'm thinking that these problems may in fact be characteristic
of some of the environments I've had to use.  Seems to me I've had to do
exactly what you say...

> Well, if you have a long computation to run in the background, threads
> are a much better solution than a Wx::Timer or idle events...

...putting just the computations in the background and having all the actual
window-related stuff happen in the foreground.  Then again, I've used at
least one system where all window-related code could occur in any thread
(with suitable locking of code where necessary).

> I know Vadim Zeitlin (one of the core wxWindows developers) has a
wxGUIThread
> (a thread that can create windows and dispatch messages to them) in his
TODO
> since (at least) 2 years. Of course making it work in at least
> wxGTK (variuos UNIX flavours), wxMSW (Win32) and wxMac (OS9 hasn't
> preemptive thread, but OSX, AFAIK has), requires a lot of work.

You betcha.  I don't think that this applies to Perl, though, unless you're
going to write a wxPerl overlay that starts a wxGUIThread and then
instantiates a Perl interpreter within it.  Which I guess would be
possible...but you would still need to make all the window objects shared (I
think).

Ah, well, none of this is critical.  Just curious (as usual) as to what will
work and what won't.  The Perl 5.8 dev group wanted feedback on how the
release candidates were working and I thought that this might be an
interesting experiment.  I have not, as yet, sent them any feedback on this.

marc

[wxperl-users] WX::FileConfig

[Marcus <li...@wo...>]

I tried the following inside OnInit, but I don't see a file in the
application directory. Has it been created in some mysterious place?
(It didn't write to the registry).

my $pconfig = Wx::FileConfig->new("conftest");
Wx::ConfigBase::Set($pconfig);
my $config = Wx::ConfigBase::Get;
$config->Write( "Fontface", "Arial" );

I also tried adding this first:
$this->SetAppName( "myapp" );
$this->SetVendorName( "mycomp" );

I also tried doing ...new("app","vendor","conftest")...

What's missing?

Thanks,

Marcus

Re: [wxperl-users] wxPerl and Perl 5.8 threads

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

> Just on a lark I decided yesterday I would try to write something using Perl
> 5.8 and wxPerl.  I compiled everything up on Windows 2000 with VC++ 6 and
> everything mostly worked.
> 
> I was unable to link the XRC module for some reason.  I suspect some
> inconsistency in the build process for wxWindows, but haven't sorted it out
> yet.  Don't really care so much about it, just mentioning in passing.
It'd be nice to discover why, how did you compile wxWIndows/wxPerl?
What if you follow the updated build instructions at
http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/wxperl/wxPerl/docs/install.txt?rev=1.12&content-type=text/vnd.viewcvs-
markup

> So all (or most) of the sample programs run.  The demo runs except for
> whatever I had to comment out because XRC isn't there (I think).  All good.
You should not need to comment anything out, BTW

> Then I start to write code.  I copy the minimal frame code and then I start
> building other windows to which I attach threads.  My goal is to write a
> prime number sieve (see example attached to Perl 5.8 thread tutorial) with
> each sieve thread attached to a different window so that the numbers crawl
> down a pipeline of windows.  Visually appealing, and my usual test program
> for GUI & threads.  So I'm easily amused, so what?
> 
> At this point I start finding things aren't quite so good.  The problems
> being mostly, I believe, related to the way Perl 5.8 threads are
> implemented.  Not to overstate the obvious, but regardless of implementation
> detail, they behave more like *NIX forked processes than threads, the
> important point being duplication of the data space.
> 
> I am able to create the child windows and have them display OK.  After
> mulling this over a bit, I find that I'm not surprised.  After all, the
> Wx::Window object gets copied to the new ithread and this will include the
> Windows handle, which is an integer essentially and therefore copies OK.  So
> when I create the new child window and pass it the (copy of the) Wx::Window
> parent window object there is a level where Windows API calls are made with
> the copied window handle and Windows deals with this OK.
> 
> Unfortunately, the child windows never get updated.  The first one does, but
> I'm creating that in the main thread.  The rest of the Wx child window
> objects are created in child threads that are in separate data spaces.  So
> the event handler implemented in the main thread gets an event and can't
> resolve it because the event is for a window ID that has no corresponding
> window object in the main thread.  I imagine it just gets thrown away.
> 
> I tried marking the child window objects as shared but that doesn't work.
> If I use the shared attribute I get a crash.  If I use the share() function
> after the creation of the window object I get an error message saying I
> can't do that, the object won't allow it.
The problem here is that wxWindows expects threads to be worker threads;
they should not create windows; they should communicate with the main thread
via Wx::PostMessage (see the threads sample in the demo).

> I thought about how the Perl 5.8 threads are set up and it seems like to go
> with the flow, as it were, I would have to create a queue for the main
> thread and have the main thread process 'commands' from that queue (as
> opposed to the Win32 queue events).  I would then have the child threads
> send commands to the main threads instead of creating the windows directly.
> The main thread sould grab a command and then build a child window based on
> that command.  The windows would all get constructed in the main thread.

> Of course, I can't do that directly because the main thread is tied up in
> the event loop.  Which naturally leads to the idea of posting windows events
> that are commands to create windows and so forth.  Which ends up looking
> like an event-driven program and not a multi-threaded program.  Why bother,
> eh?
Well, if you have a long computation to run in the background, threads
are a much better solution than a Wx::Timer or idle events...

> So I'm wondering if wxPerl is going to support the Perl 5.8 threading model.
> It seems like there's a lot of goop necessary to make that happen.  For
> example, there are per-thread static data structures for XS files.  And
I don't think the statics are a big problem; they surely are not causing
the problems you are experiencing. The problem is that (currently) wxWindows
does not support a thread other than the main thread creating windows and
dispatching events.

> there's the whole issue of how to make window objects created in child
> threads work with the main thread event loop...or not as the case may be.
> And I suspect that these issues will vary considerably between platforms.
I know Vadim Zeitlin (one of the core wxWindows developers) has a wxGUIThread
(a thread that can create windows and dispatch messages to them) in his TODO
since (at least) 2 years. Of course making it work in at least
wxGTK (variuos UNIX flavours), wxMSW (Win32) and wxMac (OS9 hasn't
preemptive thread, but OSX, AFAIK has), requires a lot of work.

Regards
Mattia

Re: [wxperl-users] IniConfig, Fileconfig

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

> Are Wx::IniConfig and Wx::FileConfig implemented?
Wx::FileCOnfig yes, Wx::IniConfig no; Wx::FileCOnfig is just
a generic implementation of Wx::IniConfig (Wx::IniConfig uses Win32 API,
Wx::FileConfig does not, and works on other platforms too)

> If so, how do you specify them instead of the system default
> (Wx::RegConfig in this case)?
> The config I have is too large for the registry and should be editable
> in a text editor.
> 
> When I use BaseConfig everything works fine, but of course it writes to
> the registry on Windows.
Wx::ConfigBase::Set( Wx::FileConfig->new( ... ) );

HTH
Mattia

[wxperl-users] wxPerl and Perl 5.8 threads

[Marc M. A. <mm...@Do...>]

Just on a lark I decided yesterday I would try to write something using Perl
5.8 and wxPerl.  I compiled everything up on Windows 2000 with VC++ 6 and
everything mostly worked.

I was unable to link the XRC module for some reason.  I suspect some
inconsistency in the build process for wxWindows, but haven't sorted it out
yet.  Don't really care so much about it, just mentioning in passing.

So all (or most) of the sample programs run.  The demo runs except for
whatever I had to comment out because XRC isn't there (I think).  All good.

Then I start to write code.  I copy the minimal frame code and then I start
building other windows to which I attach threads.  My goal is to write a
prime number sieve (see example attached to Perl 5.8 thread tutorial) with
each sieve thread attached to a different window so that the numbers crawl
down a pipeline of windows.  Visually appealing, and my usual test program
for GUI & threads.  So I'm easily amused, so what?

At this point I start finding things aren't quite so good.  The problems
being mostly, I believe, related to the way Perl 5.8 threads are
implemented.  Not to overstate the obvious, but regardless of implementation
detail, they behave more like *NIX forked processes than threads, the
important point being duplication of the data space.

I am able to create the child windows and have them display OK.  After
mulling this over a bit, I find that I'm not surprised.  After all, the
Wx::Window object gets copied to the new ithread and this will include the
Windows handle, which is an integer essentially and therefore copies OK.  So
when I create the new child window and pass it the (copy of the) Wx::Window
parent window object there is a level where Windows API calls are made with
the copied window handle and Windows deals with this OK.

Unfortunately, the child windows never get updated.  The first one does, but
I'm creating that in the main thread.  The rest of the Wx child window
objects are created in child threads that are in separate data spaces.  So
the event handler implemented in the main thread gets an event and can't
resolve it because the event is for a window ID that has no corresponding
window object in the main thread.  I imagine it just gets thrown away.

I tried marking the child window objects as shared but that doesn't work.
If I use the shared attribute I get a crash.  If I use the share() function
after the creation of the window object I get an error message saying I
can't do that, the object won't allow it.

I thought about how the Perl 5.8 threads are set up and it seems like to go
with the flow, as it were, I would have to create a queue for the main
thread and have the main thread process 'commands' from that queue (as
opposed to the Win32 queue events).  I would then have the child threads
send commands to the main threads instead of creating the windows directly.
The main thread sould grab a command and then build a child window based on
that command.  The windows would all get constructed in the main thread.

Of course, I can't do that directly because the main thread is tied up in
the event loop.  Which naturally leads to the idea of posting windows events
that are commands to create windows and so forth.  Which ends up looking
like an event-driven program and not a multi-threaded program.  Why bother,
eh?

So I'm wondering if wxPerl is going to support the Perl 5.8 threading model.
It seems like there's a lot of goop necessary to make that happen.  For
example, there are per-thread static data structures for XS files.  And
there's the whole issue of how to make window objects created in child
threads work with the main thread event loop...or not as the case may be.
And I suspect that these issues will vary considerably between platforms.

Marc M. Adkins

[wxperl-users] IniConfig, Fileconfig

[Marcus <li...@wo...>]

Are Wx::IniConfig and Wx::FileConfig implemented?

If so, how do you specify them instead of the system default
(Wx::RegConfig in this case)?
The config I have is too large for the registry and should be editable
in a text editor.

When I use BaseConfig everything works fine, but of course it writes to
the registry on Windows.

Thanks,

Marcus Friedlaender

Re: [wxperl-users] Re: Updated build instructions - care to review?

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

> Mattia,
> 
>    I saw the docs. It's very nice, show every thing, specially the problems
> for the FakeConfig to build with MingW, the commands to build the wxWindows
> DLLs, but I have some things to add:
Good, I like user feedback on this topic :-)

>   - Tell to don't forget to set the MinGW version in the file
> z:/path/to/wx/src/makeg95.env
>     > MINGW32VERSION=2.95.3
>     Or you CAN'T compile wxWindows with MingW 1.1
>     With the previus version of MinGW you have to fix to much bugs to
> compile wxWindows & wxPerl, just impossible.
I didn't know that; for me, (GCC 2.95.3-6) it works without changing the
version; strange, will investigate

>   - In the commands to compile with MinGW, you use 'dmake', but you don't
> say anything about this in the comments.
>     Put the URL too, like the extra:
> http://www.cpan.org/authors/id/GSAR/dmake-4.1pl1-win32.zip
Good catch!

>   - The only missed command now is:
>     > SET MINGWDIR=c:\mingw
>     This is about the MinGW installation, but we have to think in who don't
> know MingW, or compilers too. :-P
Why do you need this? What does happen if you don't set it?
Personally, I never have set it (even when I used Win95).

>   - Put the MinGW URL, to be more easy for the user:
> http://prdownloads.sourceforge.net/mingw/MinGW-1.1.tar.gz
>     Some peoples know MinGW from Cygwin or the Perl build instructions, are
> using old version and don't know about MinGW 1.1 and the project inside
> sourceforge.
Fixed

Thanks!
Mattia

Re: [wxperl-users] Validators

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

> Hi Marcus,
> Validators are similar to, but not the same as, Perl/Tk.  As you say, in
> Perl/Tk, changes to the underlying variable immediately appear in the Tk
> widget - a great feature but also a source of problems, as you have found.
> 
> However, I think that Wx validators only transfer the data to the control
> when $window->TransferDataToWindow is called, and back again when
> $window->TransferDataFromWindow is called. (I'll check this out with some
> trials).
This is correct.

> For wxDialogs, these are both called automatically as part of Dialog
> initialisation and dismissal (TransferDataFromWindow is only called when the
> modal result is wxID_OK, I think).
And this too.
BTW, there is a wxValidator overview in the wxWindows manual
(Topics overview -> wxValidator overview; I am not sure how much C++=oriented
 it is, but may be worth reading, especially "How validators interact with dialogs")
 
> One feature I'm thinking of implementing is the ability to supply a callback
> for the TransferToWindow and TransferFromWindow wxValidator methods, so that
> we can supply data from object methods and pump data back into object
> methods, rather than having to rely on variable addresses. (Most of my Perl
> code is OO, and so I want to be able to use property accessors, rather than
> property addresses).
This looks like a nice feature, BTW

Regards
Mattia

[wxperl-users] Re: Updated build instructions - care to review?

[Graciliano M. P. \(V. Sites\) <gm...@vi...>]

Mattia,

   I saw the docs. It's very nice, show every thing, specially the problems
for the FakeConfig to build with MingW, the commands to build the wxWindows
DLLs, but I have some things to add:

  - Tell to don't forget to set the MinGW version in the file
z:/path/to/wx/src/makeg95.env
    > MINGW32VERSION=2.95.3
    Or you CAN'T compile wxWindows with MingW 1.1
    With the previus version of MinGW you have to fix to much bugs to
compile wxWindows & wxPerl, just impossible.

  - In the commands to compile with MinGW, you use 'dmake', but you don't
say anything about this in the comments.
    Put the URL too, like the extra:
http://www.cpan.org/authors/id/GSAR/dmake-4.1pl1-win32.zip

  - The only missed command now is:
    > SET MINGWDIR=c:\mingw
    This is about the MinGW installation, but we have to think in who don't
know MingW, or compilers too. :-P

  - Put the MinGW URL, to be more easy for the user:
http://prdownloads.sourceforge.net/mingw/MinGW-1.1.tar.gz
    Some peoples know MinGW from Cygwin or the Perl build instructions, are
using old version and don't know about MinGW 1.1 and the project inside
sourceforge.


Graciliano M. P.

[wxperl-users] wxPerl Compiling Guide & Docs

[Graciliano M. P. \(V. Sites\) <gm...@vi...>]

The compiling guide for wxPerl was updated. The brocken link for the
'extra.zip' was fixed.

http://wxperl.virtuasites.com.br/
http://wxperl.virtuasites.com.br/docs

Sorry if the server was down this week, the datacenter was making some
updates in the servers.

Graciliano M. P.

Re: [wxperl-users] Get Window by name - one more thing

[James L. <jl...@bi...>]

Hi Marcus,
Forgot to say that in VB one could use the built in SendKeys VB function to
send the keystrokes.

Not sure how one can achieve this in Perl and/or wxWindows - ideas, anyone?

Oh - found this by doing a Google groups search for "perl sendkeys"

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
#!/usr/local/bin/perl -w

use Win32::OLE;
my $objPerlCOM = new Win32::OLE("WScript.Shell") ||
 die "Can't create PerlCOM object\n";

Of course you'll need the Windows Script Host installed.

$objPerlCOM->AppActivate(377);

As I'm sure you'll know, put the correct pid here.  For me, I opened up
notepad and found its pid to be 377 at that time.

$objPerlCOM->SendKeys('abcdef');
sleep 4;
$objPerlCOM->SendKeys('%fx');

^^^^^^^^^^^^^^^^^^^^

Thanks to jimbo (ji...@so...) for this!

I haven't tried the above, so can't guarantee it works - but there were
several other promising threads resulting from the above search.

James

----- Original Message -----
From: "Marcus" <li...@wo...>
To: <wxp...@li...>
Sent: 05 July 2002 13:34
Subject: [wxperl-users] Get Window by name


> Does anybody know how to get a window by name?
>
> I'm working on the following: I have a dialog which collects user input
> which needs to be pasted to an application of the user's choice. I
> think I need to get the Window by name, e.g. "Notepad", or "Some
> application", then copy and paste via the clipboard. To paste I need to
> make the application's window active.
>
> Any ideas if there's a way in Perl?
>
> Thanks,
>
> Marcus
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Bringing you mounds of caffeinated joy.
> http://thinkgeek.com/sf
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users

Re: [wxperl-users] Validators

[James L. <jl...@bi...>]

Hi Marcus,
Validators are similar to, but not the same as, Perl/Tk.  As you say, in
Perl/Tk, changes to the underlying variable immediately appear in the Tk
widget - a great feature but also a source of problems, as you have found.

However, I think that Wx validators only transfer the data to the control
when $window->TransferDataToWindow is called, and back again when
$window->TransferDataFromWindow is called. (I'll check this out with some
trials).

For wxDialogs, these are both called automatically as part of Dialog
initialisation and dismissal (TransferDataFromWindow is only called when the
modal result is wxID_OK, I think).

Hence, using wxValidators we have an inbuilt mechanism whereby our variables
are only updated when the user OK's the window (and validation is
implemented, too!).

I ended up having to wrap my Tk widgets and windows in my own objects to
achieve this sort of functionality for a large (200 screens plus) system
I've been developing/supporting.  If only I'd known about wxWindows at the
time...  It's so much more consistent in its approach than Tk...

One feature I'm thinking of implementing is the ability to supply a callback
for the TransferToWindow and TransferFromWindow wxValidator methods, so that
we can supply data from object methods and pump data back into object
methods, rather than having to rely on variable addresses. (Most of my Perl
code is OO, and so I want to be able to use property accessors, rather than
property addresses).

Enough jabbering from me....

James


----- Original Message -----
From: "Marcus" <li...@wo...>
To: <wxp...@li...>
Sent: 05 July 2002 13:11
Subject: [wxperl-users] Validators


> I think the vaildators are a good idea. If I understand the concept
> correctly, then this is how Perl/Tk works, only you have no choice.
>
> The downside is that when you "bind" a variable to a control, then any
> changes while you are working with the variable appear immediately in
> the GUI. An example that caused me and my beta tester many many hours
> of grief is the following. I had to escape backslashes when storing
> paths in a config file, in the GUI they were unescaped. As you can
> imagine unescaped backslashes can cause amazing problems when let
> loose. The only workaround was to keep copying variables back and
> forth, and making lots of temp variables.
>
> Only a word of warning, which should be at the top of the docs, in form
> of a "When to use..". Otherwise, I am in favour of the validators,
> since they can be very useful.
>
> Marcus
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Bringing you mounds of caffeinated joy.
> http://thinkgeek.com/sf
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users

Re: [wxperl-users] Get Window by name

[James L. <jl...@bi...>]

Hi Marcus,
There are two 32-bit Windows API functions to get a window by name, called
FindWindow and FindWindowEx, both in user32.dll.

FindWindow takes the windows class name (blank to ignore class), and the
title of the window to look for.

FindWindowEx takes more parameters, allowing you to search under a top
window, and iterate through child windows.

In order to use them, you will need use Win32::API, I think.

In order to then paste to Notepad, you will have to activate the window, and
send keystrokes to it (i.e. <CTRL>V, or <ALT> E P ).  At least this is what
I had to do several years ago when I was VB programming.  There may be an
easier mechanism nowadays.

Hope this helps - if you want more info, let me know

James

----- Original Message -----
From: "Marcus" <li...@wo...>
To: <wxp...@li...>
Sent: 05 July 2002 13:34
Subject: [wxperl-users] Get Window by name


> Does anybody know how to get a window by name?
>
> I'm working on the following: I have a dialog which collects user input
> which needs to be pasted to an application of the user's choice. I
> think I need to get the Window by name, e.g. "Notepad", or "Some
> application", then copy and paste via the clipboard. To paste I need to
> make the application's window active.
>
> Any ideas if there's a way in Perl?
>
> Thanks,
>
> Marcus
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Bringing you mounds of caffeinated joy.
> http://thinkgeek.com/sf
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users

[wxperl-users] Get Window by name

[Marcus <li...@wo...>]

Does anybody know how to get a window by name?

I'm working on the following: I have a dialog which collects user input
which needs to be pasted to an application of the user's choice. I
think I need to get the Window by name, e.g. "Notepad", or "Some
application", then copy and paste via the clipboard. To paste I need to
make the application's window active.

Any ideas if there's a way in Perl?

Thanks,

Marcus

[wxperl-users] Validators

[Marcus <li...@wo...>]

I think the vaildators are a good idea. If I understand the concept
correctly, then this is how Perl/Tk works, only you have no choice.

The downside is that when you "bind" a variable to a control, then any
changes while you are working with the variable appear immediately in
the GUI. An example that caused me and my beta tester many many hours
of grief is the following. I had to escape backslashes when storing
paths in a config file, in the GUI they were unescaped. As you can
imagine unescaped backslashes can cause amazing problems when let
loose. The only workaround was to keep copying variables back and
forth, and making lots of temp variables.

Only a word of warning, which should be at the top of the docs, in form
of a "When to use..". Otherwise, I am in favour of the validators,
since they can be very useful.

Marcus

[wxperl-users] Perl validators

[James L. <jl...@bi...>]

Hi Mattia,
Thanks for the feedback - I know we'd discussed this before, but had mislaid
the emails!  I think I will go with your suggestion of a separate validator
per control type, rather than GenericValidator.

What should we do with regard to submitting the code for them etc.  You're
happy for them to be part of wxPerl - so will we add them to the SourceForge
project?

Regards,

James

PS If anyone else has suggestions/requests for the validators, let me know.

[wxperl-users] Updated build instructions - care to review?

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

Link:
http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/wxperl/wxPerl/docs/install.txt?rev=1.12&content-type=text/vnd.viewcvs-
markup

Some time ago I updated build instructions to be (hopefully...)
clearer; if anyone wants to have a look and comment, I'd appreciate it.

Thanks!
Mattia

Re: [wxperl-users] Perl validators

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

> Hi Mattia,
> I've started coding a generic and a text validator for wxPerl, as I want to
> use them in my project.
> 
> Would you (or others) be interested in these being contributed to the wxPerl
> community?  If so, how do we want to manage it - as part of wxPerl, or just
> a contribution to CPAN?
Well, the rule I will try to follow is that wxPerl should
only contain things that are in wxWindows; since wxValidators are in
wxWindows I think your creatins belong to wxPerl

> With regard to package naming, I'm intending to name them as follows:
> Wx::Perl::GenericValidator
> Wx::Perl::TextValidator
> etc...
Yes, that's what we afreed last time that was discussed

> I'm intending the TextValidator validation to be controlled mainly by a
> regexp to validate against, to make it flexible, but also to match the
> features of the native wxValidator, if possible (though a lot of these can
> be achieved by a regexp, I think).

> Other suggestions/opinions regarding naming conventions are welcome -
> nothing's cast in stone yet!
Yes, one ( *suggestion* ): do not implement Wx::Perl::GenericValidator,
as we discussed last time, there is ( almost ) no hope to implement
it in Perl; and besides, the interface is quite broken IMHO;
I *think* it is better to have something different from Wx::GV,
either 
Wx::Perl::IntegerV, Wx::Perl::StringV, Wx::Perl::RealV, etc
or
Wx::Perl::ListBoxV, Wx::Perl::ComboBoxV, Wx::Perl::RadioBoxV, etc

Of course these are suggestions, not necessarily right nor necessarily
useful, just yjrowing some ideas...

Regards
Mattia

[wxperl-users] Binary distribution

[Marcus <li...@wo...>]

I'm looking at making a CD setup/install program for apps I distribute
on CDs. Is it possible to make binaries for Linux or Windows of a
wxPerl app, or do I have to load the entire Perl + wxPerl onto the CD?

Actually that's a general question. I have Perl2Exe for Windows, but
buying another for each Linux/Unix platform is very expensive. Is there
another way?

Thanks,

Marcus

Re: [wxperl-users] Perl validators

[James L. <jl...@bi...>]

DH,

No, not to validate Perl, but to implement wxValidators in Perl.

wxValidators allow the association of a variable (in our case, a Perl
variable) with a control so that the control gets automatically populated
with the contents of the variable, and the variable gets automatically
updated when the OK button is clicked on the dialog (and NOT updated if the
Cancel button is clicked).

In addition, the validator can have validation associated with it, which
gets called when the wxDialog->Validate method is called.

This all happens automatically if the control is on a wxDialog-derived
window, and can be implemented manually with a few Wx function/method calls
if the control is on a frame.

For more details, there's good documentation on wxValidators in the
wxWindows docs.

Does this make more sense now?

Regards,

James


----- Original Message -----
From: "DH" <cra...@ya...>
To: "James Lavery" <jl...@bi...>
Cc: <wxp...@li...>
Sent: Wednesday, July 03, 2002 10:33 AM
Subject: Re: [wxperl-users] Perl validators


> Say what now?
> What exactly will be the purpose of the modules, to validate Perl?
> ( it's unclear )
>
> --- James Lavery <jl...@bi...> wrote:
> > Hi Mattia,
> > I've started coding a generic and a text validator for wxPerl, as I want
to
> > use them in my project.
> >
> > Would you (or others) be interested in these being contributed to the
wxPerl
> > community?  If so, how do we want to manage it - as part of wxPerl, or
just
> > a contribution to CPAN?
> >
> > With regard to package naming, I'm intending to name them as follows:
> > Wx::Perl::GenericValidator
> > Wx::Perl::TextValidator
> > etc...
> >
> > I'm intending the TextValidator validation to be controlled mainly by a
> > regexp to validate against, to make it flexible, but also to match the
> > features of the native wxValidator, if possible (though a lot of these
can
> > be achieved by a regexp, I think).
> >
> > Other suggestions/opinions regarding naming conventions are welcome -
> > nothing's cast in stone yet!
> >
> > Regards,
> >
> > James
>
>
> __________________________________________________
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> No, I will not fix your computer.
> http://thinkgeek.com/sf
> _______________________________________________
> wxperl-users mailing list
> wxp...@li...
> https://lists.sourceforge.net/lists/listinfo/wxperl-users

Re: [wxperl-users] Perl validators

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

Say what now?
What exactly will be the purpose of the modules, to validate Perl?
( it's unclear )

--- James Lavery <jl...@bi...> wrote:
> Hi Mattia,
> I've started coding a generic and a text validator for wxPerl, as I want to
> use them in my project.
> 
> Would you (or others) be interested in these being contributed to the wxPerl
> community?  If so, how do we want to manage it - as part of wxPerl, or just
> a contribution to CPAN?
> 
> With regard to package naming, I'm intending to name them as follows:
> Wx::Perl::GenericValidator
> Wx::Perl::TextValidator
> etc...
> 
> I'm intending the TextValidator validation to be controlled mainly by a
> regexp to validate against, to make it flexible, but also to match the
> features of the native wxValidator, if possible (though a lot of these can
> be achieved by a regexp, I think).
> 
> Other suggestions/opinions regarding naming conventions are welcome -
> nothing's cast in stone yet!
> 
> Regards,
> 
> James


__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

[wxperl-users] Perl validators

[James L. <jl...@bi...>]

Hi Mattia,
I've started coding a generic and a text validator for wxPerl, as I want to
use them in my project.

Would you (or others) be interested in these being contributed to the wxPerl
community?  If so, how do we want to manage it - as part of wxPerl, or just
a contribution to CPAN?

With regard to package naming, I'm intending to name them as follows:
Wx::Perl::GenericValidator
Wx::Perl::TextValidator
etc...

I'm intending the TextValidator validation to be controlled mainly by a
regexp to validate against, to make it flexible, but also to match the
features of the native wxValidator, if possible (though a lot of these can
be achieved by a regexp, I think).

Other suggestions/opinions regarding naming conventions are welcome -
nothing's cast in stone yet!

Regards,

James