perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension

Re: [win32gui] [perl-win32-gui-hackers] Commit

[Jeremy W. <jez...@ho...>]

>When I last looked at this I thought that the best solution would be to 
>remove the tied mechanism altogether - there's not much functionality 
>added;  besides we should not be encouraging people to access the object 
>hashes directly - it's not very 00.  But I haven't found the time to look 
>at exactly how much functionality would be lost, and how hard it would be 
>to add that functionality back using a more traditional approach (if indeed 
>it is possible at all).

If it turns out that the source of the various crashes is the tied 
mechanism, and it can't be fixed across all perl versions (which could be 
the case), then we should remove it. I agree, providing the hash is 
questionable.

If we remove it, we will break code. One way to limit the 'pain' could be to 
provide a method that returns the hash, which can then be accessed (this 
would also be quicker than using tie). Other than adding items to the hash, 
I can't think of a reason why you would need to use hash access (ok, to 
return items from the hash - but these should be methods if they don't 
exits).

Cheers,

jez.

Re: [win32gui] [perl-win32-gui-hackers] Commit

[Robert M. <rm...@po...>]

Jeremy White wrote:
>> Have you tried this?  It's sort of equivalent to
>>
>> }
>>   my $mw;
>>   $mw = Win32::GUI::Window->new(
>>     ...
>>     -onTerminate => sub { undef $mw },
>>   );
>> }
>>
>> Which uses a closure to stop $mw's ref count going to zero at the end 
>> of the enclosing block, but forces it to zero in the onTerminate handler.
> 
> 
> Humm - I've just had a bit of a play, and I am not convinced the window 
> destruction logic is correct. Under the hood a window is both an object 
> and a tied hash ref right? Could it be the case that we're destroying 
> one and not the other?

Ah.  I've come across this problem too when trying to add my own DESTROY 
method to a subclass of a Win32::GUI window/control object.

There's definitely some nastiness lurking in the way that the object is 
tied to Win32::GUI::WindowProps.  I couldn't quite get my head round it 
when I last looked there, but the DESTROY method gets called twice, with 
different objects (try print $self; within the DESTROY method).  I 
*think* there are actually 2 perl objects created for each window;  but 
as I said I never got to the bottom of the logic to my satisfaction.

When I last looked at this I thought that the best solution would be to 
remove the tied mechanism altogether - there's not much functionality 
added;  besides we should not be encouraging people to access the object 
hashes directly - it's not very 00.  But I haven't found the time to 
look at exactly how much functionality would be lost, and how hard it 
would be to add that functionality back using a more traditional 
approach (if indeed it is possible at all).

Rob.

Re: [win32gui] [perl-win32-gui-hackers] Commit

[Jeremy W. <jez...@ho...>]

>Have you tried this?  It's sort of equivalent to
>
>}
>   my $mw;
>   $mw = Win32::GUI::Window->new(
>	...
>	-onTerminate => sub { undef $mw },
>   );
>}
>
>Which uses a closure to stop $mw's ref count going to zero at the end of 
>the enclosing block, but forces it to zero in the onTerminate handler.

Humm - I've just had a bit of a play, and I am not convinced the window 
destruction logic is correct. Under the hood a window is both an object and 
a tied hash ref right? Could it be the case that we're destroying one and 
not the other?

Anyways, have a play with the example below.

Cheers,

jez.
-----------------

use strict;
use warnings;

use Win32::GUI;

# Create the main window
my $mainwindow = new Win32::GUI::Window(
   -name   => "Window",
   -title  => "Objects and Windows",
   -pos    => [100,100],
   -size   => [400,400],
);

#We now create several employee windows
EmployeeSelector->new($mainwindow,20,20);
EmployeeSelector->new($mainwindow,20,50);
EmployeeSelector->new($mainwindow,20,80);
EmployeeSelector->new($mainwindow,20,110);
EmployeeSelector->new($mainwindow,20,140);

$mainwindow->Show();
#Enter the message processing loop
Win32::GUI::Dialog();
exit(0);

package EmployeeSelector;
use strict;
use warnings;
use Win32::GUI;
use base qw(Win32::GUI::Window);

#The constructor
sub new
{
my ($class, $parent, $xcor, $ycor)=@_;

#Create window
my $self = $class->SUPER::new(
#my $self =  new Win32::GUI::Window(
#-parent    => $parent,
-pos       => [$xcor,$ycor],
-size      => [150, 60],
#-onTerminate  => sub {return 1},
#When we terminate, the ref counter of the UserData is dropped, which should 
kick off the destruction
-onTerminate  => sub {my $self=shift;print "in terminate self is $self\n"},
);
$self->AddButton (
-text   => 'Click Me!',
-pos    => [60,2],
-size  => [60,20],
-onClick => sub {print 'Button Clicked';},
);
print "Created $self\n";
$self->Show();
#Save the window in the window user data, once the sub finishes, there is no 
reference to the
#window other than itself. The destiny of the window is in it's own hands.
$self->UserData($self);
}

sub DESTROY {
  my $self=shift;
  print "In destroy $self \n";
  $self->SUPER::DESTROY();
}

Re: [win32gui] [perl-win32-gui-hackers] Commit

[Jeremy W. <jez...@ho...>]

>Just one comment here - if the parent doesn't have valid userdata, should 
>GetParent() return the hwnd, like most other calls do?  Should we be 
>looking at extending/changing other api calls to return objects, where such 
>objects exist?

Both good questions and the honest answer is that I don't know:) Personally 
I prefer using objects, but if we have methods that could return either then 
it would mean that the user would have to test the return value before each 
use.

>Nice.  I hadn't thought of holding a separate reference to the userdata, 
>and so avoiding the circular references.  I think we may still see problems 
>with the reference causing 'late destruction' in some cases, but I could be 
>wrong (I still can't really get my head round the way objects are tied, 
>resulting in more than one call to the classes DESTROY method).

