RE: [perl-win32-gui-users] Anyone help?

[Stephen Pick]

Hi,
 
Could be that I broke this when upping the _WIN32_IE constant to 0x0501. If you 
put that back to 0x0400 does it work again?
 
Steve

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Laurent ROCHER
Sent: 25 February 2004 19:02
To: [EMAIL PROTECTED]; perl-win32-gui-users@lists.sourceforge.net
Subject: Re: [perl-win32-gui-users] Anyone help?


Hi,
 
Same problem for me. It's a problem of not up to date include file. 
For correct problem, i have tested those 3 methods.
[RED = removeBLUE = Add ]
 
1) Small change in Win32-GUI source but warming messag.
 
edit GUI.h and add this line :
#define  WIN32_LEAN_AND_MEAN
#define _WIN32_IE 0x0501
#define _WIN32_WINNT 0x0400
#define WINVER 0x0501

Now it's work, but you have a warming message.
 
2) Hack your default Windows.h header in include directory
 
#ifndef WINVER
#define WINVER 0x0400 0x0501
#else 
#if defined(_WIN32_WINNT)  (WINVER  0x0400)  (_WIN32_WINNT  0x0400)
#error WINVER setting conflicts with _WIN32_WINNT setting
#endif
#endif
 
#if(WINVER = 0x0500)
#pragma message ()
#pragma message (NOTE: WINVER has been defined as 0x0500 or greater which 
enables)
#pragma message (Windows NT 5.0 and Windows 98 features. When these headers 
were released,)
#pragma message (Windows NT 5.0 beta 1 and Windows 98 beta 2.1 were the 
current versions.)
#pragma message ()
#pragma message (For this release when WINVER is defined as 0x0500 or greater, 
you can only)
#pragma message (build beta or test applications.  To build a retail 
application,)
#pragma message (set WINVER to 0x0400 or visit  
http://www.microsoft.com/msdn/sdk http://www.microsoft.com/msdn/sdk;)
#pragma message (to see if retail Windows NT 5.0 or Windows 98 headers are 
available.)
#pragma message ()
#pragma message (See the SDK release notes for more information.)
#pragma message ()
#endif
 
This force default WINVER and remove warning message.
It's probably not very safe if you use VC for other building.
 
3) You need to download and install last microsoft SDK.
 
  see: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm
  You need core SDK. It's a huge download.
 
Laurent.


I downloaded the updated files  and tried to build under Windows 2000
but I am getting the error below. Any help would be appreciated.
It would be nicer if the new updated version can be packed and update
the version number. I remember also I installed before the binary version
and was unable to build  from the source. I have VC6 on the computer.

GUI.xs(2031) : warning C4101: 'targ' : unreferenced local variable
GUI.xs(2289) : error C2065: 'WINDOWINFO' : undeclared identifier
GUI.xs(2289) : error C2146: syntax error : missing ';' before identifier
'pwi'
GUI.xs(2289) : error C2065: 'pwi' : undeclared identifier
...
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.

Ramy

RE: [perl-win32-gui-users] Shipping resources with your exe

[Stephen Pick]

Well, we can't support PAR because currently it's kind of a stop-gap
solution used by those who don't want to or cannot buy perlapp/perl2exe
(like me). If you must use PAR then there is nothing stopping you from
using the PAR options to include bitmaps and other files inside the PAR
file. When your program is executed these will be extracted and will be
available in the temporary directory used by PAR (which I believe can be
found in @INC). You can then do something like this:

my $resource = Win32::GUI::LoadResource(some.file) || do
{open(FILE,,some.file);binmode(FILE);join('',FILE)};

Which should revert to a disk copy if LoadResource fails to find the
resource. Alternatively you can use this to auto-generate perl hex code
for files and stick the files right into your script:

open(DATA,,test.bmp);
my $data;
sysread(DATA,$data,(stat(DATA))[7]);
close(DATA);
my $output = '$VAR = ';
for(my $i = 0; $i  length($data); $i++) {
$output .= sprintf('\x%02x',ord(substr($data,$i,1)));
if($i % 80 == 0) { $output .= \.\n   \ };
}
$output .= \;\n;
print $output;

I now have confirmations from people that both Perl2Exe and PerlApp work
OK with LoadResource and the additions to the LoadImage routine (meaning
EXE is checked first when loading bitmap, cursor and icon files). PAR
will need to mature a bit (i.e. dump the whole extracted bundle thing
and use an in-exe resource like the other perl exe makers do) before it
will really make the grade for me, I'm afraid. By the way, I'm not
making PAR exempt from the use of this new functionality on purpose,
it's just that PAR cannot possibly work with it yet.

Steve

 -Original Message-
 From: Glenn Linderman [mailto:[EMAIL PROTECTED]
 Sent: 19 February 2004 17:57
 To: Stephen Pick
 Cc: Jez White; Win32-GUI
 Subject: Re: [perl-win32-gui-users] Shipping resources with your exe
 
 
 It would probably be sufficient to support PAR.  Even if ActiveState 
 gave you the free copy, it isn't likely they'd give it to 
 everyone, so 
 everyone is more likely to use PAR, in the long term (once 
 it's growing 
 pains are over).  Of course, if AS does supply you a free 
 copy, I have 
 no objections to your support of it, along with PAR.
 
 Looking at the global issue, I wonder if it might not be possible to 
 create a DLL containing all the resources for a particular Win32::GUI 
 program, and then, whether the program is running via 
 perl.exe, or via 
 PAR, or even Perl2Exe or PerlApp, that somehow that one DLL would be 
 referenced for all the resource needs of the program.
 
 
 On approximately 2/19/2004 2:02 AM, came the following characters from
 the keyboard of Stephen Pick:
 
  I didnt mean to suggest we start modifying the perl exe :) 
 That would be 
  crazy.
   
  I meant that microsoft provides certain functions that let you add, 
  remove and update resources in an executable, you just have 
 to pass the 
  handle to the module who's executable file needs to have 
 its resources 
  played with. There are ways of finding what this handle is for the 
  current running thread (although I'm not sure what they are 
 right now), 
  but I'm not sure what file it would pick up as the current running 
  thread when running under perl.exe -- it may pick up 
 GUI.dll, or it may 
  pick up perl.exe. So while, say, an UpdateResource call may 
 work in the 
  real executable it will probably cause unexpected results 
 when running 
  under perl.exe.
   
  Another problem that I've yet to test is to do with the 
 various pl - 
  exe converters out there. I'm not sure of PerlApp (the 
 best, but $400, 
  so sod that...) or Perl2Exe (also costly) but PAR 
 executables are simply 
  a depacker that unpacks a perl interpreter and appropriate 
 packages to a 
  temporary directory then runs that perl interpreter to execute your 
  program. It's a good chance that UpdateResource commands (and even 
  LoadBitmap et al) would not pick up the exe file that you actually 
  executed when searching for resources, but would actually 
 pick up the 
  perl interpreter or GUI.dll that had been packed into the 
 PAR executable.
   
  As a developer of Win32::GUI I'm sure ActiveState would be 
 very happy to 
  give me a free copy of the Perl Dev Kit to aid in my work! 
 (yeah, right.)
   
  Steve
   
  
  -Original Message-
  From: [EMAIL PROTECTED]
  
 [mailto:[EMAIL PROTECTED] Behalf
  Of Jez White
  Sent: 19 February 2004 09:46
  To: Steve Pick; Win32-GUI
  Subject: Re: [perl-win32-gui-users] Shipping resources 
 with your exe
  
  I agree with your analysis - I especially like the idea 
 of bitmaps,
  Icons and cursors to check for resources first, and 
 then to look at
  the file system (would solve the problem of running in 
 dev mode
  with the perl command line, or running the exe direct).
   
  How easy would it to be load other binary objects in 
 from the exe?
  For example, having other image formats

RE: [perl-win32-gui-users] Shipping resources with your exe

[Stephen Pick]

I didnt mean to suggest we start modifying the perl exe :) That would be crazy.
 
I meant that microsoft provides certain functions that let you add, remove and 
update resources in an executable, you just have to pass the handle to the 
module who's executable file needs to have its resources played with. There are 
ways of finding what this handle is for the current running thread (although 
I'm not sure what they are right now), but I'm not sure what file it would pick 
up as the current running thread when running under perl.exe -- it may pick up 
GUI.dll, or it may pick up perl.exe. So while, say, an UpdateResource call may 
work in the real executable it will probably cause unexpected results when 
running under perl.exe.
 
Another problem that I've yet to test is to do with the various pl - exe 
converters out there. I'm not sure of PerlApp (the best, but $400, so sod 
that...) or Perl2Exe (also costly) but PAR executables are simply a depacker 
that unpacks a perl interpreter and appropriate packages to a temporary 
directory then runs that perl interpreter to execute your program. It's a good 
chance that UpdateResource commands (and even LoadBitmap et al) would not pick 
up the exe file that you actually executed when searching for resources, but 
would actually pick up the perl interpreter or GUI.dll that had been packed 
into the PAR executable.
 
As a developer of Win32::GUI I'm sure ActiveState would be very happy to give 
me a free copy of the Perl Dev Kit to aid in my work! (yeah, right.)
 
Steve
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 19 February 2004 09:46
To: Steve Pick; Win32-GUI
Subject: Re: [perl-win32-gui-users] Shipping resources with your exe


I agree with your analysis - I especially like the idea of bitmaps, Icons and 
cursors to check for resources first, and then to look at the file system 
(would solve the problem of running in dev mode with the perl command line, 
or running the exe direct). 
 
How easy would it to be load other binary objects in from the exe? For example, 
having other image formats or storable created objects.
 
As for adding resources - I can see the benefits of having a native solution, 
but it would create massive scope to mess around with the perl exe:) Perhaps 
the first step is to point to ResHacker, with a step by step guide on how to 
use it?
 
jez.
 
 

- Original Message - 
From: Steve Pick mailto:[EMAIL PROTECTED]  
To: Jez White mailto:[EMAIL PROTECTED]  ; Win32-GUI 
mailto:perl-win32-gui-users@lists.sourceforge.net  
Sent: Wednesday, February 18, 2004 10:40 PM
Subject: Re: [perl-win32-gui-users] Shipping resources with your exe

I'd find this functionality kinda handy. Loading resources from the exe is very 
simple, and it would not be too difficult to extend the Win32::GUI::Bitmap, 
Icon, etc. objects to accept an additional argument that indicates that the 
resource should be loaded from the exe rather than from a real file on disk (in 
fact, it would actually be a trivial matter to do this).
 
What is less trivial is getting the resources in there in the first place. 
While ResHacker lets you do it, it'd be nice to see a Win32::GUI native way of 
doing it. Microsoft provides functions for adding, deleting and replacing 
resources in executable files and I propose we either:
 