It does need more testing, and no doubt issues will crop up. In theory you 
should be able to create a sell referencing window, which has no global 
reference, with the window controlling when it's destroyed. Something like 
this:

{#window constructor
my $win=create window;
#the window is stored within itself, and the ref count is increased and wont 
be destroyed when
#the block is finished
$win->UserData($win);
}

onTerminateHandler
{
my $self=shift;
#Setting the userdata to a blank string causes the ref count to be dropped 
on the window
#and therefore should kick in the destruction logic
$self->UserData('');
}

>It would be nice to have tests for everything we add, and we should 
>certainly try going forward.  There are some things I just don't know how 
>to test yet.  I'd like to encourage everyone to put tests into the test 
>directory - I've not really got a naming scheme yet, but think something 
>will become obvious once we see some more contributions.  For methods, I 
>started numbering at 50, with test names XX_Classname_Methodname.t, but 
>don't know if this will hold up or not.

Ok - I'll add these scripts later. Does anyone know a way to test for memory 
leaks?

Cheers,

jez.

Re: [win32gui] [perl-win32-gui-hackers] Commit

[Robert M. <rm...@po...>]

Jeremy White wrote:
>> Just one comment here - if the parent doesn't have valid userdata, 
>> should GetParent() return the hwnd, like most other calls do?  Should 
>> we be looking at extending/changing other api calls to return objects, 
>> where such objects exist?

> Both good questions and the honest answer is that I don't know:) 
> Personally I prefer using objects, but if we have methods that could 
> return either then it would mean that the user would have to test the 
> return value before each use.

I think that's good logic to use to say that a method should return 
either object/undef or handle/undef, but never object/handle/undef.

> In theory 
> you should be able to create a sell referencing window, which has no 
> global reference, with the window controlling when it's destroyed. 
> Something like this:
> 
> {#window constructor
> my $win=create window;
> #the window is stored within itself, and the ref count is increased and 
> wont be destroyed when
> #the block is finished
> $win->UserData($win);
> }
> 
> onTerminateHandler
> {
> my $self=shift;
> #Setting the userdata to a blank string causes the ref count to be 
> dropped on the window
> #and therefore should kick in the destruction logic
> $self->UserData('');
> }

Have you tried this?  It's sort of equivalent to

}
   my $mw;
   $mw = Win32::GUI::Window->new(
	...
	-onTerminate => sub { undef $mw },
   );
}

Which uses a closure to stop $mw's ref count going to zero at the end of 
the enclosing block, but forces it to zero in the onTerminate handler.

> Ok - I'll add these scripts later. Does anyone know a way to test for 
> memory leaks?

No idea how to test for memory leaks - it's such a hard problem that 
there's a whole industry around making tools to do just that.

You'll find developer CVS is down for anything up to the next 36 hours 
for maintenance.

Regards,
Rob.

Re: [win32gui] [perl-win32-gui-hackers] Commit

[Robert M. <rm...@po...>]

Jeremy White wrote:
> I've just committed a change that added two new methods, GetParent and 
> UserData - both of which can be called on controls or windows.
> 
> GetParent simply returns the parent window of the control or child 
> window (if there was one).

Just one comment here - if the parent doesn't have valid userdata, 
should GetParent() return the hwnd, like most other calls do?  Should we 
be looking at extending/changing other api calls to return objects, 
where such objects exist?

> UserData allows you to associate an SV to a control or window, allowing 
> you to save instance data to that object.

Nice.  I hadn't thought of holding a separate reference to the userdata, 
and so avoiding the circular references.  I think we may still see 
problems with the reference causing 'late destruction' in some cases, 
but I could be wrong (I still can't really get my head round the way 
objects are tied, resulting in more than one call to the classes DESTROY 
method).

> I've created a test script for both of these functions but I am unsure 
> of the naming scheme? I also assume that going forward we should be 
> adding test scripts for any changes?

It would be nice to have tests for everything we add, and we should 
certainly try going forward.  There are some things I just don't know 
how to test yet.  I'd like to encourage everyone to put tests into the 
test directory - I've not really got a naming scheme yet, but think 
something will become obvious once we see some more contributions.  For 
methods, I started numbering at 50, with test names 
XX_Classname_Methodname.t, but don't know if this will hold up or not.

Regards,
Rob.

[perl-win32-gui-hackers] Commit

[Jeremy W. <jez...@ho...>]

Hi,

I've just committed a change that added two new methods, GetParent and 
UserData - both of which can be called on controls or windows.

GetParent simply returns the parent window of the control or child window 
(if there was one).

UserData allows you to associate an SV to a control or window, allowing you 
to save instance data to that object.

When used together, these methods should allow the creation of an window 
object that encapsulates all events, methods and instance data without the 
use of closures and other 'tricks'.

I've created a test script for both of these functions but I am unsure of 
the naming scheme? I also assume that going forward we should be adding test 
scripts for any changes?

I would be grateful for any comments/suggestions - and once this 
functionality has bedded down I'll add a couple of samples before the next 
release. In the meantime, the script below will show this functionality in 
action.

Cheers,

jez.

-------------------
use strict;
use warnings;

use Win32::GUI;

# Create the main window
my $mainwindow = new Win32::GUI::Window(
   -name   => "Window",
   -title  => "Objects and Windows",
   -pos    => [100,100],
   -size   => [400,400],
);

#We now create several employee selector 'controls'.
my $search1=EmployeeSelector->new($mainwindow,20,20);
my $search2=EmployeeSelector->new($mainwindow,20,50);
my $search3=EmployeeSelector->new($mainwindow,20,80);
my $search4=EmployeeSelector->new($mainwindow,20,110);
my $search5=EmployeeSelector->new($mainwindow,20,140);
#Show all our controls
$search2->Move(200,200);

# Child windows don't show until their parent shows, so by
# showing the main window last we can create the child
# windows with WS_VISIBLE, and not see them drawing
$mainwindow->Show();
#Enter the message processing loop
Win32::GUI::Dialog();
exit(0);