1. Add this update/add/delete functionality into Win32::GUI so that 
applications can fiddle with their own resources. This may be an exceptionally 
bad idea (what exe file will it think it's using when running straight from 
Perl? We dont want it messing with perl.exe's resources)
 
2. Create a small tool that is distributed with Win32::GUI to pack resources 
into the exe. I doubt we can re-dist ResHacker with win32::gui and it'd be nice 
if there was this functionality provided. The Win32::GUI::Bitmap, Icon and 
Cursor objects could then be modified to first check for a resource identified 
by the given filename in the current running exe, and if it's not found attempt 
to use the given filename to load an external file. This seems the best mode of 
operation to me.
 
Steve

- Original Message - 
From: Jez White mailto:[EMAIL PROTECTED]  
To: Win32-GUI mailto:perl-win32-gui-users@lists.sourceforge.net  
Sent: Wednesday, February 18, 2004 6:34 PM
Subject: [perl-win32-gui-users] Shipping resources with your exe

Hi,
 
One the problems I have when I ship my exe is ensuring that all the resources 
(bitmaps, cursors and config files) are valid when my app starts up. Typically, 
just including them in a sub directory can cause problems since the user could 
delete or alter them. The ideal solution would be to package the resources into 
the exe and extract them at runtime. See: 
 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/Resources.asp
 
Adding the resources to the exe is quite straightforward (with reshacker) but 
I'm not sure how easy 

RE: [perl-win32-gui-users] Shipping resources with your exe

[Stephen Pick]

Hi peter,
 
I just tried the free version of it and it doesnt do what PAR does. I added a 
little line to LoadImage in GUI.xs to see what it thought it's current exe was. 
The results:
 
Running perl:
Loading image 0 - current EXE: C:\Perl\bin\perl.exe
 
Running PAR packed exe (ouch...):
Loading image 0 - current EXE: 
C:\DOCUME~1\id909774\LOCALS~1\Temp\par_priv.1732.tmp\par.exe
 
Running perl2exe packed exe:
Loading image 0 - current EXE: C:\junk\Win32-GUI-0.0.665\samples\toolbar.exe
 
Nice. So if you want this functionality you're gonna have to use a decent pl - 
exe packer. I'll get onto the code and a CVS commit soon!
 
Steve
 

-Original Message-
From: Straub, Peter (Peter) [mailto:[EMAIL PROTECTED]
Sent: 19 February 2004 10:26
To: Stephen Pick; Jez White; Win32-GUI
Subject: RE: [perl-win32-gui-users] Shipping resources with your exe


I have been using perl2exe for quite some time and I'm quite sure that it does 
the trick in the way that you describe for PAR.
Cheers,
Peter

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Stephen Pick
Sent: Thursday, 19 February, 2004 11:02
To: Jez White; Win32-GUI
Subject: RE: [perl-win32-gui-users] Shipping resources with your exe


I didnt mean to suggest we start modifying the perl exe :) That would be crazy.
 
I meant that microsoft provides certain functions that let you add, remove and 
update resources in an executable, you just have to pass the handle to the 
module who's executable file needs to have its resources played with. There are 
ways of finding what this handle is for the current running thread (although 
I'm not sure what they are right now), but I'm not sure what file it would pick 
up as the current running thread when running under perl.exe -- it may pick up 
GUI.dll, or it may pick up perl.exe. So while, say, an UpdateResource call may 
work in the real executable it will probably cause unexpected results when 
running under perl.exe.
 
Another problem that I've yet to test is to do with the various pl - exe 
converters out there. I'm not sure of PerlApp (the best, but $400, so sod 
that...) or Perl2Exe (also costly) but PAR executables are simply a depacker 
that unpacks a perl interpreter and appropriate packages to a temporary 
directory then runs that perl interpreter to execute your program. It's a good 
chance that UpdateResource commands (and even LoadBitmap et al) would not pick 
up the exe file that you actually executed when searching for resources, but 
would actually pick up the perl interpreter or GUI.dll that had been packed 
into the PAR executable.
 
As a developer of Win32::GUI I'm sure ActiveState would be very happy to give 
me a free copy of the Perl Dev Kit to aid in my work! (yeah, right.)
 
Steve
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 19 February 2004 09:46
To: Steve Pick; Win32-GUI
Subject: Re: [perl-win32-gui-users] Shipping resources with your exe


I agree with your analysis - I especially like the idea of bitmaps, Icons and 
cursors to check for resources first, and then to look at the file system 
(would solve the problem of running in dev mode with the perl command line, 
or running the exe direct). 
 
How easy would it to be load other binary objects in from the exe? For example, 
having other image formats or storable created objects.
 
As for adding resources - I can see the benefits of having a native solution, 
but it would create massive scope to mess around with the perl exe:) Perhaps 
the first step is to point to ResHacker, with a step by step guide on how to 
use it?
 
jez.
 
 

- Original Message - 
From: Steve  mailto:[EMAIL PROTECTED] Pick 
To: Jez White mailto:[EMAIL PROTECTED]  ; Win32-GUI 
mailto:perl-win32-gui-users@lists.sourceforge.net  
Sent: Wednesday, February 18, 2004 10:40 PM
Subject: Re: [perl-win32-gui-users] Shipping resources with your exe

I'd find this functionality kinda handy. Loading resources from the exe is very 
simple, and it would not be too difficult to extend the Win32::GUI::Bitmap, 
Icon, etc. objects to accept an additional argument that indicates that the 
resource should be loaded from the exe rather than from a real file on disk (in 
fact, it would actually be a trivial matter to do this).
 
What is less trivial is getting the resources in there in the first place. 
While ResHacker lets you do it, it'd be nice to see a Win32::GUI native way of 
doing it. Microsoft provides functions for adding, deleting and replacing 
resources in executable files and I propose we either:
 
1. Add this update/add/delete functionality into Win32::GUI so that 
applications can fiddle with their own resources. This may be an exceptionally 
bad idea (what exe file will it think it's using when running straight from 
Perl? We dont want it messing with perl.exe's resources)
 
2. Create a small tool that is distributed with Win32::GUI to pack resources 
into the exe. I

RE: [perl-win32-gui-users] New Win32 Package suggestion and sample code

[Stephen Pick]

Eh?
 
Win32::API *can* be included in compiled .exe perl scripts. What packer are you 
using?
 
Steve 
 
 -Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED]
Sent: 19 February 2004 11:02
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] New Win32 Package suggestion and sample code



Hello All,
 
I am suggesting we start a new package for Win32 like say Win32::Windows or 
Win32::General
where in this package we can add or request a specific windows functions that 
is not already included
in Win32 current packages. For example, I needed to get the Memory status 
function I know there is a module
called Sysinfo or so but is used by callng WIn32::API which can not currently 
included with compiled .exe perl scripts
therefore it was a must for me to build s little module for this function. 
However every little time I needed one other
function. Here is a code to get the memory ststus function and it is tested and 
working.
Any one is welcomed to start this package and set the rules for it.
 
TODO: of course anyone can help adding these needed by everyone:
 
1)- Loading Windows Help files using WinHelp function:
 
BOOL WinHelp(
HWND hWndMain,
LPCTSTR lpszHelp,
UINT uCommand,
DWORD dwData
);
 
WinHelp(ghWndMain, gszHELPfilename, HELP_QUIT, 0); // unload help 

2)-Getting and changing the .DLL and .EXE version information, specially
these info is not updated to your compied .exe usig perlapp or perl2exe
if you see any .exe file you generated by windows explorer property it
will refer to indygostar website and perl.exe file only.
 
VS_VERSIONINFO { 
WORD  wLength; 
WORD  wValueLength; 
WORD  wType; 
WCHAR szKey[]; 
WORD  Padding1[]; 
VS_FIXEDFILEINFO Value; 
WORD  Padding2[]; 
WORD  Children[]; 
}; 

typedef struct _VS_FIXEDFILEINFO {  // vsffi 
DWORD dwSignature; 
DWORD dwStrucVersion; 
DWORD dwFileVersionMS; 
DWORD dwFileVersionLS; 
DWORD dwProductVersionMS; 
DWORD dwProductVersionLS; 
DWORD dwFileFlagsMask; 
DWORD dwFileFlags; 
DWORD dwFileOS; 
DWORD dwFileType; 
DWORD dwFileSubtype; 
DWORD dwFileDateMS; 
DWORD dwFileDateLS; 
} VS_FIXEDFILEINFO; 
 
// File version
bRetCode = VerQueryValue((LPVOID)lpstrVffInfo,
TEXT(\\StringFileInfo\\040904E4\\FileVersion),
(LPVOID *)lpVersion,
puVersionLen);


 
#
This code for 2 functions, get memory status and get system path directory
calling directly as my @Mems = Win32::MemoryStatus::MemStatus();
 
 
#include EXTERN.h
#include perl.h
#include XSUB.h
#include ppport.h
#include windows.h
 
MODULE = Win32::MemoryStatus  PACKAGE = Win32::MemoryStatus  
 
PROTOTYPES: DISABLE
 #
# GlobalMemoryStatus exists in the  kernel32.dll library
 
void
MemStatus()
 PREINIT:
  MEMORYSTATUS * mem;
 PPCODE:
  GlobalMemoryStatus(mem);
  EXTEND(SP, 8);
  PUSHs(sv_2mortal(newSVuv(mem-dwMemoryLoad)));
  PUSHs(sv_2mortal(newSVuv(mem-dwTotalPhys)));
  PUSHs(sv_2mortal(newSVuv(mem-dwAvailPhys)));
  PUSHs(sv_2mortal(newSVuv(mem-dwTotalPageFile)));
  PUSHs(sv_2mortal(newSVuv(mem-dwAvailPageFile)));
  PUSHs(sv_2mortal(newSVuv(mem-dwTotalVirtual)));
  PUSHs(sv_2mortal(newSVuv(mem-dwAvailVirtual)));
  PUSHs(sv_2mortal(newSVuv(mem-dwLength)));
  XSRETURN(8);
 
void
WinSystemDirectory()
 PREINIT:
  LPTSTR  lpBuff;
  UINT  PathLen;
  int  BufSize;
 PPCODE:
  BufSize = 300;
  lpBuff = (LPTSTR) safemalloc(BufSize);
  PathLen = GetSystemDirectory(lpBuff, BufSize);
  EXTEND(SP, 1);
  PUSHs(sv_2mortal(newSVpv(lpBuff, PathLen)));
  safefree(lpBuff);
  XSRETURN(1);

and this is a perl module suggestion for it, of course it can be called directly
 
 
package Win32::MemoryStatus;
 
#use 5.008002;
use strict;
use warnings;
 
require Exporter;   # to export the constants to the main:: space
require DynaLoader; # to dynuhlode the module.
our @ISA = qw( Exporter DynaLoader );
 
# Items to export into callers namespace by default. Note: do not export
# names by default without a very good reason. Use EXPORT_OK instead.
# Do not simply export all your public functions/methods/constants.
 
# This allows declaration use Win32::MemoryStatus ':all';
# If you do not need this, moving things directly into @EXPORT or @EXPORT_OK
# will save memory.
our %EXPORT_TAGS = ( 'all' = [ qw(
 
) ] );
 
our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } );
our @EXPORT = qw(
 
);
 
our $VERSION = '0.01';
 
#require XSLoader;
#XSLoader::load('Win32::MemoryStatus', $VERSION);
# kernel32.dll
bootstrap Win32::MemoryStatus;
 
sub MemoryStatus{
 
 my @Mems = Win32::MemoryStatus::MemStatus();
 my %Meminfo;
 undef %Meminfo;
 #print join \n=,@Mems;
 
 if ($Mems[7] == 0) {return undef;} #The size in bytes of the MEMORYSTATUS data 
structure.
 
 $Meminfo{MemLoad} = int($Mems[0]);
 $Meminfo{TotalPhys} = 

[perl-win32-gui-users] Commited a LoadResource function

[Stephen Pick]

Hi,

Jez mentioned it'd be neat to be able to load resources other than bitmaps, 
icons and cursors from the EXE file. This would be very useful for packing your 
GUI Loft .gld files into the exe and things. Well, here it is.

Win32::GUI::LoadResource(SomeResourceName); will search the exe of the perl 
interpreter that is currently interpreting your app (in PAR, this will be 
par.exe (as extracted from yourexename.exe), in perlapp and perl2exe it will be 
yourexename.exe. In other words, this wont work under PAR as there doesnt 
appear to be a way to modify the resources of the packed par.exe. PAR is 
annoying), and return the raw data of the resource name you requested as a 
scalar.

You must add your resources to the exe file with the RCDATA type. This type 
means raw data.

If anyone knows of any other perl exe makers that are A) free and B) work then 
please let me know.

Steve

RE: [perl-win32-gui-users] Rebar and toolbar revisited

[Stephen Pick]

Hi,
 
Can you not set the parent to be the handle of the rebar section that you're 
adding the toolbar into? I know not much about rebars but I do know that they 
have HWNDs that would satisfy a toolbars need to have a parent window.
 
Steve

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 19 February 2004 12:11
To: Win32-GUI
Subject: [perl-win32-gui-users] Rebar and toolbar revisited


Hi,
 
For a while I've been playing with rebars, with the goal of ending up with 
something like the attached image...
 
With the recent (excellent) additional methods/styles to the toolbar, I went 
back to the rebar, and tried to add a tool bar to it. I couldn't get the 
toolbar to work when it is used by itself - since it requires a parent on 
creation - but I was able to add a toolbar to a child window, which in turn can 
be added to the rebar. This is not ideal, but does work. See the example below 
(I have used some of the new toolbar styles).
 
Ideally you should be able to add a toolbar, and for that matter a menu 
directly to a rebar control (not via a child window).  I've done some searching 
and came up with the these examples: 
 
http://www.codeguru.com/toolbar/iebars.html  (the attached image was taken from 
this site, included the C code required to create this example).
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_rebar_controls_and_bands.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmfc98/html/_mfc_ctoolbar.3a3a.createex.asp
 
Are these easy changes/additions?
 
Cheers,
 
jez.
 
==
 
use Win32::GUI;
use strict;
 
#Create the imagelist that will be used for the toolbar
my $B1 = new Win32::GUI::Bitmap(one.bmp);
my $B2 = new Win32::GUI::Bitmap(two.bmp);
my $B3 = new Win32::GUI::Bitmap(three.bmp);
my $IL = new Win32::GUI::ImageList(16, 16, 0, 3, 10);
$IL-Add($B1, 0);
$IL-Add($B2, 0);
$IL-Add($B3, 0);
 
#create the main window
my $mainwindow = new GUI::Window(
-title= Win32::GUI::Rebar test,
-left = 100,
-top  = 100,
-width= 600,
-height   = 200,
-name = Window,
-onTerminate = sub { return -1 },
);
 
#create the child window which will contain the toolbar
my $band0 = new Win32::GUI::Window (
-parent= $mainwindow,
-name  = ToolBar,
-popstyle  = WS_CAPTION | WS_SIZEBOX,
-pushstyle = WS_CHILD,
);
 
#create a child window for band 1 of the rebar control, this band will contain 
two buttons
my $band1 = new Win32::GUI::Window (
-parent= $mainwindow,
-name  = Action,
-popstyle  = WS_CAPTION | WS_SIZEBOX,
-pushstyle = WS_CHILD,
);
 
#Add a button to band 1
$band1-AddButton (
 -name = 'Button1',
 -pos  = [0, 1],
 -size = [60, 20],
 -text = 'Button 1',
 -tip  = 'Button 1',
 -onClick = sub {print 'Button 1 clicked' },
);
 
#Add a button to band 1
$band1-AddButton (
 -name = 'Button2',
 -pos  = [65, 1],
 -size = [60, 20],
 -text = 'Button 2',
 -tip  = 'Button 2',
 -onClick = sub {print 'Button 2 clicked' },
);
 
#create a rebar control
my $rebar; 
$rebar = $mainwindow-AddRebar(
-name   = Rebar,
-bandborders = 1,
#-fixedorder  = 1,
-onHeightChange = sub {print 'Rebar_HeightChange'.$rebar-Height;},
);
 
#Insert band 1
$rebar-InsertBand (  
  -child = $band0,
  -width = 100,
  -minwidth  = 100,
  -minheight = 24,
);
#Insert band 2
$rebar-InsertBand (  
  -child = $band1,
  -width = 130,
  -minwidth  = 130,
  -minheight = 24,
);
 
#Add the toolbar to band 0
my $TB = $band0-AddToolbar(
-name   = Toolbar,
-nodivider = 1,
-onButtonClick = sub {my ($self,$button)[EMAIL PROTECTED];print  button 
$button clicked;},
);
#Set the image list, and add the styles 
$TB-SetImageList($IL);
$TB-SetStyle(TBSTYLE_FLAT|TBSTYLE_TRANSPARENT|1|TBSTYLE_LIST|TBSTYLE_TOOLTIPS);
$TB-SetExtendedStyle(0x0008);  
#Add the buttons
$TB-AddButtons(
4,
0, 1, 4, 0, 0,
1, 2, 4, 0, 1,
0, 0, 0, TBSTYLE_SEP, 0,
2, 3, 4, 0, 2,
);
#add the tooltips
$TB-AddString(One);
$TB-AddString(Two);
$TB-AddString(Three);
 
#show the main window
$mainwindow-Show;
 
Win32::GUI::Dialog;

 

RE: [perl-win32-gui-users] ActivePerl 5.8.3 build 809

[Stephen Pick]

I'm sticking with 5.8.0 for the time being, for Win32::GUI stuff at least.

I was also wondering, does anybody compile with MS VS .NET? If so is there any 
way to stop it requiring the MSVCRT70.DLL and similar 7.0 DLLs that most people 
don't have?

Steve

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Karl Hakmiller
 Sent: 16 February 2004 21:51
 To: Perl-Win32-GUI-Users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] ActivePerl 5.8.3 build 809
 
 
 I've been struggling with earlier installs of ActivePerls but 
 this release
 installs easily and cleanly.  Very nice build for those who 
 are interested.
 
 Karl L
 
 
 
 ---
 SF.Net is sponsored by: Speed Start Your Linux Apps Now.
 Build and deploy apps  Web services for Linux with
 a free DVD software kit from IBM. Click Now!
 http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

[perl-win32-gui-users] CVS update: Toolbars

[Stephen Pick]

Hi,

I've just spent the morning converting and documenting Rammy's perl toolbar 
functions into XS. They're now in the CVS.

The new functions are as follows:
# (@)METHOD:SetButtonState(BUTTON, STATE)
# (@)METHOD:SetStyle(STYLE)
# (@)METHOD:SetExtendedStyle(STYLE)
# (@)METHOD:GetStyle(STYLE)
# (@)METHOD:MoveButton(BUTTON, TARGET)
# (@)METHOD:SetImageList(IMAGELIST)
# (@)METHOD:SetHotImageList(IMAGELIST)
# (@)METHOD:SetDisabledImageList(IMAGELIST)
# (@)METHOD:GetImageList()
# (@)METHOD:GetHotImageList()
# (@)METHOD:GetDisabledImageList()
# (@)METHOD:ChangeBitmap(BUTTON, BITMAP)
# (@)METHOD:CheckButton(BUTTON, CHECKED)
# (@)METHOD:DeleteButton(BUTTON)
# (@)METHOD:SetToolTips(TOOLTIP)

SetToolTips is not really needed, as you should be able to assign a tooltip 
object using the -tooltip option when constructing the toolbar now. Same thing 
with SetImageList; you should be able to use -imagelist to set an imagelist now.

Note that there is already a Padding() method for the toolbar so I didnt add 
Rammy's padding one which seemed to do a similar thing. I've also (hopefully) 
fixed the tooltips crash application on exit bug that appeared when I ran 
Rammy's test code.

There is some safety checking on SetImageList, AddBitmap and ChangeBitmap. You 
cannot call SetImageList and AddBitmap/ChangeBitmap on the same toolbar as 
microsoft says this would be a really bad idea, so you get a croak about it if 
you try it.

Another thing is, I've modified the ButtonClick event so that when a button 
that has the TBSTYLE_DROPDOWN style applied to it is clicked, an extra argument 
gets passed to ButtonClick with the value of 1. This allows you to tell if you 
need to show a drop-down menu.

There have been a ton of constants added to GUI.pm and GUI_Constants.cpp, so 
you can use most of the regular toolbar styles, extended styles, button styles 
etc. One word of warning is to avoid using the BTNS_*** constants and use the 
TBSTYLE_*** equivalents instead, as the availability of the BTNS_*** constants 
depends on the headers and compiler used (they're a new thing).

I added dwFlags to the USERDATA and CREATESTRUCT structs. This dword is 
intended to store any per-object flags needed. for instance, the toolbar uses 
FLAGS_TB_HASBITMAPS to remember if AddBitmap has been called and complain if 
the user attempts to SetImageList on the same toolbar object. Developers: add 
flags as you see fit.

One last thing. We're running out of mask bits in the NEM. Are they really 
needed? The mask only appears to be used as a speed thing (to avoid doing a 
hash lookup for each event) so perhaps it would be more sensible to group some 
events together or something? Thoughts please...

Steve

RE: [perl-win32-gui-users] Listview Background color change code available

[Stephen Pick]

Cheers Ramy, just added the ability to set the listview background using the 
standard -background option to CVS.
 
Steve

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED]
Sent: 17 February 2004 14:05
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] Listview Background color change code available


 
Hello all
 
Here is a code to change the background for the ListView
 
I still need to change the background color for ComboBox
if any one knows how let me know.
 
#Set the ListView Background Color
sub LVM_FIRST   (){0x1000} #   ListView messages
sub LVM_SETBKCOLOR (){(LVM_FIRST + 1)}
sub LV_SetBkColor{
my ($Handle, $Color) = @_;
 $Handle or return undef;
 defined $Color or return;
 return Win32::GUI::SendMessage($Handle, LVM_SETBKCOLOR, 0, $Color);
}

# Test 
#Call as LV_SetBkColor($Listview, $Color);
LV_SetBkColor($LV, 0x00ff00);
 
Just remember to use these 2 functions to set the foreground and background
of the listview text color when using the above function:
 
$LV-TextBkColor($BkColor);
$LV-TextColor($Color);
 
or when listview scrolls it will wipe out the background color you set
 

Ramy
 

RE: [perl-win32-gui-users] Listview Background color change code available

[Stephen Pick]

Also, you can set Listbox (combobox) background colours with the -background 
option. Works for me (tm).
 
Steve

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED]
Sent: 17 February 2004 14:05
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] Listview Background color change code available


 
Hello all
 
Here is a code to change the background for the ListView
 
I still need to change the background color for ComboBox
if any one knows how let me know.
 
#Set the ListView Background Color
sub LVM_FIRST   (){0x1000} #   ListView messages
sub LVM_SETBKCOLOR (){(LVM_FIRST + 1)}
sub LV_SetBkColor{
my ($Handle, $Color) = @_;
 $Handle or return undef;
 defined $Color or return;
 return Win32::GUI::SendMessage($Handle, LVM_SETBKCOLOR, 0, $Color);
}

# Test 
#Call as LV_SetBkColor($Listview, $Color);
LV_SetBkColor($LV, 0x00ff00);
 
Just remember to use these 2 functions to set the foreground and background
of the listview text color when using the above function:
 
$LV-TextBkColor($BkColor);
$LV-TextColor($Color);
 
or when listview scrolls it will wipe out the background color you set
 

Ramy
 

RE: [perl-win32-gui-users] Status bar Parts method bug.

[Stephen Pick]

Hi Jez.
 
I found the problem (duh...) You should remember that Parts also returns the 
widths of all parts as a list. Since you have a part of width -1 on the last 
part, when you call Parts a list with -1 as the last element is being returned.
 
In the instances you showed where Parts does not work, $_ is being set to -1 by 
your code. For example,
$status-Parts(10,20,-1);
 
would set $_ to -1. Then when the function just runs off the end, the contents 
of $_ is returned, and if you return -1 from a function in win32::gui, the 
event loop ends.
 
So to solve your problem, get into the habit of explicitly returning from your 
functions. It's a very good habit to be in and can stop a lot of bugs 
appearing, especially in Win32::GUI. Also, I've committed an update for the 
statusbar Parts method that will check if it's in Scalar context and if so 
returns the number of parts instead of a list of parts. This will also fix your 
problem.
 
Steve

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 15 February 2004 10:08
To: Win32-GUI
Subject: [perl-win32-gui-users] Status bar Parts method bug.


Hi,
 
I've found a bug when using the parts method in the status bar control. All the 
following statements fail (no error, application just exits):
 
  $status-Parts($width-200,$width-100,-1);
  my $temp=$status-Parts($width-200,$width-100,-1);
  my @temp=$status-Parts($width-200,$width-100,-1);
 
While the following works:
 
 print $status-Parts($width-200,$width-100,-1);
 foreach ($status-Parts($width-200,$width-100,-1)) {print $_ \n;}

See example below. I've created a task in the tracker.
 
Cheers,
 
jez.
 
=
use Win32::GUI;
use strict;
 
 my $W = new GUI::Window(
-title= Win32::GUI::status test,
-left = 100,
-top  = 100,
-width= 300,
-height   = 200,
-name = main,
-onResize = \main_resize
);
 
my $status=$W-AddStatusBar(-name   = Status);
 
$status-Parts(50,100,-1);
$status-PartText(0,'Lots of text');
$status-PartText(1,'Part 1');
$status-PartText(2,'Part 2');
 
$W-Show;
 
Win32::GUI::Dialog;
 
sub main_resize {
 $status-Width($W-ScaleWidth);
 $status-Top($W-ScaleHeight - $status-Height);
 my $width=$status-Width;
 #The following work:
 print $status-Parts($width-200,$width-100,-1);
 #foreach ($status-Parts($width-200,$width-100,-1)) {print $_ \n;}
 #The following fail:
 #$status-Parts($width-200,$width-100,-1);
 #my $temp=$status-Parts($width-200,$width-100,-1);
 #my @temp=$status-Parts($width-200,$width-100,-1);
 
}
 
 
 
 

RE: [perl-win32-gui-users] Memory Usage

[Stephen Pick]

Yep, there's a PERLWIN32GUI_USERDATA structure for every control and window. 
This structure is chunky, and has references off to other structures in it, 
such as window names, cursors, accelerator tables, NEM events, etc. It could 
probably be optimized down.
 