# package to encapsulate the search window.
# one static (class) function that diaplays the
# search window and returns the selected item
# or undef if ESC/Cancel preseed
package SearchWindow;
use strict;
use warnings;
use Win32::GUI;

our $searchwindow;
our $ok;  # there has to be a better way to determine
          # which button was pressed perhaps buttons with -ok/-cancel
          # should exit the DoModal loop, returning some
          # well defined values?

sub DoSearch {

unless ($searchwindow) {
# create it first time we're called
# depending how much this gets called it's questionable
# whether it's worth keeping it hanging around

$searchwindow = Win32::GUI::DialogBox->new(
-title       => "Search for Employee",
-size        => [300,270],
-onTerminate => sub { $ok = 0; return -1;},
);
$searchwindow->AddListView(
-name          => "ListView",
-pos           => [8,8],
-size          => [280,189],
-singlesel     => 1,
-fullrowselect => 1,
-tabstop       => 1,
);
$searchwindow->AddButton (
-text    => 'OK',
-pos     => [164,208],
-size    => [60,21],
-tabstop => 1,
-default => 1,  # draw button in 'default' style
-ok      => 1,  # respond to 'return' key
-onClick => sub{ $ok = 1; return -1;},
);
$searchwindow->AddButton (
-text    => 'Cancel',
-pos     => [228,208],
-size    => [60,21],
-tabstop => 1,
-cancel  => 1,  # respond to ESC key
-onClick => sub{ $ok = 0; return -1;},
);

#populate the list view
$searchwindow->ListView->InsertColumn(-width => 55,-text  => 'Emp ID');
$searchwindow->ListView->InsertColumn(-width => 205,-text  => 'Employee 
Name');
$searchwindow->ListView->InsertItem(-text => [1234, 'Bob Smith']);
$searchwindow->ListView->InsertItem(-text => [4321, 'Peter Jones']);
$searchwindow->ListView->InsertItem(-text => [7890, 'John Brown']);

}

# show the search window and return the searched out value
$searchwindow->Center();
$searchwindow->ListView->SetFocus();
$searchwindow->DoModal(1);

return undef unless $ok;  # pressed cancel or ESC (or X in titlebar)
  my $item=$searchwindow->ListView->SelectedItems();
  return undef unless defined $item;  # no selection (undef gets treated as 
zero by ItemInfo)
my %hItem=$searchwindow->ListView->ItemInfo($item,0);
  return $hItem{-text};
}

# I don't really understand why this end block is necessary to avoid 
warnings
END
{
undef $searchwindow;
}

#package to encapsulate the 'Employee Selector' control
# subclass of Window, so that I don't have to implement
# Move()/Show() etc.
package EmployeeSelector;
use strict;
use warnings;
use Win32::GUI;
use base qw(Win32::GUI::Window);

#The constructor
sub new
{
my ($class, $parent, $xcor, $ycor)=@_;

#Create window
my $self = $class->SUPER::new(
-parent    => $parent,
-pos       => [$xcor,$ycor],
-size      => [150, 24],
-popstyle  => WS_CAPTION | WS_SIZEBOX,
-pushstyle => WS_CHILD | WS_CLIPCHILDREN | WS_VISIBLE,
);
$self->UserData(0);
#Create other controls
$self->AddLabel(
-text   => 'ID#',
-pos    => [0,6],
-size   => [20,20],
);
$self->AddTextfield(
-name   => "EMPID",
-pos   => [20,2],
-size  => [35,20],
-tip    => 'Employee ID',
);
  $self->AddButton (
-text   => 'Search',
-pos    => [60,2],
-size  => [60,20],
-tip    => 'Search for a Employee  ID',
-onClick => sub{my $self=shift;Search($self->GetParent)},
);
#Set the user data for the window to be an empty string
$self->UserData('');
return $self;
}

sub Search
{
my $self = shift;
my $result = SearchWindow::DoSearch();
if ($result) {
  $self->SetEmpID($result);
  print 'Previous ID for this window was '.$self->UserData()."\n";
  $self->UserData($result);
}
return 1;
}

sub SetEmpID
{
my $self=shift;
$self->EMPID->Text(shift);
}

RE: [perl-win32-gui-hackers] Win32::GUI Commit

[Robert M. <rm...@po...>]

Jeremy White wrote:
> I had to change __MINGW__ in ImageList.xs to __MINGW32__, otherwise I get:
Got it.

> When running makefile.pl I get:
> 
> Checking if your kit is complete...
> Warning: the following files are missing in your kit:
>        patches/README.txt
>        patches/patch001.patch
Got it.

> I also get this warning:
> GUI_MessageLoops.cpp:111: warning: NULL used in arithmetic
Got it.

Fixes in CVS.

Many thanks,
Rob.

RE: [perl-win32-gui-hackers] Win32::GUI Commit

[Jeremy W. <jez...@ho...>]

>I've done very limited testing on most of this, so any feedback (especially 
>negative) is very welcome.

I had a few issues building under mingw:

I had to change __MINGW__ in ImageList.xs to __MINGW32__, otherwise I get:

ImageList.o(.text+0xd2a):ImageList.cpp: undefined reference to 
`ImageList_Copy@2
0'
ImageList.o(.text+0x21c4):ImageList.cpp: undefined reference to 
`ImageList_DrawI
ndirect@4'
ImageList.o(.text+0x25e9):ImageList.cpp: undefined reference to 
`_Z19ImageList_D
uplicateP10_IMAGELIST@4'

When running makefile.pl I get:

Checking if your kit is complete...
Warning: the following files are missing in your kit:
        patches/README.txt
        patches/patch001.patch
Please inform the author.
Writing Makefile for Win32::GUI

I also get this warning:

1.02_01\" -DHASATTRIBUTE -IC:\Perl\lib\CORE  GUI_MessageLoops.cpp
GUI_MessageLoops.cpp: In function `LRESULT CommonMsgLoop(PerlInterpreter*,
   HWND__*, unsigned int, unsigned int, long int, LRESULT (*)(HWND__*, 
unsigned

   int, unsigned int, long int))':
GUI_MessageLoops.cpp:111: warning: NULL used in arithmetic

Cheers,

jez.

Re: [perl-win32-gui-hackers] Win32::GUI Commit

[Reini U. <ru...@x-...>]

Robert May schrieb:
> - many tests added, and MANIFEST updated (Reini Urban, Dan Dascalescu, 
> Robert May)
> 
> I've done little with the test other that take what Reini and Dan have 
> given me, and re-write them to use Test::More.  We still need to think 
> through a testing strategy.

I thought of adding a simple Win32::GUI:Test helper module with a
SendMessage, PostMessage.
And maybe higher SendKeys and mouse functionality borrowed from 
Win32::GuiTest, and doing the rest with Timers.
Or just using Win32-GuiTest-1.50 to do the functionality tests.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [perl-win32-gui-hackers] What is the -container option for?

[Robert M. <rm...@po...>]

Jeremy White wrote:
> Hi,
> 
> Was looking at something else and came across the -container option. 
> What is it for? The option has no documentation, but does seem to do 
> "something". It has a message loop (ContainerMsgLoop in 
> GUI_MessageLoops), and a constant (PERLWIN32GUI_CONTAINER) which is 
> checked/used in several places.
> 
> If anyone can provide an explanation - and perhaps an example:) I'll 
> update the docs.

I've had a look at the code, and can tell you what it does, but I can't 
tell you why it's useful.

The -container option set the PERLWIN32GUI_CONTAINER flag against an 
object.  See ParseWindowOptions in GUI_Options.cpp:

} else BitmaskOption("-container", perlcs->dwPlStyle,
                          PERLWIN32GUI_CONTAINER)

It is used in the ControlMessageLoop (the window procedure that is by 
default used to sub-class controls), and passes all unprocessed 
WM_COMMAND and WM_NOTIFY messages the objects parent.  Search for 
PERLWIN32GUI_CONTAINER in GUI_Messageloops.cpp

The flag is automatically set in Create() on the parent of any window or 
control that is not itself a window(Window, DialogBox, MDIFame, MDIClient)

So there you go.  I can't think of a use for it.

Rob.

[perl-win32-gui-hackers] Win32::GUI Commit

[Robert M. <rm...@po...>]

All,

I've just put quite a large set of changes into CVS.  Many thanks to Dan 
and Reini for their contributions.

I've done very limited testing on most of this, so any feedback 
(especially negative) is very welcome.

Regards,
Rob.


- Added VERSIONINFO resource to GUI.rc and updated the build process to 
update version automatically in VERSIONINFO Structure

Now you can right-click->Properties GUI.dll and get the version 
information etc.  I don't know if this is generally useful, but I have 
so many GUI.dll files hanging around that it is at least useful for me.


- GUI.h, button.xs, datetime.xs, GUI.xs, GUI_options.cpp, Label.xs, 
Listview.xs, Richedit.xs, Splitter.xs, Textfield.xs, Updown.xs, 
Window.xs: Added new macro W32G_DOWARN and W32G_DOEARN_DEPRECATED to 
replace use of PL_dowarm, fixing inability to turn off Win32::GUI 
warnings when lexical warnings are in use. By default behaviour is as 
before, pass -DW32G_NEWWARN to enable this.

I started investigating whether there was a better way to issue warnings 
from the XS code.  You shouldn't see any change in behaviour unless you 
pass -DW32G_NEWWARN to the build process.  If you do, then you'll get no 
warnings from the XS parts of Win32::GUI unless you use the -w 
command-line switch (or set it on your shbang line, or set $^W)


- Makefile.PL, GUI.h: now use __MINGW32__ guard blocks rather than 
__MINGW__, as compiler defines first automatically; reduced variations 
between build environments

I've re-worked the Makefile to reduce the number of differences between 
the build environments.  *I am particularly interested in hearing that I 
haven't broken your build process*.


- GUI.pm Fix to logic in Win32::GUI::Class::new for perl 5.8.6 and 
above. Tracker:1236053

- GUI.pm fixed Win32::GUI::Brush to return undef on failure

- GUI.pm upped version to v1.02_01

- GUI_messageloops.cpp: Tracker 1246429 fixed WM_CTLCOLORSTATIC for 
handling readonly Edit controls
- GUI_messageloops.cpp: Fixed WM_CTLCOLOR* to use window class 
background brush if there is one
- GUI_messageloops.cpp: Tracker:1236283 Change to WM_ERASEBACKGROUND to 
allow -background to work with windows

As a result of these changes use of -background, and -class (with 
background brushes) should work much more as you expect.  -background on 
  Windows can be quite flickery.  Most of this can be overcome by adding 
WS_CLIPCHILDREN to your window styles.

- sourceParser.pm Fix to solve over aggressive removal of blank lines.

- various documentation corrections/enhancements

- Richedit.xs fix SetCharFormat/GetCharFormat option and new 
documentation (thanks to Dan Dascalescu)

- GUI.pm Timer fixes (Reini Urban)

- many tests added, and MANIFEST updated (Reini Urban, Dan Dascalescu, 
Robert May)

I've done little with the test other that take what Reini and Dan have 
given me, and re-write them to use Test::More.  We still need to think 
through a testing strategy.

- GUI.xs re-wrote logic for TrackPopupMenu to make it (slightly) more 
maintainable

- added listvew_drag_drop.pl to the samples

[perl-win32-gui-hackers] RE: [SPAM] - [perl-win32-gui-users] ANNOUNCE: New home on the web - Email found in subject

[Lloyd, S. <Ste...@la...>]

Awesome Rob! Do you need any help getting samples or content for the
areas marked TDB?
I also suggest an Examples section in both the Methods and Events area.

Steve Lloyd

-----Original Message-----
From: per...@li...
[mailto:per...@li...] On Behalf Of
Robert May
Sent: Tuesday, August 02, 2005 3:35 PM
To: per...@li...;
per...@li...
Subject: [SPAM] - [perl-win32-gui-users] ANNOUNCE: New home on the web -
Email found in subject