The reason it uses more memory is that it supports and does more stuff. When 
you're writing an application to do, say, a calculator, you know exactly what 
buttons and windows you want, where you want them, and what you're doing, so 
you can build your C windowing code around your final goal. When you compile 
it, things get optimized even more by the compiler. With Win32::GUI there is no 
final goal and everything the Perl coder could conceivably want to do has to 
be supported, making it's footprint quite large.
 
Steve

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 29 January 2004 09:51
To: Win32-GUI
Subject: [perl-win32-gui-users] Memory Usage


Hi,
 
I've noticed that my app uses lots of memory on start up (35 M) compared to 
other similar applications (around 12 M) I'm on XP. I've got lots of windows 
and controls which are created at the start - is there Win32::GUI memory 
overhead for each control/window? Or should I start considering this as some 
sort of bug in my code?
 
Cheers,
 
jez.

RE: [perl-win32-gui-users] Memory Usage

[Stephen Pick]

To make things fair I compared a script that makes and shows 10 windows with a 
script that makes and shows 1000 windows and I'm happy to report that the 
memory usage per window is, on average, 1.612kb. The script that showed 1000 
windows used about 6mb of memory. The windows were created with only name, pos, 
size and text options. Don't forget that Perl with Win32::GUI loaded takes up 
about 4mb of RAM alone.
 
Steve
 
-Original Message-
From: Jez White [mailto:[EMAIL PROTECTED]
Sent: 03 February 2004 13:13
To: Stephen Pick; Win32-GUI
Subject: Re: [perl-win32-gui-users] Memory Usage



Thanks for the detailed reply.
 
I broke my app down and found it was taking about 2 meg for all the 
controls/windows - the rest was due to my code or other modules. I'm 
considering using a new design approach were I'll be using child windows as 
containers for groups of controls - potentially there could be lots of these 
windows - roughly how much memory does a window use?
 
Cheers,
 
jez.
 

- Original Message - 
From: Stephen  mailto:[EMAIL PROTECTED] Pick 
To: Jez White mailto:[EMAIL PROTECTED]  ; Win32-GUI 
mailto:perl-win32-gui-users@lists.sourceforge.net  
Sent: Tuesday, February 03, 2004 10:47 AM
Subject: RE: [perl-win32-gui-users] Memory Usage

Yep, there's a PERLWIN32GUI_USERDATA structure for every control and window. 
This structure is chunky, and has references off to other structures in it, 
such as window names, cursors, accelerator tables, NEM events, etc. It could 
probably be optimized down.
 
The reason it uses more memory is that it supports and does more stuff. When 
you're writing an application to do, say, a calculator, you know exactly what 
buttons and windows you want, where you want them, and what you're doing, so 
you can build your C windowing code around your final goal. When you compile 
it, things get optimized even more by the compiler. With Win32::GUI there is no 
final goal and everything the Perl coder could conceivably want to do has to 
be supported, making it's footprint quite large.
 
Steve

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 29 January 2004 09:51
To: Win32-GUI
Subject: [perl-win32-gui-users] Memory Usage


Hi,
 
I've noticed that my app uses lots of memory on start up (35 M) compared to 
other similar applications (around 12 M) I'm on XP. I've got lots of windows 
and controls which are created at the start - is there Win32::GUI memory 
overhead for each control/window? Or should I start considering this as some 
sort of bug in my code?
 
Cheers,
 
jez.

RE: [perl-win32-gui-users] How can I install Win32-GUI-DIBitmap without MSVC?

[Stephen Pick]

Yikes

Right, first off you need to get the Microsoft Platform SDK. This
contains all the windows header files and system header files that will
be required when compiling. It's free to download, get it here:

http://www.microsoft.com/msdownload/platformsdk/sdkupdate/

It's a massive download. You probably only want the core SDK and perhaps
the Internet SDK if you're that way inclined.

Then you want the Microsoft .NET Framework SDK. This contains the
compiler (cl.exe and linker (link.exe)). Don't worry - the stuff you
compile with it won't require the .NET framework to be installed on your
user's machines:

http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4
070-9F41-A333C6B9181Ddisplaylang=en

Then you need to set your environment variables so the compiler can find
the headers and other files it needs when compiling. Mine are set to:

INCLUDE=C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\include\.;C:\Program Files\Microsoft SDK\include\.
LIB=C:\Program Files\Microsoft SDK\Lib\.;C:\Program Files\Microsoft
Visual Studio .NET 2003\Vc7\lib\.

You should also add this to your PATH environment variable:
C:\Perl\bin\;C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\bin;C:\Program Files\Microsoft SDK\Bi
n\Win64;C:\Program Files\Microsoft SDK\Bin

Now nmake, cl, and link will all work, and you MIGHT even be able to
compile FreeImage. GOOD LUCK :)

Note that using the downloadable .NET SDK means that you cannot optimize
your binaries (so they will be big and slow). I recommend grabbing a
copy of VS .NET 2003 (what I have at home). If you're in education you
can get it extra-cheap (like I did...)

Steve


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 [EMAIL PROTECTED]
 Sent: 22 January 2004 09:13
 Cc: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] How can I install Win32-GUI-DIBitmap
 without MSVC?
 
 
 Hi All,
 
 I am trying to install Win32-GUI-DIBitmap. At first I install ppm, but
 when I tryed to run demo.pl sample script I got a error:
 
 Can't call method ConvertToBitmap on an undefined value at 
 D:\IPSwitch\test\de
 mo.pl line 14.
 
 then I tryed to install this module from scratch, how it wrotten in
 Readme.txt :
 
 SP INSTALLATION
 SP 
 SP Download FreeImage source code at 
 http://freeimage.sourceforge.net/
 SP Build the FreeImage static lib with MSVC project.
 SP Copy the FreeImage.lib and FreeImage.h in the extlib directory.
 
 Instead I am copied FreeImage\Dist\FreeImage.lib in extlib directory.
 Is it the same file???
 
 SP To install this module type the following:
 SP 
 SPperl Makefile.PL
 
 Writing Makefile for Win32::GUI::DIBitmap
 SPmake# nmake
 Searching EXE: E:/WINDOWS/EXE/NMAKE.EXE
   Inflating: NMAKE.ERR
   Inflating: NMAKE.EXE
 PKSFX: (W18) Warning! README.TXT already exists.  Overwrite (y/n)?y
   Inflating: README.TXT
 SPmake install# nmake install
 
 Der Befehl cl ist entweder falsch geschrieben oder   # from German:
 konnte nicht gefunden werden.  # cl not found
 
 NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : 
 return code '0x1'
 Stop.
 
 Have I to have a linker programm too?
 
 Thanks in advance.
 
 --
 Pavel
 
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] Label with transparent background

[Stephen Pick]

Hi,

this has already been in the list before. I've no idea if it really
works but try adding this option to your label:

-pushexstyle = 0x0020

That sets the WS_EX_TRANSPARENT style. Apparently it makes windows
transparent but still allows them to respond to input events. Please let
me know if it works.

Steve


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 carollyne courtney
 Sent: 22 January 2004 10:31
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] Label with transparent background
 
 
 Is there anyway to create a label with a transparent background?
 Thanks..
 
 _
 Get accurate, multi-day weather forecasts for your area at 
 MSN Weather! 
 http://www.msn.co.za/weather/
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] Accelerator bug?

[Stephen Pick]

Hooks were always after the regular handling code, except now they're
after WM_PAINT and a few other events too.

While it is not possible to retrieve the coderefs for specific NEM
events, the only time I can imagine you wanting to do this would be to
find out a handler that a particular gui object is using and call it
with your own arguments. I can't see that that would be a good plan or
any particular practical use for it. An example would be nice.

The other points, I'm looking into.

Steve

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Glenn Linderman
 Sent: 21 January 2004 01:39
 To: Steve Pick
 Cc: Jez White; perl-win32-gui-users@lists.sourceforge.net
 Subject: Re: [perl-win32-gui-users] Accelerator bug?
 
 
 Back when I tried to convert one of my applications from OEM 
 to NEM, I 
 discovered the following problems.  Perhaps some of them have 
 been fixed 
 by now.  Perhaps some of them were user error.
 
 1) The subroutines defined for pop-up menu click events never 
 got called.
 
 2) Accelerators didn't work.
 
 3) It wasn't possible to obtain the old event reference, so 
 that event 
 references could be stacked or nested.
 
 The latter item blew away NEM for me, as I wasn't able to port Harold 
 Piske's WinSize module in a reasonable fashion.  I didn't really need 
 accelerator keys on that project, but they are handy on all projects, 
 and I prefer to have them available, so that was a negative.  
 And that 
 project used lots of pop-up menus, and when the Click event 
 subroutine 
 doesn't get called, that is a problem.
 
 So those are the reasons I gave up on NEM for now.  1) May have been 
 user error... anyone have a code sample in that area?  2) is still a 
 problem, and 3) might be solvable via hooks... but I think hooks 
 executed before the event is seen by the regular handling 
 code would be 
 more effective, and they just got switched to after the 
 regular handling 
 code.  Being able to obtain the old code reference would be a handy 
 feature, though, even though hooks do exist.
 
 
 On approximately 1/20/2004 11:01 AM, came the following 
 characters from
 the keyboard of Steve Pick:
  Aldo's been silent for a while.
  
  Exactly what events are missing? We're running out of space 
 in the NEM to
  add new events (checking if events are set is based on a 
 32-bit mask, and
  most of the bits are used), but I'm sure that's easy to get round.
  
  The NEM is probably faster than the OEM, though I've not 
 run any benchmarks.
  
  I would no longer even consider using the OEM, having 
 looked at the code for
  it (mind you I'm hardly in a position to comment on code 
 clarity :) ).
  
  Steve
  
  - Original Message - 
  From: Jez White [EMAIL PROTECTED]
  To: Stephen Pick [EMAIL PROTECTED]; [EMAIL PROTECTED];
  perl-win32-gui-users@lists.sourceforge.net
  Sent: Tuesday, January 20, 2004 11:20 AM
  Subject: Re: [perl-win32-gui-users] Accelerator bug?
  
  
  
 I'de like to use NEM more - but I am finding some events 
 missing. So it
  
  the
  
 NEM slightly faster as well?
 
 Aldo was talking about another model - is this just an 
 enhancement of NEM?
 
 jez.
 
 - Original Message - 
 From: Stephen Pick [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]; 
 perl-win32-gui-users@lists.sourceforge.net
 Sent: Tuesday, January 20, 2004 10:58 AM
 Subject: RE: [perl-win32-gui-users] Accelerator bug?
 
 
 Yes, I use the NEM heavilly. The OEM is a really ugly way of doing
 things and basing things on references is much safer and much more
 elegant. Every other perl module that needs to do callbacks uses
 references (see.. well.. anything, err, LWP for example). This is
 because you can check that references are safe to call, whereas with
 non-references you have to eval() and then you open up 
 security holes.
 
 Steve
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]
  Behalf Of
 Glenn W Munroe
 Sent: 20 January 2004 10:52
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: RE: [perl-win32-gui-users] Accelerator bug?
 
 
 
 Just out of interest, is anybody really using the NEM? Are 
 there any
 major advantages to it? I admit it is quite elegant to 
 have a one-line
 subroutine defined as an -event option, but in practice, most event
 handlers will consist of more code than I would like to
 define that way
 and the handler would just end up being another subroutine call.
 
 IMHO, the two major advances in this module recently have been
 accelerators and hooks (I'd say we're approaching GUI
 nirvana), so if at
 least one of them doesn't work in NEM, that knocks it on 
 the head for
 me.
 
 Glenn
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] 
 On Behalf Of
 Glenn Linderman
 Sent: Monday, 19 January, 2004 21:52
 To: [EMAIL PROTECTED]
 Cc: perl-win32-gui-users@lists.sourceforge.net
 Subject: Re: [perl-win32-gui-users] Accelerator bug?
 
 Glenn,
 
 Sorry for the delay

RE: [perl-win32-gui-users] Accelerator bug?

[Stephen Pick]

GUI_MessageLoops.cpp, there are events for graphics in the OEM but i don't see 
any NEM functionality for Paint(). the onMouseDown etc. events will probably 
work if the graphic is set to be interactive.