I am pleased to announce that Win32::GUI has a new home on the web at:=20
http://perl-win32-gui.sourceforge.net/

There you'll find links to all things Win32::GUI including the latest=20
documentation. Problems/suggestions/corrections to the users mailing=20
list please.

Regards,
Rob.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
_______________________________________________
Perl-Win32-GUI-Users mailing list
Per...@li...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users

This email, and any files previous email messages included with it, may =
contain confidential and/or privileged material. If you are not the =
intended recipient please contact the sender and delete all copies.

[perl-win32-gui-hackers] ANNOUNCE: New home on the web

[Robert M. <rm...@po...>]

I am pleased to announce that Win32::GUI has a new home on the web at: 
http://perl-win32-gui.sourceforge.net/

There you'll find links to all things Win32::GUI including the latest 
documentation. Problems/suggestions/corrections to the users mailing 
list please.

Regards,
Rob.

Re: [win32gui] Re: [perl-win32-gui-hackers] Using Windows as Objects

[Jeremy W. <jez...@ho...>]

>It doesn't crash for me: Win98 (and IE 6 fully patched), perl 5.8.7, 
>Win32::GUI 1.02
>
>Here's an alternative.  Does this crash for you?

Yes still crashes - on 5.8.7 and 5.6.1 both Win32::GUI 1.02, I'm on XP 
Sp2...

Win32-GUI in both cases was the binary from sourceforge, not my own build.

Leaving the crashing aside for the moment, a key line in your changes (or 
rather the comments) was:

-onClick => sub{Search($self)},  # closure
                                 # wouldn't it be nice to have
                                 # a way to navigate up to parent
                                 # objects as well as down to children

Your comments hit the nail on the head. You could argue that the real 
problem is that there is no way to navigate from the event in the control, 
to the window which it belongs, to the perl 'thing' that owns the instance 
data for the window/object. Perhaps something like this would work:

sub #the constructor for the window/object
  my $window= createwindow
  $window->create lots of controls;
  #We now add instance data to the window, which we can read and set as we 
like
  #it should mean we can get away with closures, and it should be simple 
enough to deal
  #with when we free the window.
  $window->InstanceData({}); #set the instance data for the window as a 
empty hash

  return window;
}

sub #some event handler for a control
my $self=shift;
my $parentwindow=$self->GetParent;
my $instancedata=$parentwindow->InstanceData;
if ($instancedata->{something}) {
  #do logic here...
}

Here we fetch the parent window (of the control) via the method GetParent 
(which doesn't actually exist in win32-gui), we then call a new method 
InstanceData which returns an SV that was squirreled away on object 
creation.

I do something similar in some of my code already - I add my own data to the 
window hash - I just had to make sure I didn't clobber anything...A formal 
approach would be better.

Thoughts?

Cheers,

jez.

Re: [win32gui] Re: [perl-win32-gui-hackers] Using Windows as Objects

[Robert M. <rm...@po...>]

It doesn't crash for me: Win98 (and IE 6 fully patched), perl 5.8.7, 
Win32::GUI 1.02

Here's an alternative.  Does this crash for you?

#!perl -w
use strict;
use warnings;

use Win32::GUI;

# Create the main window
my $mainwindow = new Win32::GUI::Window(
    -name   => "Window",
    -title  => "Objects and Windows",
    -pos    => [100,100],
    -size   => [400,400],
);

#We now create several employee selector 'controls'.
my $search1=EmployeeSelector->new($mainwindow,20,20);
my $search2=EmployeeSelector->new($mainwindow,20,50);
my $search3=EmployeeSelector->new($mainwindow,20,80);
my $search4=EmployeeSelector->new($mainwindow,20,110);
my $search5=EmployeeSelector->new($mainwindow,20,140);
#Show all our controls
$search2->Move(200,200);

# Child windows don't show until their parent shows, so by
# showing the main window last we can create the child
# windows with WS_VISIBLE, and not see them drawing
$mainwindow->Show();
#Enter the message processing loop
Win32::GUI::Dialog();
exit(0);

# package to encapsulate the search window.
# one static (class) function that diaplays the
# search window and returns the selected item
# or undef if ESC/Cancel preseed
package SearchWindow;
use strict;
use warnings;
use Win32::GUI;

our $searchwindow;
our $ok;  # there has to be a better way to determine
           # which button was pressed perhaps buttons with -ok/-cancel
           # should exit the DoModal loop, returning some
           # well defined values?

sub DoSearch {

	unless ($searchwindow) {
		# create it first time we're called
		# depending how much this gets called it's questionable
		# whether it's worth keeping it hanging around

		$searchwindow = Win32::GUI::DialogBox->new(
			-title       => "Search for Employee",
			-size        => [300,270],
			-onTerminate => sub { $ok = 0; return -1;},
		);
		$searchwindow->AddListView(
			-name          => "ListView",
			-pos           => [8,8],
			-size          => [280,189],
			-singlesel     => 1,
			-fullrowselect => 1,
			-tabstop       => 1,
		);
		$searchwindow->AddButton (
			-text    => 'OK',
			-pos     => [164,208],
			-size    => [60,21],
			-tabstop => 1,
			-default => 1,  # draw button in 'default' style
			-ok      => 1,  # respond to 'return' key
			-onClick => sub{ $ok = 1; return -1;},
		);
		$searchwindow->AddButton (
			-text    => 'Cancel',
			-pos     => [228,208],
			-size    => [60,21],
			-tabstop => 1,
			-cancel  => 1,  # respond to ESC key
			-onClick => sub{ $ok = 0; return -1;},
		);

		#populate the list view
		$searchwindow->ListView->InsertColumn(-width => 55,-text  => 'Emp ID');
		$searchwindow->ListView->InsertColumn(-width => 205,-text  => 
'Employee Name');
		$searchwindow->ListView->InsertItem(-text => [1234, 'Bob Smith']);
		$searchwindow->ListView->InsertItem(-text => [4321, 'Peter Jones']);
		$searchwindow->ListView->InsertItem(-text => [7890, 'John Brown']);

	}

	# show the search window and return the searched out value
	$searchwindow->Center();
	$searchwindow->ListView->SetFocus();
	$searchwindow->DoModal(1);
	
	return undef unless $ok;  # pressed cancel or ESC (or X in titlebar)
   my $item=$searchwindow->ListView->SelectedItems();
   return undef unless defined $item;  # no selection (undef gets 
treated as zero by ItemInfo)
	my %hItem=$searchwindow->ListView->ItemInfo($item,0);
   return $hItem{-text};
}