Steve

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Jez White
 Sent: 21 January 2004 10:27
 To: Steve Pick; perl-win32-gui-users@lists.sourceforge.net
 Subject: Re: [perl-win32-gui-users] Accelerator bug?
 
 
 Steve,
 
 I think I have found some missing events (for graphics) but 
 before I create
 any bug reports I'd like to check the XS code - but were 
 should I look?
 
 Cheers,
 
 jez.
 - Original Message - 
 From: Steve Pick [EMAIL PROTECTED]
 To: Jez White [EMAIL PROTECTED];
 perl-win32-gui-users@lists.sourceforge.net
 Sent: Tuesday, January 20, 2004 7:01 PM
 Subject: Re: [perl-win32-gui-users] Accelerator bug?
 
 
  Aldo's been silent for a while.
 
  Exactly what events are missing? We're running out of space 
 in the NEM to
  add new events (checking if events are set is based on a 
 32-bit mask, and
  most of the bits are used), but I'm sure that's easy to get round.
 
  The NEM is probably faster than the OEM, though I've not run any
 benchmarks.
 
  I would no longer even consider using the OEM, having 
 looked at the code
 for
  it (mind you I'm hardly in a position to comment on code 
 clarity :) ).
 
  Steve
 
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] Accelerator bug?

[Stephen Pick]

Yes, I use the NEM heavilly. The OEM is a really ugly way of doing
things and basing things on references is much safer and much more
elegant. Every other perl module that needs to do callbacks uses
references (see.. well.. anything, err, LWP for example). This is
because you can check that references are safe to call, whereas with
non-references you have to eval() and then you open up security holes.

Steve

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Glenn W Munroe
 Sent: 20 January 2004 10:52
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: RE: [perl-win32-gui-users] Accelerator bug?
 
 
 
 Just out of interest, is anybody really using the NEM? Are there any
 major advantages to it? I admit it is quite elegant to have a one-line
 subroutine defined as an -event option, but in practice, most event
 handlers will consist of more code than I would like to 
 define that way
 and the handler would just end up being another subroutine call.
 
 IMHO, the two major advances in this module recently have been
 accelerators and hooks (I'd say we're approaching GUI 
 nirvana), so if at
 least one of them doesn't work in NEM, that knocks it on the head for
 me.
 
 Glenn
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of
 Glenn Linderman
 Sent: Monday, 19 January, 2004 21:52
 To: [EMAIL PROTECTED]
 Cc: perl-win32-gui-users@lists.sourceforge.net
 Subject: Re: [perl-win32-gui-users] Accelerator bug?
 
 Glenn,
 
 Sorry for the delay, I was not monitoring this email address 
 from 1/15 
 until now.
 
 
 On approximately 1/16/2004 8:28 AM, came the following characters from
 the keyboard of Glenn W Munroe:
  Glenn,
  
  I haven't really used the NEM much yet, but when I knocked 
 up a small
  test script this morning with the new model I found that 
 accelerators
  didn't work. Had you noticed this or can you confirm it? If 
 so, is it
 a
  bug with accelerators themselves or some underlying feature of the
  system?
 
 Indeed, I think it is just a missing feature in NEM.  When I 
 looked at 
 the code inside Win32::GUI for accelerators, I was able to figure out 
 and fix accelerators for OEM, but I think NEM has much more code that 
 simply isn't there for accelerators.  This is one reason I am still 
 using OEM.  (OEM = Old Event Model, when it takes a break 
 from meaning 
 Original Equipment Manufacturer :) )
 
  Regards,
  Glenn Munroe
 
 -- 
 Glenn -- http://nevcal.com/
 ===
 The best part about procrastination is that you are never bored,
 because you have all kinds of things that you should be doing.
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 
 
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] Statusbar example

[Stephen Pick]

Hi,

The correct usage is:

$status-Parts(x1,x2,x3,x4,x5...);

I'm sorry if the docs were confusing. This takes a list, not a list reference. 
Also it does not take widths, it takes the X co-ordinate of the right-hand 
edge of each part. This is true to the actual API functionality, which is kind 
of weird but is actually quite handy. So, to create 3 parts each of width 100 
pixels, you would use:

$status-Parts(100,200,300);

Hope that helps out,

Steve


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Chris Wearn
 Sent: 19 January 2004 06:30
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] Statusbar example
 
 
 Hi All
 
 Having trouble with the new Statusbar additions:
 
 tried different combinations of PARTS to start dividing, but 
 no matter what
 I've tried nothing seems to work. What order do the methods need to be
 called?
 
 I've had a look at MSDN Status Bars and read the notes that 
 Steve posted on
 announcing the enhancements. Confused in that MSDN says that Parts is
 (nParts[array of widths])
 
 I've tried $Window_Status-Parts([200,100,-1]); and
 Parts(3,[200,100,-1])
 
 Can someone add a few of the methods to the example below.
 
 Chris
 
 
 # 
 
 use Win32::GUI;
 
 my $Window = new GUI::Window(
   -title  = Statusbar example,
   -left   = 100,
   -top= 100,
   -width  = 400,
   -height = 200,
   -name   = Window,
   -events ={
   Terminate = sub { return -1 },
}
 );
 
 # Add a Status Bar
 my $Window_Status = $Window-AddStatusBar(
   -name = Window_Status,
   -text = Panel 1
 );
 
 $Window-Show;
 Win32::GUI::Dialog;
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] Image change

[Stephen Pick]

Have you tried $label-SetImage($win32_gui_bitmap_object)? I find that
this doesnt do anything unless you force the image to update. You can do
this with:

$label-Redraw(0x0001 | 0x0100);

Which invalidates the label rect (0x0001 = RDW_INVALIDATE) - you could
also use InvalidateRect to do this - and redraws the label *immediately*
(0x0100 = RDW_UPDATENOW).

Steve


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Chris
 Sent: 19 January 2004 04:12
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] Image change
 
 
 Okay, I've created a label. Now when I first make it, I have 
 a image set to
 it and make it so it can be clicked on. Now, my problem is 
 when I click on
 the image, I actually want to change it to a different image. 
 If someone
 could help me with this, it would be very useful. 
 
 Thanks Chris
 
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

Re: [perl-win32-gui-users] Recursive Grep

[Stephen Pick]

Hey here's an idea!

man grep

Wow! 
  -r, --recursive
 Read all files under each  directory,  recursively;
 this is equivalent to the -d recurse option.

Also manifests itself as the rgrep command. RTFM next time. Don't post
dumb questions to this list. Post them to perlmonks. Is this a GUI
question? No. We've told you before about this sort of thing.

Steve

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 mayank prakash
 Sent: 19 January 2004 11:23
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] Recursive Grep
 
 
 
 I have to write a unix shell script which does recursive 
 grep...It 
 should be an enhancement over Grep. i.e. It should support all the 
 functionalities of Grep.
 
 
 Please tell me  how to do that
 I am trying.using 'find'..'grep''$@' etcPlease Help
 
 Mayank
 
 _
 Meet a mate. Find a soulmate. http://www.msn.co.in/Romance/ 
 Or just chat a 
 while.
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] moving windows

[Stephen Pick]

Not a problem!

Give your label the -notify = 1 option. Now when you click it, it'll
generate a WM_LBUTTONDOWN message.

Make a new global variable called $MBUTTON:
our $MBUTTON = 0;

Give your label an -onMouseDown event, and in the event handler, you
want to:

sub mousedown {
$label-SetCapture(); # capture all the mouse events
# get the mouse cursor pos in our window:
my($ox, $oy) =
$Wmain-ScreenToClient(Win32::GUI::GetCursorPos());
$MBUTTON = 1;
while($MBUTTON) {
# get the screen cursor pos
my($mx,$my) = Win32::GUI::GetCursorPos();
# position the window under the mouse at the correct
place:
$Wmain-Move($mx - $ox, $my - $oy);
# check for mouseup.
Win32::GUI::DoEvents;
}
$label-ReleaseCapture;
}

sub mousemove {
}

give your label an onMouseUp event, handler:

sub mouseup {
$MBUTTON = 0;
}

now, when the mouse goes down on the label, $MBUTTON is set to 1, the
label is set to capture all mouse events, and a while loop starts that
allows the window to be dragged around. When the mouse is released,
$MBUTTON is set to 0, and the while loop ends. Mouse is released, and
you have a coffee.

Steve


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Chris
 Sent: 19 January 2004 10:57
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] moving windows
 
 
 Okay, I have a window, but I'm not sure how to make it so I 
 can move it.
 
   $Wmain = Win32::GUI::Window-new(
   -name   = 'winamp',
   -top = ($screen_heigth - 116)/2,
   -left = ($screen_width - 275)/2,
   -maxsize = [275,116],
   -minsize = [275,116],
   -width  = 275,
   -height = 116,
   -style = WS_POPUP,
   -text   = Winamp Remote,
   );
 
 With that style, I no longer have the ugly windows title bar. 
 However the
 entire window is created out of labels, and I'm not sure how 
 to make it so I
 can click and drag a label to move the window around, cause 
 that would allow
 me to handle movements. I already inserted my own custom 
 menubar buttons, so
 if someone could help me, please do
 
 Thanks Chris
 
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] Statusbar example

[Stephen Pick]

I just know you're going to start asking how to put progress bars in there. 
Basically, there's a way of obtaining the rectangle of a specific part 
($statusbar-GetRect($part)). I'm pretty sure that to insert a progress bar 
into the status bar you simply make a new progress bar with the status bar as 
it's parent window, and position and size it using the values returned by 
GetRect.

Here's an example that shows a progress bar filling and unfilling in the status 
bar.

use Win32::GUI;
use Time::HiRes qw( time );

my $window = new Win32::GUI::Window(
-name = main,
-text = Status Progress,
-size = [300,300],
-pos = [100,100],
-onResize = \main_resize
);

my $status = new Win32::GUI::StatusBar($window);

$status-Parts(200,-1);

my $progress = new Win32::GUI::ProgressBar($status, -smooth = 1);

$progress-SetRange(0,1000);

$window-Show;

while(1) {
Win32::GUI::DoEvents;
$progress-SetPos( int((1 + sin(time)) * 500) );
}

sub main_resize {
$status-Width($window-ScaleWidth);
$status-Top($window-ScaleHeight - $status-Height);
my($left,$top,$right,$bottom) = $status-GetRect(1);
$progress-Left($left);
$progress-Top($top);
$progress-Width($right - $left);
$progress-Height($bottom - $top);
}

__END__

Steve

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Chris Wearn
 Sent: 19 January 2004 10:15
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: RE: [perl-win32-gui-users] Statusbar example
 
 
 Hi Steve, Jez,
 
 Thanks Steve. Now its all clear ;-) Got confused with the 
 MSDN which had
 Parts(nParts[array of widths]). Should have spotted the X 
 co-ordinate in
 'x1' Doh!
 
 And now Jez has answered my next question with his post, 
 which was how are
 the parts referenced... hours of fun coming up, another late 
 night I feel
 ;-)
 
 Cheers
 
 Chris
 
 -Original Message-
 From: Stephen Pick [mailto:[EMAIL PROTECTED]
 Sent: Monday, 19 January 2004 5:49 PM
 To: Chris Wearn; perl-win32-gui-users@lists.sourceforge.net
 Subject: RE: [perl-win32-gui-users] Statusbar example
 
 
 Hi,
 
 The correct usage is:
 
 $status-Parts(x1,x2,x3,x4,x5...);
 
 I'm sorry if the docs were confusing. This takes a list, not a list
 reference. Also it does not take widths, it takes the X 
 co-ordinate of the
 right-hand edge of each part. This is true to the actual API 
 functionality,
 which is kind of weird but is actually quite handy. So, to 
 create 3 parts
 each of width 100 pixels, you would use:
 
 $status-Parts(100,200,300);
 
 Hope that helps out,
 
 Steve
 
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] 
 Behalf Of
  Chris Wearn
  Sent: 19 January 2004 06:30
  To: perl-win32-gui-users@lists.sourceforge.net
  Subject: [perl-win32-gui-users] Statusbar example
 
 
  Hi All
 
  Having trouble with the new Statusbar additions:
 
  tried different combinations of PARTS to start dividing, but
  no matter what
  I've tried nothing seems to work. What order do the methods 
 need to be
  called?
 
  I've had a look at MSDN Status Bars and read the notes that
  Steve posted on
  announcing the enhancements. Confused in that MSDN says 
 that Parts is
  (nParts[array of widths])
 
  I've tried $Window_Status-Parts([200,100,-1]); and
  Parts(3,[200,100,-1])
 
  Can someone add a few of the methods to the example below.
 
  Chris
 
 
  # 
 
  use Win32::GUI;
 
  my $Window = new GUI::Window(
  -title  = Statusbar example,
  -left   = 100,
  -top= 100,
  -width  = 400,
  -height = 200,
  -name   = Window,
  -events ={
  Terminate = sub { return -1 },
   }
  );
 
  # Add a Status Bar
  my $Window_Status = $Window-AddStatusBar(
  -name = Window_Status,
  -text = Panel 1
  );
 
  $Window-Show;
  Win32::GUI::Dialog;
 
 
 
  ---
  The SF.Net email is sponsored by EclipseCon 2004
  Premiere Conference on Open Tools Development and Integration
  See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
  http://www.eclipsecon.org/osdn
  ___
  Perl-Win32-GUI-Users mailing list
  Perl-Win32-GUI-Users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 
 
 
 
 ---
 The SF.Net email is sponsored by EclipseCon 2004
 Premiere Conference on Open Tools Development and Integration
 See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
 http://www.eclipsecon.org/osdn
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