# I don't really understand why this end block is necessary to avoid 
warnings
END
{
	undef $searchwindow;
}

#package to encapsulate the 'Employee Selector' control
# subclass of Window, so that I don't have to implement
# Move()/Show() etc.
package EmployeeSelector;
use strict;
use warnings;
use Win32::GUI;
use base qw(Win32::GUI::Window);

#The constructor
sub new
{
	my ($class, $parent, $xcor, $ycor)=@_;

	#Create window
	my $self = $class->SUPER::new(
		-parent    => $parent,
		-pos       => [$xcor,$ycor],
		-size      => [150, 24],
		-popstyle  => WS_CAPTION | WS_SIZEBOX,
		-pushstyle => WS_CHILD | WS_CLIPCHILDREN | WS_VISIBLE,
	);

	#Create other controls
	$self->AddLabel(
		-text   => 'ID#',
		-pos    => [0,6],
		-size   => [20,20],
	);
	$self->AddTextfield(
		-name   => "EMPID",
		-pos   => [20,2],
		-size  => [35,20],
		-tip    => 'Employee ID',
	);
   $self->AddButton (
		-text   => 'Search',
		-pos    => [60,2],
		-size  => [60,20],
		-tip    => 'Search for a Employee  ID',
		-onClick => sub{Search($self)},  # closure
		                                 # wouldn't it be nice to have
		                                 # a way to navigate up to parent
		                                 # objects as well as down to children
	);

	return $self;
}

sub Search
{
	my $self = shift;

	my $result = SearchWindow::DoSearch();
	$self->SetEmpID($result) if $result;

	return 1;
}

sub SetEmpID
{
	my $self=shift;
	$self->EMPID->Text(shift);
}


Jeremy White wrote:
>> This is a known bug with win32-gui.
>> It is fixed by using perl 5.7 or later or using the circular ref patch
> 
> 
> Ok - I've created a tracker item so this issue isn't lost:)
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=1248578&group_id=16572&atid=116572 
> 
> 
> I've just ran that example under 5.8.7 and it still crashed?
> 
>> I posted to the list during the 1.02 release cycle. A similar section 
>> was applied some years ago, but removed because older perl don't allow 
>> circular refs at all.
> 
> 
> I just searched the archive but it doesn't show any attachments - could 
> you forward it again so I can see if it fixes the problem?
> 
> Cheers,
> 
> jez.
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> 

Re: [win32gui] RE: [perl-win32-gui-hackers] -background option and windows

[Jeremy W. <jez...@ho...>]

>>I've just had a look at the Visual .Net environment and you can specify 
>>the backcolor of a window (and the background image)
>
>It would be possible to allow the -background option to take a 
>Win32::GUI::Brush as a value.  This would allow bitmaps as patterns for the 
>background;  but it would start to be very confusing for controls, where 
>-background also specifies the text background colour.  I don't propose to 
>do this - if you really want it use a class.

Sorry - was my poor explanation. I meant that there is an additional option 
to set the background image:)

>I'll have a look at implementing this.

>BTW I've got the fix for class backgrounds not working in perl's 5.8 and 
>higher.

If you want me to test anything let me know.

Cheers,

jez.

Re: [win32gui] RE: [perl-win32-gui-hackers] -background option and windows

[Robert M. <rm...@po...>]

Jeremy White wrote:
>> (1) It appears that the '-background' option was never intended to 
>> work with  windows (Win32::GUI::Window, Win32::GUI::Dialog) and that 
>> the only way to change the background colour of a window is using the 
>> -class option with a coloured brush.   It might be possible to extend 
>> the WM_PAINT and/or WM_ERASEBKGND handlers to cope with this - is it 
>> work exploring?
> 
> I've just had a look at the Visual .Net environment and you can specify 
> the backcolor of a window (and the background image)

It would be possible to allow the -background option to take a 
Win32::GUI::Brush as a value.  This would allow bitmaps as patterns for 
the background;  but it would start to be very confusing for controls, 
where -background also specifies the text background colour.  I don't 
propose to do this - if you really want it use a class.

> The 
> problem with using a class to set the background is that you can't 
> change it during runtime.

I hadn't spotted this.

> Setting the background of a window does seem to crop up now and again - 
> and I've been stung with it several times - so a solution would be nice 
> - but how much work would be involved with the fiddling of 
> WM_PAINT/WM_ERASEBKGND? Is there a risk of it breaking other things? 
> Performance?

 From what I've seen I don't think it would be hard, but I would be 
concerned about regression testing, as I don't yet have enough 
experience in this area to be confident of understanding the behaviour 
of everything.

Performance - you'd only take a hit if you had the -background option 
set, and the background needs erasing anyway - it's just a question of 
whether Win32::GUI does it of it's done by DefWindowProc.

I'll have a look at implementing this.

BTW I've got the fix for class backgrounds not working in perl's 5.8 and 
higher.

Regards,
Rob.

RE: [perl-win32-gui-hackers] -background option and windows

[Jeremy W. <jez...@ho...>]

>I've been looking at a few of the bug reports regarding background colours 
>of windows/controls.
>
>(1) It appears that the '-background' option was never intended to work 
>with  windows (Win32::GUI::Window, Win32::GUI::Dialog) and that the only 
>way to change the background colour of a window is using the -class option 
>with a coloured brush.   It might be possible to extend the WM_PAINT and/or 
>WM_ERASEBKGND handlers to cope with this - is it work exploring?

I've just had a look at the Visual .Net environment and you can specify the 
backcolor of a window (and the background image) in the Designer - now, how 
this is achieved under the hood is a different matter:) The problem with 
using a class to set the background is that you can't change it during 
runtime.

Setting the background of a window does seem to crop up now and again - and 
I've been stung with it several times - so a solution would be nice - but 
how much work would be involved with the fiddling of WM_PAINT/WM_ERASEBKGND? 
Is there a risk of it breaking other things? Performance?

Cheers,

jez.

[perl-win32-gui-hackers] -background option and windows

[Robert M. <rm...@po...>]

I've been looking at a few of the bug reports regarding background 
colours of windows/controls.

(1) It appears that the '-background' option was never intended to work 
with  windows (Win32::GUI::Window, Win32::GUI::Dialog) and that the only 
way to change the background colour of a window is using the -class 
option with a coloured brush.   It might be possible to extend the 
WM_PAINT and/or WM_ERASEBKGND handlers to cope with this - is it work 
exploring?

[-background, should work with most controls (but not Buttons - see 
MSDN).  However, class brushes are ignored for such controls - I have a 
fix for this.]

(2) Does anyone know or have any opinions on what the behaviour for a 
RichEdit control in readonly mode with a given background colour should 
be.   Current behaviour is that if no -background option is given then 
the background is 'white' (COLOR_WINDOW) when read/write and 'grey' 
(COLOR_BTNFACE) when readonly.  If a -background option is given, then 
this colour is used regardless.  My view is that this is a reasonable 
approach, but I thought I'd ask.

Rob.

Re: [perl-win32-gui-hackers] Using Windows as Objects

[Jeremy W. <jez...@ho...>]

>This is a known bug with win32-gui.
>It is fixed by using perl 5.7 or later or using the circular ref patch

Ok - I've created a tracker item so this issue isn't lost:)

https://sourceforge.net/tracker/index.php?func=detail&aid=1248578&group_id=16572&atid=116572

I've just ran that example under 5.8.7 and it still crashed?

>I posted to the list during the 1.02 release cycle. A similar section was 
>applied some years ago, but removed because older perl don't allow circular 
>refs at all.

I just searched the archive but it doesn't show any attachments - could you 
forward it again so I can see if it fixes the problem?

Cheers,

jez.

Re: [win32gui] Re: [perl-win32-gui-hackers] Web Presence

[Reini U. <ru...@x-...>]

Robert May schrieb:
> It'll take me a couple of days to get this website up and running, as I 
> don't have enough permissions to remove/edit the existing files on the 
> shell server - I have a support call going through now.

There's an easy trick to get the sf.net edit perms for any file created 
by somebody else.

~/bin/my:

#!/bin/sh
if [ -z "$1" ]; then echo "usage $0 file"; exit; fi
if [ ! -f "$1" ]; then echo "$1 does not exist"; exit; fi
if [ -w "$1" ]; then echo "$1 is already writable"; exit; fi

mv -f "$1" "$1.temp"
cp "$1.temp" "$1"
chmod g+w $1
rm -f "$1.temp"

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

Re: [perl-win32-gui-hackers] Using Windows as Objects

[Reini U. <ru...@x-...>]