Re: [perl-win32-gui-users] Yet Another CVS Commit...

[Stephen Pick]

Hi Jez,

 If I wanted to use a scroll bar for part of the window - say, within a
 tabstrip, would the approach be to create another window and apply the
 scroll bar to that?

Yes. Bear in mind that the scrollbars are ONLY scrollbars, they do not have any 
effect on the window contents unless you implement the effect they're supposed 
to have yourself. Therefore, you should move all your widgets yourself, or 
place them in a child window and simply move the child window.

Steve

RE: [perl-win32-gui-users] Scroll bar example

[Stephen Pick]

Your code is bad. What you're doing is creating a floating BorderlessWindow 
positioned over the top of the main window. If you want to put your window 
*INSIDE* the client area I suggest you do this:
 
use Win32::API;
our $SETPARENT = new Win32::API(user32,SetParent,NN,N) or croak Failed 
to load SetParent from user32.dll;
 
my $child = new Win32::GUI::DialogBox(
-parent = $win,
-name = Child,
-left = 0,
-top = 0,
-text = Child,
-width = 100,
-height = 100,
-style = WS_CHILD,
   );
 
$SETPARENT-Call($child-{-handle}, $win-{-handle});
$child-Width($child-Width); # force update.
 
After doing this stuff, you'll find you have a dialogbox inside the main 
window. It also clips if you drag it out of the main window, so it truely is 
inside. You can even give it a WS_CAPTION and drag it around in the client area.
 
Giving things a -parent argument does NOT mean SetParent is called on them in 
Win32::GUI.
 
Steve
 
 
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 16 January 2004 12:37
To: Win32-GUI
Subject: [perl-win32-gui-users] Scroll bar example



Hi,
 
The example below will only work on the latest code line from CVS. 
 
I'm trying to get my head round using scroll bars. In my test example I want to 
create a window containing one tab strip. In the tab strip there will be a 
child window containing a scroll bar and 10 buttons. Scrolling the scroll bar 
will move the buttons into and out view.
 
Now, the scrolling part works fine - but is using a child window in this way 
the correct approach? For example, interacting with the child window (clicking 
on a button, or scrolling) loses focus (which you would expect for a normal 
window) but is not the correct behaviour in this case. Am I missing something 
fundamental?
 
Apologies for the dodgy code - is a hack job:)
 
cheers,
 
jez.
 
===
use Win32::GUI;
use Win32::GUI::BorderlessWindow;
 
#create the main window
my $win = new Win32::GUI::Window (
 -name = MainWin,
 -left = 0,
 -top = 100,
 -width = 500,
 -height = 300,
 -sizable = 1,
 -text = Scrollbar Test 2,
 -noflicker = 1,
);
 
#create a tab strip
$win-AddTabStrip (
 -name = Tab,
 -left = 0,
 -top = 100,
 -width = 250,
 -height = 150,  
);
$win-Tab-InsertItem(-text = 'Some Tab');
 
#create a child window with a scroll bar
my $childwin = new Win32::GUI::BorderlessWindow (
 -name = Child,
 -parent =$win,
 -left = 10,
 -top = 250,
 -width = 200,
 -height = 120,
 -hscroll = 1,
 -noflicker = 1,
 -onScroll = \scrolled
);
 
#create content for our child window, 10 buttons.
foreach (0..9) {
  $childwin-AddButton (
   -name = Button.$_,
   -pos  = [$_*50, 30],
   -size = [50, 20],
   -text = 'Button'.$_,);
}
 
#set the scrollbar range and starting pos
$childwin-ScrollRange(0,0,450);
$childwin-ScrollPos(0,0);
 
$win-Show;
$childwin-Show;
Win32::GUI::Dialog;
 
sub scrolled {
 my($object,$bar,$operation,$pos) = @_;
 my $string;
 $object-Scroll($bar,$operation,$pos);
 #Scroll the buttons...
 if($operation == SB_THUMBTRACK) {
foreach (0..9) {
  $string='Button'.$_;
  $childwin-$string-Move(($_*50)-$pos,30);
}
  }
}

 

RE: [perl-win32-gui-users] Scroll bar example

[Stephen Pick]

Whoa there, slow down...
 
This is NOT an MDI thing. This is a cheap hack to get Jez's problem solved. 
Don't use it unless you have to.
 
if the title bars do not become active, remove the WS_CHILD style.
 
if things are clipping what they shouldnt, add the WS_CLIPSIBLINGS style.
 
I added new methods that have API equivalents (SetScrollRange, 
SetScrollPos...), and I am not the sort of XS programmer who leaves the user to 
extract a massive struct which I could have done in XS, which is why I did not 
offer SetScrollInfo(), but instead implemented the older functions that let you 
do everything SetScrollInfo() does.
 
You must handle all scrolling yourself, as i've said a million times. I will 
look into MDIs when I have the time; win32::gui already seems to have an MDI 
object but I'm unsure of what it does.
 
I strongly disagree that adding new functionality is bad. The functions I have 
added are all documented and most have API equivalents.
 
 I don't want to have someone how is used to windows programming in VB or
 C++ to wonder what something is
 
I do not program XS functions for VB/VC++ programmers. I write them for Perl 
programmers. I respect the fact that originally Win32::API was supposed to be 
very similar to the VB way of doing things. That has changed now. Every new 
method I add to Win32::GUI attempts to be in-keeping with the general 
Win32::GUI way of doing things, and is well documented. Win32::GUI is still 
very similar to the underlying C API, which is a good thing. If they dont know 
what something is then they can read the docs, which will be regenerated from 
the new code and distributed with the PPM.
 
Steve
 
 
 -Original Message-
From: Frazier, Joe Jr [mailto:[EMAIL PROTECTED]
Sent: 16 January 2004 14:15
To: Stephen Pick; Win32-GUI
Subject: RE: [perl-win32-gui-users] Scroll bar example



Stephen, that's real nice with the MDI thing.  However, there are a few 
questions:
 
Do you(the developer) have to control all the window positions and stuff 
manually  For example, when I set up a second window, and maximize one using 
the buttons ( I added the -controlbox property), the other windows floats on 
top but cannot be interacted with. Neither child window's title bar would 
become active.  If one window was clipping the other, the lower window would 
not come to the foreground when selected.   I think we are really close here to 
getting some very awesome new functionality via MDI windows and would perhaps 
like someone to look into whatever else is needed to make that happen (although 
I would rather have the scroll bar's first in PPM and documented since that is 
something I need fairly soon).
 
Now, going back to the subject of new methods, I personally would prefer 
against that unless they are aliases for the right way to do things.  Just as 
XML parsing has problems with proprietary methods, I don't want to have 
someone how is used to windows programming in VB or C++ to wonder what 
something is.  If there is something we will do with a new method that is not 
in the core API, we need to make sure that it is fully documented as such.  
Things that are in the core API should work the same as they do in other 
languages, with specific new methods to change the functionality if we deem 
that we can get it to work better doing other things under the hood so to 
speak.   Does anyone else agree with that?
 

Joe Frazier, Jr.
Technical Support Engineer
Peopleclick Service Support

Tel:  +1-800-841-2365
E-Mail: mailto:[EMAIL PROTECTED]


-Original Message-
From: Jez White [mailto:[EMAIL PROTECTED]
Sent: Friday, January 16, 2004 8:35 AM
To: Stephen Pick; Win32-GUI
Subject: Re: [perl-win32-gui-users] Scroll bar example


Thanks for all the replies/suggestions.
 
I have to admit I'm more confused now than I was when I started:)
 
I tried your suggestions Steve, I end up with something that works like an MDI 
application - which is nice in itself, but not what I was after:) 
 
Basically is it possible to use a scroll bar within a window, and not on one of 
it's edges? I'm trying to think of a clearer example than my tab strip one. 
Imagine a image viewing program with the main window filled with controls, the 
image could be larger than the screen so you want to place scroll bars on the 
image and not on the window (almost like putting a scroll bar on a control). I 
had assumed you could use somesort of child window to achieve this kind of 
effect?
 
My thought process was basically inline with what Johan was suggesting - if a 
child window could be just another control, then the parent window would not 
lose focus and everything would be hunky dory. Using a child window in this 
manor would also make sense when attaching a child window to a band in the 
rebar control.
 
Or am I just way off the mark here?:)
 
Cheers,
 
jez.
 

- Original Message - 
From: Stephen Pick mailto:[EMAIL PROTECTED]  
To: Jez White mailto:[EMAIL PROTECTED]  ; Win32-GUI 
mailto:perl

RE: [perl-win32-gui-users] another newbie question...

[Stephen Pick]

I would recommend looking into The GUI Loft - It's a WYSIWYG gui creator
for use with the Win32::GUI perl module.

Johan seems to have been busy updating it too :)

Link: http://www.bahnhof.se/~johanl/perl/Loft/

Steve

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Sirisha Gollapudi
 Sent: 15 January 2004 12:33
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] another newbie question...
 
 
 Hi all,
 
 after some difficulty I managed to get Win32::GUI up and 
 running - being 
 pretty new to this I was wondering if anyone could help with 
 another query. 
 I have a fully functional perl program that at the moment is 
 just a simple 
 command line interface. what's the process for turning this 
 into a GUI 
 application? I realise this might be an odd question and the 
 answer is 
 probably just going to be learn Win32::GUI!! but i'm on a tight 
 schedule... it's for a project which will gain me better 
 marks if i have a 
 pretty interface.
 
 thanks for any advice,
 
 Sirisha
 
 _
 Express yourself with cool new emoticons 
 http://www.msn.co.uk/specials/myemo
 
 
 
 ---
 This SF.net email is sponsored by: Perforce Software.
 Perforce is the Fast Software Configuration Management System offering
 advanced branching capabilities and atomic changes on 50+ platforms.
 Free Eval! http://www.perforce.com/perforce/loadprog.html
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] Win32::GUI

[Stephen Pick]

Use ppm (programmers package manager) with activeperl. Type ppm at a
command prompt, then type help for instructions.

If you prefer to use CPAN (comprehensive perl archive network) to
install modules/packages (often more are available here) you can use:

perl -MCPAN -e shell

then at the cpan  prompt type: install Module::Name.

If you don't have a compiler and header files then CPAN will often fail
to work as a lot of modules have to be compiled before they can be used.
With ActivePerl, PPM makes many precompiled modules available to you,
one of which is Win32::GUI, but others are available. You can use the
PPM shell to query certain large module repositories, or you can install
a downloaded module from a .ppd file.

To install a perl module from a .ppd file, use:
ppm install The-Module.ppd
at a command prompt.

To get a PPM shell, use:
ppm

You can now enter PPM commands. The only PPM commands I ever really use
are:
install module
search string

the help command may be useful for new users.

Steve




 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 mayank prakash
 Sent: 15 January 2004 12:39
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] Win32::GUI
 
 
 Hi all,
 
 Can anyone tell me how to install perl modules; the complete 
 process?
 
 I have installed ActiveState ActivePerl 5.8 in my Windows 
 2000 machine.
 
 Mayank.
 
 _
 Marriage? 
 http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Join 
 BharatMatrimony.com and get married.
 
 
 
 ---
 This SF.net email is sponsored by: Perforce Software.
 Perforce is the Fast Software Configuration Management System offering
 advanced branching capabilities and atomic changes on 50+ platforms.
 Free Eval! http://www.perforce.com/perforce/loadprog.html
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

[perl-win32-gui-users] GUI loft crashes

[Stephen Pick]

I just got the latest version of TGL, and it won't start. Tries to read
memory at 0x000. This problem is something I commonly associate with
missing files given to imagelists, bitmaps, etc. Or maybe PAR is to
blame.

Steve.

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Stephen Pick
 Sent: 15 January 2004 12:42
 To: Sirisha Gollapudi; perl-win32-gui-users@lists.sourceforge.net
 Subject: RE: [perl-win32-gui-users] another newbie question...
 
 
 I would recommend looking into The GUI Loft - It's a WYSIWYG 
 gui creator
 for use with the Win32::GUI perl module.
 
 Johan seems to have been busy updating it too :)
 
 Link: http://www.bahnhof.se/~johanl/perl/Loft/
 
 Steve
 
  -Original Message-
  From: [EMAIL PROTECTED]
  [mailto:[EMAIL PROTECTED] 
 Behalf Of
  Sirisha Gollapudi
  Sent: 15 January 2004 12:33
  To: perl-win32-gui-users@lists.sourceforge.net
  Subject: [perl-win32-gui-users] another newbie question...
  
  
  Hi all,
  
  after some difficulty I managed to get Win32::GUI up and 
  running - being 
  pretty new to this I was wondering if anyone could help with 
  another query. 
  I have a fully functional perl program that at the moment is 
  just a simple 
  command line interface. what's the process for turning this 
  into a GUI 
  application? I realise this might be an odd question and the 
  answer is 
  probably just going to be learn Win32::GUI!! but i'm on a tight 
  schedule... it's for a project which will gain me better 
  marks if i have a 
  pretty interface.
  
  thanks for any advice,
  
  Sirisha
  
  _
  Express yourself with cool new emoticons 
  http://www.msn.co.uk/specials/myemo
  
  
  
  ---
  This SF.net email is sponsored by: Perforce Software.
  Perforce is the Fast Software Configuration Management 
 System offering
  advanced branching capabilities and atomic changes on 50+ platforms.
  Free Eval! http://www.perforce.com/perforce/loadprog.html
  ___
  Perl-Win32-GUI-Users mailing list
  Perl-Win32-GUI-Users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
  
 
 
 ---
 This SF.net email is sponsored by: Perforce Software.
 Perforce is the Fast Software Configuration Management System offering
 advanced branching capabilities and atomic changes on 50+ platforms.
 Free Eval! http://www.perforce.com/perforce/loadprog.html
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] GUI loft crashes

[Stephen Pick]

Windows 2000, SP 4.


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Johan Lindstrom
 Sent: 15 January 2004 14:29
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: Re: [perl-win32-gui-users] GUI loft crashes
 
 
 At 13:59 2004-01-15, Stephen Pick wrote:
 I just got the latest version of TGL, and it won't start. 
 Tries to read
 memory at 0x000. This problem is something I commonly 
 associate with
 missing files given to imagelists, bitmaps, etc. Or maybe PAR is to
 blame.
 
 Which OS?
 
 I've had one report (which I unfortunately haven't answered 
 yet, sorry 
 about that) that TGL doesn't work under Windows XP, but it 
 sounded similar 
 to other reports on this list that Win32::GUI doesn't work 
 under XP either, 
 so I'm not entirely sure it's a TGL thing or a 
 certain-flavour-of-Windows-XP thing.
 
 I switched to PAR because PerlApp (a very old version) 
 couldn't create an 
 .exe last time I tried and it seemed the simplest solution at 
 the time.
 
 
 /J
 
  --  --- -- --  --  -- -  - -
 Johan Lindström   Sourcerer @ Boss Casinos   [EMAIL PROTECTED]
 
 Latest bookmark: Enabling WebDAV on Apache
 http://www.serverwatch.com/tutorials/article.php/2176771
 dmoz (1 of 30): /Computers/Software/Internet/Servers/ 52
 
 
 
 ---
 This SF.net email is sponsored by: Perforce Software.
 Perforce is the Fast Software Configuration Management System offering
 advanced branching capabilities and atomic changes on 50+ platforms.
 Free Eval! http://www.perforce.com/perforce/loadprog.html
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] Re: Intermediate release of Win32::GUI

[Stephen Pick]

You should already be able to add the WS_EX_STATICEDGE style to buttons.
 
use the
-pushexstyle = 0x0002
option for your button and the style will be applied. WS_EX_STATICEDGE is not 
exported by Win32::GUI (most Win32 constants arent), so you have to use the 
numeric instead.
 
Steve

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Levin
Sent: 14 January 2004 14:19
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] Re: Intermediate release of Win32::GUI


I AM VERY GLAD because now can there will be rebirth PERL for Windows, thanks!
If will allow me I want to offer some themes for creativity;) I do not know as 
it to carry out: (
It will be very good to use:
Styles for buttons (and for others), for example WS_EX_STATICEDGE,
Hints for controls, 
For Dialogbox it's necessary to make alive the button ?.
---

I believe that the 670 version has some old hooks code in it, this version is 
available as a ppm on 
sourceforge. The latest CVS from the 665 branch is the one you want for best 
functionality. What 
errors do you get on compile, and what compiler are you using?
 Thanks, Steve.
I have taken from Activestate distribution kit ActivePerl-5.8.2.808-MSWin32-x86 
(earlier I used ActivePerl-5.6.1), and taken not compiled package 
Win32-GUI-0.0.665. Now has taken all new files from CVS repository and has 
replaced old on new. Used NMAKE15 for compilation and has received blib 
directory. Compilation has passed without mistakes.

But I have not found GUI.DLL here, and perl have told to me Can't locate 
loadable object for module Win32::GUI in @INC ... end :(

First I think that this package ActivePerl-5.8.2.808 is not multi-thread, and 
so I have a mistake.Then I have put PPM Win32-GUI-0.0.670, and it work! I have 
made something not correctly. I do not understand :(

Any ideas?

Thanks. 

 
 

RE: [perl-win32-gui-users] Re: Intermediate release of Win32::GUI

[Stephen Pick]

Oh and you need to do
 
nmake install
 
after compiling to install the module. Sorry, forgot to add that.
 
Steve
 

-Original Message-  
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Levin
Sent: 14 January 2004 14:19
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] Re: Intermediate release of Win32::GUI


I AM VERY GLAD because now can there will be rebirth PERL for Windows, thanks!
If will allow me I want to offer some themes for creativity;) I do not know as 
it to carry out: (
It will be very good to use:
Styles for buttons (and for others), for example WS_EX_STATICEDGE,
Hints for controls, 
For Dialogbox it's necessary to make alive the button ?.
---

I believe that the 670 version has some old hooks code in it, this version is 
available as a ppm on 
sourceforge. The latest CVS from the 665 branch is the one you want for best 
functionality. What 
errors do you get on compile, and what compiler are you using?
 Thanks, Steve.
I have taken from Activestate distribution kit ActivePerl-5.8.2.808-MSWin32-x86 
(earlier I used ActivePerl-5.6.1), and taken not compiled package 
Win32-GUI-0.0.665. Now has taken all new files from CVS repository and has 
replaced old on new. Used NMAKE15 for compilation and has received blib 
directory. Compilation has passed without mistakes.

But I have not found GUI.DLL here, and perl have told to me Can't locate 
loadable object for module Win32::GUI in @INC ... end :(

First I think that this package ActivePerl-5.8.2.808 is not multi-thread, and 
so I have a mistake.Then I have put PPM Win32-GUI-0.0.670, and it work! I have 
made something not correctly. I do not understand :(

Any ideas?

Thanks. 

 
 

RE: [perl-win32-gui-users] Intermediate release of Win32::GUI

[Stephen Pick]

Hi,
 
I believe that the 670 version has some old hooks code in it, this version is 
available as a ppm on sourceforge. The latest CVS from the 665 branch is the 
one you want for best functionality. What errors do you get on compile, and 
what compiler are you using?
 
Steve
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Levin
Sent: 13 January 2004 10:50
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] Intermediate release of Win32::GUI


Laurent, 
If corrections have enabled to put hooks, it's the good reason to make new PPM 
release of the module ;) Have you such plan?
 
I had failure of all attempts when compiled a package with corrections from CVS 
Repository :( 

RE: [perl-win32-gui-users] Intermediate release of Win32::GUI

[Stephen Pick]

Hi Jez,
 
I agree with most of your points about what goes into the project, but I feel 
that we're in the best position (as people working on active projects) to know 
what needs to be added.
 
To make you extremely happy the commit i'll do thisevening will make progress 
bars take account of -foreground and -background colour arguments. Rejoice!
 
Steve
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jez White
Sent: 13 January 2004 12:16
To: Levin; perl-win32-gui-users@lists.sourceforge.net
Subject: Re: [perl-win32-gui-users] Intermediate release of Win32::GUI


All,
 
There have been quite a few additions to the 665-fix build - so perhaps a new 
build is warranted?
 
How would people feel if there are regular new builds - say once a month 
(during active development)? [Laurent, I apologise for a suggestion that would 
give you more work!].
 
I've been thinking for a while about the problem of missing methods/functions 
for various controls. Most of below is just me speaking outloud, and does not 
offer direct solutions. With a bit of luck it may spark a bit of debate. I 
apologise in advance if this is just a boring monologue:)
 
To me the general development process seems quite selfish  -  i.e., things go 
into the build that is required for the individual developers project. Using 
myself as an example, I needed the AddImageList method for the tab strip 
control, and with a bit of tinkering and struggle I got it working (It went 
into the latest build, with Laurent graciously adding other missing tab strip 
methods). In my view, this process isn't a negative thing, but I can't help 
wondering if there is a better way of managing and dealing with missing 
methods/functions. As an example, we had a solution presented for setting the 
colour of the progress control and ideally this should be added as a method to 
the core.
 
I think part of the problem is that most of us on this list (including myself) 
are using Win32::GUI in an active project, so time and effort is devoted to our 
own needs and not on gui. So, solutions such as identifying all missing 
methods/functions, and dishing out the work in a proactive major, can only work 
if people have the time and inclination to do the work. It would also need 
someone to own, manage and control that aspect of the development project. I 
suspect that the hardcore hackers/developers have time constraints and other 
commitments that would preclude them for getting involved (?). 
 
The only solution I can think of is for more developers to get involved - 
perhaps some of you reading this list?:) Although, in my view, the key is for 
someone to manage and own. Anyone fancy the job?:) Perhaps other developers can 
be brought in through sourceforge (through the help wanted feature)?
 
Thoughts? Comments?
 
Cheers,
 
selfish jez :)
 
 
 
 
 
 
 
 
 
 

- Original Message - 
From: Levin mailto:[EMAIL PROTECTED]  
To: perl-win32-gui-users@lists.sourceforge.net 
Sent: Tuesday, January 13, 2004 10:50 AM
Subject: [perl-win32-gui-users] Intermediate release of Win32::GUI

Laurent, 
If corrections have enabled to put hooks, it's the good reason to make new PPM 
release of the module ;) Have you such plan?
 