Jeremy White schrieb:
> Except for when you exit, and a crash occurs (perl 5.6 GUI 1.02 Attempt 
> to free unreferenced scalar at C:/Perl/site/lib/Win32/GUI.pm line 3266). 
> I do create a circular link, with a closure being used to 'remember the 
> object (In my own application, the closure is of the window, not an 
> object that contains it, and this doesn't crash). I'm not sure if this 
> is a bug within win32-gui or my code?

This is a known bug with win32-gui.
It is fixed by using perl 5.7 or later or using the circular ref patch
I posted to the list during the 1.02 release cycle. A similar section 
was applied some years ago, but removed because older perl don't allow 
circular refs at all.

Remember to DESTROY any dangling circular refs with perl <= 5.6.

> Or is there a better way to create a perl object that can handle both 
> method calls and events?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
http://phpwiki.org/

[perl-win32-gui-hackers] Using Windows as Objects

[Jeremy W. <jez...@ho...>]

Hi,

I've been putting together an example of several of the techniques I use 
when building a GUI. One of the things I do is to use lots of child windows 
to encapsulate many controls and functionality into one logical package. 
This works really well for me, but is still on the 'messy' side, so I've 
tried to encapsulate all functionality (event handling and method calls) 
into a single perl object that could be used throughout the application.

The example below is rather simple, but should explain the concept. In a 
hypothetical application, the user needs to be able to select the Employee 
ID in lots of places in the application. As well as being able to type in 
the ID directly, the user might also want to search for the ID. Rather than 
create lots of individual controls, an object does all the work for you...

Except for when you exit, and a crash occurs (perl 5.6 GUI 1.02 Attempt to 
free unreferenced scalar at C:/Perl/site/lib/Win32/GUI.pm line 3266). I do 
create a circular link, with a closure being used to 'remember the object 
(In my own application, the closure is of the window, not an object that 
contains it, and this doesn't crash). I'm not sure if this is a bug within 
win32-gui or my code?

Or is there a better way to create a perl object that can handle both method 
calls and events?

Thoughts?

Cheers,

jez.

---------------------
use strict;
use Win32::GUI;

#We init the EmployeeSelector class
EmployeeSelector::Init();

# Create the main window
my $mainwindow = new Win32::GUI::Window(
    -name   => "Window",
    -title  => "Objects and Windows",
    -pos    => [100,100],
    -size   => [400,400],
);
$mainwindow->Show();

#We now create several employee selector 'controls'.
my $search1=EmployeeSelector->new($mainwindow,20,20);
my $search2=EmployeeSelector->new($mainwindow,20,50);
my $search3=EmployeeSelector->new($mainwindow,20,80);
my $search4=EmployeeSelector->new($mainwindow,20,110);
my $search5=EmployeeSelector->new($mainwindow,20,140);
#Show all our controls
$search1->Show();
$search2->Show();
$search3->Show();
$search4->Show();
$search5->Show();
$search2->Move(200,200);

#Enter the message processing loop
Win32::GUI::Dialog();

package EmployeeSelector;
  #Class spefic globals
  my $searchwindow; #The search window
  my $active;       #The active object

sub Init {
  #This is a class function, and is used to initilise all objects
  $searchwindow = new Win32::GUI::DialogBox(
    -name   => "EmployeeSelector",
    -title  => "Search for Employee",
    -size   => [300,270],
  );
  $searchwindow->AddListView(
    -name => 'ListView',
    -pos    => [8,8],
    -size   => [280,189],
    -fullrowselect=> 1,
  );
  $searchwindow->AddButton (
    -name   => 'OK',
    -text   => 'OK',
    -pos    => [164,208],
    -size   => [60,21],
    #When we click ok, we populate the calling controls EmpID
    -onClick => sub {my $item=$searchwindow->ListView->SelectedItems();
                     my %hItem=$searchwindow->ListView->ItemInfo($item,0);
                     $active->SetEmpID($hItem{-text});
                     return -1;
                     },
  );
  $searchwindow->AddButton (
    -name   => 'Cancel',
    -text   => 'Cancel',
    -pos    => [228,208],
    -size   => [60,21],
    -onClick => sub {return -1},
  );
  #populate the list view
  $searchwindow->ListView->InsertColumn(-width => 55,-text  => 'Emp ID');
  $searchwindow->ListView->InsertColumn(-width => 205,-text  => 'Employee 
Name');
  $searchwindow->ListView->InsertItem(-text => [1234, 'Bob Smith']);
  $searchwindow->ListView->InsertItem(-text => [4321, 'Peter Jones']);
  $searchwindow->ListView->InsertItem(-text => [7890, 'John Brown']);
}

#The constructor
sub new {
  my $proto = shift;
  my $class = ref($proto) || $proto;
  my $self  = {};
  bless ($self, $class);
  my ($parent,$xcor,$ycor)=@_;
  #Create window
  my $childwin = new Win32::GUI::Window (
      -parent      => $parent,
      -name        => "ChildWin",
      -pos         => [$xcor,$ycor],
      -size        => [150, 24],
      -popstyle    => Win32::GUI::WS_CAPTION | Win32::GUI::WS_SIZEBOX,
      -pushstyle   => Win32::GUI::WS_CHILD | Win32::GUI::WS_CLIPCHILDREN,
      );
  #add the window to the object
  $self->{win}=$childwin;
  #Create other controls
$childwin->AddLabel(
    -name   => 'Label',
    -text   => 'ID#',
    -height => 20,
    -width  => 20,
    -top    => 6,
    -left   => 0,
  );
  $childwin->AddTextfield (
    -name   => 'EmpID',
    -height => 20,
    -width  => 35,
    -top    => 2,
    -left   => 20,
    -tip    => 'Employee ID',
  );
  $childwin->AddButton (
    -name   => 'Search',
    -text   => 'Search',
    -height => 20,
    -width  => 60,
    -top    => 2,
    -left   => 60,
    -tip    => 'Search for a Employee  ID',
    #$self will become a closure
    -onClick => sub {Search($self)},
);
  return $self;
}

sub Search {
  #Open the search window - can be called as a method or as an event handler
  my $self=shift;
  #Set the active object to be this object
  $active=$self;
  $searchwindow->Center;
  $searchwindow->DoModal(1);
}

sub SetEmpID {
  #Set the EmpID of the text box - can be called as a method or as an event 
handler
  my $self=shift;
  $self->{win}->EmpID->Text(shift);
}

sub Show {
  #Show the window
  my $self=shift;
  $self->{win}->Show();
}

sub Hide {
  #Hide the window
  my $self=shift;
  $self->{win}->Hide();
}

sub Move {
  #Move the window
  my $self=shift;
  $self->{win}->Move(@_);
}

sub DESTROY {
  #We have a circular link(?)
  my $self=shift;
  print 'in Destroy'.$self;
  $self->{win}=undef;
}

Re: [win32gui] Re: [perl-win32-gui-hackers] Web Presence

[Robert M. <rm...@po...>]

Reini Urban wrote:
>> (1) Whether it lays out nicely in your browser, or whether it screws up.
> looks fine for firefox and MSIE6.
Great - thanks.
>> (4) Your Technical comments
> http://www.robmay.me.uk/win32gui/website/docs/Win32/GUI.html TOC
> Typo:
>     * Introdction
Got it.  That was in the pod documentation, and had propagated to the 
nav bar on the right-hand side too.

>> (5) Anything that you'd like to see in the future.
> Screenshots as jeremy already noted
On my list.  Anyone have some nice Win32::GUI apps they'd be happy to 
take some screenshots of and contribute?

> and maybe put/link Aldo's old 
> examples somewhere, even if some of them don't work out of the box anymore.

I don't think that we should be pointing people at examples that don't 
work.  I have on my list to add to the distribution source for all the 
examples in the tutorial (and to fix the tutorial where it is currently 
incorrect)

> maybe add a wiki to let people add their samples. There cannot be enough 
> samples.
Indeed.  I want to get a Wiki up and running, and had been wondering 
what to seed it with.  I think re-works of Aldo's original samples and 
the existing samples would be a great start.  I have a couple of samples 
  (drag and drop in a list view, toolbar and threads) that I need to 
finish and will add.

Right now, I intend to take the existing Wiki down (I'll check, but I 
don't think there is any useful content in it), upgrade it to the latest 
Kwiki version, brand it and get it back online, linked from the 
homepage.  It'll take me a few weeks though!

It'll take me a couple of days to get this website up and running, as I 
don't have enough permissions to remove/edit the existing files on the 
shell server - I have a support call going through now.

Regards,
Rob.