I had failure of all attempts when compiled a package with corrections from CVS 
Repository :( 

RE: [perl-win32-gui-users] PERL Expert

[Stephen Pick]

Hi,

Most of the active people on this list are Perl experts.

Here's the code to make a logging box like you asked for:

# Make a really simple new window:
my $popup = new Win32::GUI::DialogBox (
-name = LogPopup,
-left = 100,
-top = 100,
-width = 200,
-height = 200,
-text = Log
);

# And add a textfield that fills it
$popup-AddTextfield(
-name = LogText,
-left = 0,
-top = 0,
-width = $popup-ScaleWidth,
-height = $popup-ScaleHeight,
-multiline = 1
);

# Show the window.
$popup-Show();

# Define our logging subroutine
sub logline {
# Take one argument off the front of the arguments
# list (@_) and put it in $text.
my $text = shift;

# Change the text of the textfield to it's current text
# plus our new log line (in $text) plus carriage
# return then linefeed characters.
$popup-LogText-Text($popup-LogText-Text().$text.\r\n);
}


# END

Now, in your utility scripts you should be able to use

MAIN::logline(Hello, world!);

To log a line to the text field.

Steve


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 #SHUCHI MITTAL#
 Sent: 08 January 2004 08:33
 To: perl-win32-gui-users@lists.sourceforge.net
 Subject: [perl-win32-gui-users] PERL Expert
 
 
 Hi all
  
 I am sorry if this is the wrong place to post this message 
 but I was wondering if anyone here is a general expert at the 
 PERL language other than just at the Win32::GUI module.
 I needed some help and the regular perl forums and tutorials 
 havent cleared my doubts so was hoping I can get  some help 
 from here. Please reply to this post if you there is someone 
 very good with regular expressions/pattern matching and HTML 
 text extraction with PERL. Need urgent help.
  
 Thanx to one n all
  
 Ciao..
  
 Shuchi
 
 
 ---
 This SF.net email is sponsored by: Perforce Software.
 Perforce is the Fast Software Configuration Management System offering
 advanced branching capabilities and atomic changes on 50+ platforms.
 Free Eval! http://www.perforce.com/perforce/loadprog.html
 ___
 Perl-Win32-GUI-Users mailing list
 Perl-Win32-GUI-Users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
 

RE: [perl-win32-gui-users] CVS commit

[Stephen Pick]

Hi,

OK let me introduce Hooks to those in Win32::GUI::Users who may have missed its 
introduction.

The Hacker Event Model / Hook Event Model / HEM allows you to define one or 
more Perl handlers for any window message, window command or notification. When 
your application receives a message that you have defined a hook for, 
Win32::GUI will call your Perl hook handlers.

The upshot of this is that you can now catch any Win32 API message, instead of 
just the ones that Win32::GUI knows about.

Here is a quick example or two. Note that the constants used below may not be 
exported by Win32::GUI at this time, so it's worth discovering their values 
from WinUser.h, otherwise things won't work.

# Add a hook for WM_MOVE in the main window.
$window-Hook(WM_MOVE, \windowmoved);

sub windowmoved {
my($widget, $wparam, $lparam, $type, $msg) = @_;
# The message should not be from WM_COMMAND or WM_NOTIFY:
if($type != 0) { return };

print Window moved!;
$widget-Text(You moved me);
}

# Add a hook for BN_CLICKED on a button.
my $coderef = sub {
if($_[3] != WM_COMMAND) {return};
print Button clicked!\n;
};

$button-Hook(BN_CLICKED, $coderef);

# Add another hook for BN_CLICKED on the same button.
my $coderef2 = sub {
if($_[3] != WM_COMMAND) {return};
print This is the second hook handler!\n;
};

$button-Hook(BN_CLICKED, $coderef2);

# Remove a specific hook handler from the button for
# a particular event:

$button-UnHook(BN_CLICKED, $coderef);

# Remove all the hooks for a particular event (BAD PRACTICE).

$button-UnHook(BN_CLICKED);


All in all, hooks save you a lot of trouble with nasty GetMessage()/PeekMessage 
loops and allow pretty much unlimited freedom. They were originally conceived 
as a way for modules that act as wrappers around widgets to unobtrusively 
capture events from the widget they wrapped, and to allow you to modify your 
handlers at any point in your code (normally, all the NEM handlers were forced 
to be defined when you created the object).

I hope that sort of explained something. Anyway, the current version is in the 
CVS under the 665-Fix branch. The documentation is inline in GUI.xs but I'm 
sure someone will update the main docs again soon

Steve



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Behalf Of
 Frazier, Joe Jr
 Sent: 08 January 2004 12:23
 To: Steve Pick; Win32 GUI Users
 Subject: RE: [perl-win32-gui-users] CVS commit
 
 
 Steve, can you demonstrate the use of this and what this is 
 for, because I am not quite following the whole thread.  Is 
 this a way to get controls to fire event handlers which were 
 previously not available for that control?  
 
 Joe Frazier, Jr.
 Technical Support Engineer
 Peopleclick Service Support
 
 Tel:  +1-800-841-2365
 E-Mail: mailto:[EMAIL PROTECTED]
 
 
  -Original Message-
  From: Steve Pick [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, January 07, 2004 8:34 PM
  To: Win32 GUI Users; Win32 GUI Hackers
  Subject: [perl-win32-gui-users] CVS commit
  
  
  Hi,
  
  I've committed the updated hooks code in 665-Fix. See GUI.xs for the
  documentation for the Hook and UnHook functions.
  
  What's new:
  
  Hooks work in Old Event Model and New Event Model
  You can hook WM_COMMAND and WM_NOTIFY submessages if you call 
  Hook on a
  child widget (like a button, for example)
  You can now add multiple hooks for each message. Calling 
  Hook(MSG, CODEREF)
  no longer replaces the current handler returning the old 
  handler for that
  hook (which didnt work properly anyway) but adds another 
  handler for the
  specified message. Returns true if adding succeeded or 
 false otherwise
  (normally if it returns false then the hook has already 
 been defined).
  
  When removing hooks they are identified by coderef, so this 
 is WRONG:
  
  $win-Hook(WM_MOVE, sub { print moved! });
  $win-UnHook(WM_MOVE, sub { print moved! });
  
  In that case, UnHook will return false and the hook will not 
  be removed
  because the codref passed to the UnHook call will be 
  different to the one
  passed to Hook. You should do it like this:
  
  $movedsub = sub { print moved!\n };
  $win-Hook(WM_MOVE, $movedsub);
  $win-UnHook(WM_MOVE, $movedsub);
  
  Some more arguments have been added to the handler callbacks. 
  These are
  $type and $msg. $msg is simply the code for the message that 
  triggered the
  hook, and $type is 0 for normal window message, WM_NOTIFY for 
  WM_NOTIFY
  messages, and WM_COMMAND for WM_COMMAND messages. $type is 
  there because
  often WM_COMMAND submessages, WM_NOTIFY submessages and 
  normal messages can
  conflict so it's good to check if your handler has been 
 called by the
  correct type of message. Yes this is a nasty kludge, but i 
  chose it because
  all the other options would have taken too long to get right 
  or would have
  been less intuitive.
  
  Doing UnHook() inside a hook handler seems to be safe 
 

RE: [perl-win32-gui-users] Win32::GUI help

[Stephen Pick]

Hi,

 2/ Every button click should invoke another perl script -- I 
 think I can do this by including the system command in the 
 button click method. If anyone knows any other sophisticated 
 method then pelase tell me

You can run your perl scripts using perl's do keyword:
do 'myscript.pl';

However this may lead to problems, like if myscript.pl dies, your whole script 
will die. The very best way to handle it is to fork, as in my example below. 
The added advantage of forking is the script you started will run independently 
of your window script, so you dont have to wait for it to exit if you want to 
start another script running or do something else with the GUI.

Here's how to do it:

# Signal handler for when child threads die.
# Probably not required on Win32. Put this near the top
# of your script.
sub REAPER {wait; $SIG{CHLD} = \REAPER;}
$SIG{CHLD} = \REAPER;

#
# Your GUI code goes here.
#

# Example handler for a button called buttonA.
# change 'myscript.pl' to whatever script you want to run.
sub ::buttonA_Click {
my $pid = fork;
if(!defined($pid)) { die Fork failed };
if($pid == 0) {
# This is the child thread
do 'myscript.pl';
exit;   # This quits our child.
}
}

 3/ I need to display the output while execution of each of 
 the scripts, that runs on a button click, on some sort of 
 box/window. This box or window can appear on the original 
 window or pop up a new one which would close once execution 
 finishes. that is :
 I have a basic window with buttons. on click of button I 
 should see a text box or a pop up window which shows me the 
 result of the script execution. If its a pop up window it 
 should close when script finishes execution and if its a text 
 box then it can just stay as it is once the execution finishes. I
 I have NO idea how to do this so any sort of help would be 
 great. I tried reading some tutorials on Win32::GUI but Im 
 still lost. Any advice/script snippets to start me off would 
 be much appreciated.

The hardest part is capturing the output of your auxiliary scripts as they run. 
One way to do this is make a function in your GUI script that appends a line to 
a textfield somewhere. Let's say this function is called logline() and takes 
an argument of $text. You can call the function from your external script 
(which we called 'myscript.pl' above) by using MAIN::logline(some text). 
This means replacing all those print statements with MAIN::logline() instead.

Steve

RE: [perl-win32-gui-users] New Hook Method

[Stephen Pick]

Hi,

Arrrgh.

The Win32 API deals, in the most part, with pointers to structs rather
than structs themselves. You can't pass homemade structs as Perl
references to SendMessage and hope that they're magically converted into
C pointers, that would indeed be nice, but it just isn't how it works.

I recommend you take a look at the Win32::API module for Perl. This may
help you as it certainly helped me.

Steve


 -Original Message-
 From: Glenn W Munroe [mailto:[EMAIL PROTECTED]
 Sent: 06 January 2004 14:28
 To: 'Stephen Pick'; perl-win32-gui-users@lists.sourceforge.net
 Cc: [EMAIL PROTECTED]
 Subject: RE: [perl-win32-gui-users] New Hook Method
 
 
 
 Thanks for that, Steve. I'll be looking out for the new 
 implementation.
 In the meantime, I've been playing with some other messages and always
 seem to hit the same problem with pointers to structures. When you say
 you can't use Perl to resolve the pointer does that mean it is
 impossible without XS code? Can you not just pack the correct
 structure? For example, it would be nice to be able to select 
 all items
 in a listview without going through a slow loop like:
 
 for (0..$mw-lvList-Count()-1) {$mw-lvList-Select($_)}
 
 Now,
 
 $mw-lvList-Select(-1)
 
 would be nice, but it doesn't work!
 
 Taking an idea from the VB world I tried this:
 
 use constant LVM_SETITEMSTATE = 0x1000 + 43;
 use constant LVIF_STATE   = 0x0008;
 use constant LVIS_SELECTED= 0x0002;
 
 my 
 $lvItem=pack(IiiIIp,LVIF_STATE,0,0,1,LVIS_SELECTED,,0,0,0,0);
 $mw-lvList-SendMessage(LVM_SETITEMSTATE, -1, \$lvItem);
 
 Needless to say, it fails miserably. I assume the problem is with the
 pointer to the structure. Is the structure wrong or is the 
 problem with
 the Perl variable reference? I know that a Perl variable is 
 represented
 by a C structure internally; can you get a pointer to the actual data
 value without resorting to XS code?
 
 Thanks again,
 Glenn
 
 -Original Message-
 From: Stephen Pick [mailto:[EMAIL PROTECTED] 
 Sent: Monday, 05 January, 2004 06:46
 To: [EMAIL PROTECTED]; perl-win32-gui-users@lists.sourceforge.net
 Cc: [EMAIL PROTECTED]
 Subject: RE: [perl-win32-gui-users] New Hook Method
 
 Hi Glenn,
 
  I've been trying to get the ListView EditLabel feature to 
 work. I can
  turn it on OK and have got the handle to the edit control 
 and through
  that the control's contents. The problem is that the control is
 created
  and destroyed automatically, and it is difficult to get 
 access to the
  final data. According to MSDN, an LVN_ENDLABELEDIT notification is
 sent
  just before the control is destroyed, but I can't figure out how to
 get
  to that. Would the new Hook method work? Again, according to MSDN,
 the
  LVN_ENDLABELEDIT notification is sent in the form of a WM_NOTIFY
  message. Would I have to grab that? That sounds like it may 
 be biting
  off more than I can chew... Can you offer any pointers? Could you
  perhaps post a snippet of code showing how the Hook method works?
 
 You can't do this with Hooks at the moment. Personally I am not happy
 with the current hook implementation as it does not satisfy what I
 originally intended it to do. A new hook implementation should come in
 the next few days, and I'll add the ability to hook notifications as
 well as messages.
 
 The problem is that WM_NOTIFY messages are delivered with an 
 lParam that
 is a pointer to a structure containing the notification code (like
 LVN_ENDLABELEDIT). While you can use the current hooks 
 implementation to
 catch WM_NOTIFY and see the wParam and lParam arguments, the lParam
 pointer is useless to you in Perl and you can't use Perl to 
 resolve the
 pointer and get the notification code from it.
 
 Watch this space...
 
 Steve
 
 
 
 

RE: [perl-win32-gui-users] Printing and save/restore dialog

[Stephen Pick]

There is a module on CPAN called Win32::Printer:
 
http://search.cpan.org/~wasx/Win32-Printer-0.6.6.1/Printer.pm
 
Check it out, it's great.
 
Steve

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Chris
Sent: 03 January 2004 02:38
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] Printing and save/restore dialog



Okay, I want to add a printing function into my application. I can write
my output to a file. But I don't know what to do from there. I also want
to implement an open and save function into it so I can back up my
database and restore it.