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

RE: [perl-win32-gui-hackers] Problems building under Mingw

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

Ok,

Doing:

size = GetFileVersionInfoSize((char*)filename, &handle);

and:

if(GetFileVersionInfo((char*)filename, handle, size, data)) {

"Fixes" the errors, the resulting binary runs fine as does NotifyIcon.pl - 
why the error - no idea - as a guess the mingw headers.


>From: "Jeremy White" <jez...@ho...>
>To: per...@li...
>Subject: [perl-win32-gui-hackers] Problems building under Mingw
>Date: Thu, 20 Apr 2006 07:35:26 +0000
>
>GUI.xs: In function `void XS_Win32__GUI_GetDllVersion(PerlInterpreter*, 
>CV*)':
>GUI.xs:5591: warning: converting of negative value `-0x000000001' to 
>`DWORD'
>GUI.xs:5592: warning: converting of negative value `-0x000000001' to 
>`DWORD'
>GUI.xs:5593: warning: converting of negative value `-0x000000001' to 
>`DWORD'
>GUI.xs:5625: error: invalid conversion from `const TCHAR*' to `CHAR*'
>GUI.xs:5625: error:   initializing argument 1 of `DWORD 
>GetFileVersionInfoSizeA(
>CHAR*, DWORD*)'
>GUI.xs:5629: error: invalid conversion from `const TCHAR*' to `CHAR*'
>GUI.xs:5629: error:   initializing argument 1 of `BOOL 
>GetFileVersionInfoA(CHAR*
>, DWORD, DWORD, void*)'
>
>I'll have a play and see if I can track it down.
>
>Cheers,
>
>jez.
>
>
>
>
>-------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job 
>easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Perl-Win32-GUI-Hackers mailing list
>Per...@li...
>https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>http://perl-win32-gui.sourceforge.net/

Re: [perl-win32-gui-hackers] Re: Unicode support (and Win32::GUI::DropFiles progress)

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

>>With Vista just round the corner and native 64bit soon to be a 
>>requirement...
>
>Eggzactly!  Poor planning on MS's part, isn't an emergency on my clients' 
>part.  Or Rob's.  In this case, the poor planning, is that people really 
>don't need all the new features in new operating systems... they'd really 
>rather just have the bugs fixed in the old ones.

Yeah, I think Microsoft is going to be in for a bit of a shock to see how 
slowly corporations upgrade to Vista. The benefits over the XP line is 
extremely questionable. Saying that, with Vista being bundled on new 
machines, it's inevitable that one day Vista will be king.

Cheers,

jez.

[perl-win32-gui-hackers] Problems building under Mingw

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

GUI.xs: In function `void XS_Win32__GUI_GetDllVersion(PerlInterpreter*, 
CV*)':
GUI.xs:5591: warning: converting of negative value `-0x000000001' to `DWORD'
GUI.xs:5592: warning: converting of negative value `-0x000000001' to `DWORD'
GUI.xs:5593: warning: converting of negative value `-0x000000001' to `DWORD'
GUI.xs:5625: error: invalid conversion from `const TCHAR*' to `CHAR*'
GUI.xs:5625: error:   initializing argument 1 of `DWORD 
GetFileVersionInfoSizeA(
CHAR*, DWORD*)'
GUI.xs:5629: error: invalid conversion from `const TCHAR*' to `CHAR*'
GUI.xs:5629: error:   initializing argument 1 of `BOOL 
GetFileVersionInfoA(CHAR*
, DWORD, DWORD, void*)'

I'll have a play and see if I can track it down.

Cheers,

jez.

Re: [win32gui] [perl-win32-gui-hackers] Creating a new Win32-GUI class

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

>How about something like this:
>- The 'userdata' member of the (internal) stored data always holds a hash.  
>The UserData method stores the passed SV in the 'UserData' member of that 
>hash.
>The 'Data' method stores the passed SV in the hash with a key equal to the 
>current classname (obtained from ref($_[0])).  As you can't have 2 classes 
>with the same name in an inheritance hierarchy, nothing ever clobbers 
>anything else.
>
>This would be problematic if you ever wanted access to your instance data 
>from a different package from where you set it - but you really should be 
>using accessor methods to do this anyway.
>
>Does this work, and is it sensible?

Very interesting and elegant solution. I can't see why this wouldn't work. 
Just so I understand you:

The userData SV on PERLWIN32GUI_USERDATA, will become a hash if it is ever 
used (perhaps we should rename this member?). When the user calls the 
UserData method to store data, the data is stored in the hash with the key 
'UserData'. If the Data method is used to store data, the class name of the 
object will be used to store the data in the hash.

Cheers,

jez.

RE: [perl-win32-gui-hackers] Re: Unicode support (and Win32::GUI::DropFiles progress)

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

>>>(3) Drop support for Win95/98/ME - I don't want to do this yet.
>>
>>I'd rather not drop support for Win9x yet either.  Still have clients 
>>using it...
>
>I'm still using it, and I don't want to have to pay MS to upgrade yet 
>(althoug a new PC is on the horizon).

With Vista just round the corner and native 64bit soon to be a 
requirement...

jez.

[perl-win32-gui-hackers] Re: Unicode support (and Win32::GUI::DropFiles progress)

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

Glenn Linderman wrote:
> On approximately 4/18/2006 2:56 PM, came the following characters from 
> the keyboard of Robert May:

[snip]

>> I allowed myself to be sidetracked by Reini's comment that his code 
>> didn't support Unicode file nmaes, and have spend a considerable time 
>> looking at the options for how to do this.  
> 
> There has been discussion recently on p5p about the fact that ActivePerl 
> implementation of operators like -d -r -f etc. also do not support 
> Unicode file names.  The question has been asked if ActiveState has any 
> plans to fix that.

Thanks.  I'm already following that thread, and have looked quite 
extensively at the win32 parts of the perl source in the last weeks. 
It's peppered with branches that call the  W and A decorated win32 apis, 
based on an USING_WIDE() macro, that is currently defined as 0.

[options for supporting Unicode in Win32::GUI]

>> (1) Use undecorated apis, and compile with -DUNICODE (and friends) on 
>> WinNT and above.  Workable, but requires 2 binary distributions.
> 
> And, it is not clear that it even works/helps.  I experimented a while 
> with adding -DUNICODE to the compiles of Win32::GUI, and found no change 
> in behavior!  So I know a lot less about Windows APIs than you do--maybe 
> you could get it to work, but I agree that since the expected result 
> doesn't meet the goal, that figuring out that direction isn't worthwhile.

It's not as simple as just defining -DUNICODE, as the W apis give us 
UCS-2, and that needs converting to UTF-8 for perl usage - pretty much 
anything that uses a string would need re-writing to work.

[snip]

>> (3) Drop support for Win95/98/ME - I don't want to do this yet.
> 
> I'd rather not drop support for Win9x yet either.  Still have clients 
> using it...

I'm still using it, and I don't want to have to pay MS to upgrade yet 
(althoug a new PC is on the horizon).

>> (4) Write code that branches based on OS version and calls the 'A' or 
>> 'W' apis as appropriate for the platform.  This will result in larger 
>> code size, and an overhead for the switch, but is, I believe, the best 
>> compromise.  I want to work on reducing the code size anyway, and an 
>> confident in the long term that we can minimise the number of places 
>> we need to do this, and that the overhead can be made small.  By 
>> writing the branches carefully, and judicious usage of #ifdefs and 
>> macros it will be possible for someone who knows that their code will 
>> only run on NT and higher to compile a smaller and faster version with 
>> no Win9X/ME support.  This approach also makes it easy to strip the 
>> legacy Win9X/ME code at a later date when we de-support these platforms.
> 
> Sounds good to me.  I'll be glad to hear what you are doing, and help as 
> able, which may not be much more than encouraging comments

Having finished coding the DropFiles implementation, I can confirm that 
I have not yet found a reason why this will not work.  Just some 
documentation to go.

> ... right now 
> I'm discovering that the latest versions of ImageMagick and PAR don't 
> work together, and it seems that the solution is either to find a 
> solution other than PAR, or fix PAR.... :(

I've seen your threads in perl.par and on perl-win32-users.  I'm not am 
ImageMagick user, so can't help here.

Regards,
Rob.

[perl-win32-gui-hackers] Unicode support (and Win32::GUI::DropFiles progress)

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

Hi all,

A quick update on what I'm looking at right now.  I'm not as far along 
as I wanted to be, but I lost a load of time fighting what turned out to 
be a MinGW bug, and more time to a crashed hard disk on my main 
development box.  But all is back in order again now.

I'm near committing a Win32-GUI-DropFiles module to CVS.  I've got a bit 
of re-organising to do, and a couple of bugs to work around with 
MakeMaker under perl 5.6, but I'm mostly there.  Many thanks to Reini 
for the ground-work on this.

I allowed myself to be sidetracked by Reini's comment that his code 
didn't support Unicode file nmaes, and have spend a considerable time 
looking at the options for how to do this.  The dropfile code seemed 
like a good place to start, as it's entirely new code, and has one api 
that might return a unicode filename (DragQueryFile).  I've reached a 
conclusion on the 'right' way for us to proceed with Unicode support, 
but wanted to document my findings, and ask for any further input.

Problem Statement:  'W' apis are only supported natively on WinNT and 
above (not Win95/98/ME, which only support the 'A' apis).  I want to 
retain support for Win95/98/ME in the codebase, and only have a single 
binary distribution**.

** the sinlge binary is important so that (a) we don't have confusions 
with our PPMs, as I cannot find a sensible way to package both binaries 
into a PPM, and get the right one installed, and (b) so that executables 
packed with PAR/PerlApp etc. can be move between Win9X and WinNT systems.

Options:

(1) Use undecorated apis, and compile with -DUNICODE (and friends) on 
WinNT and above.  Workable, but requires 2 binary distributions.

(2) Use 'W' apis only, and do as Microsoft would have us do, linking 
with their unicows.dll library.  This was my preferred approach, as it 
would leave us with the smallest code size, easy to understand source 
and almost no performance penalty on WinNT systems. But ... MS don't 
provide a link library for MinGW.  Searching, I found an opensource 
implementation (http://libunicows.sourceforge.net/ and it certainly did 
the job for VC, MinGW and other compilers.  But ... we'd need to 
distribute unicows.dll, and the MS licensing terms for re-distribution 
are just not compatible with our licence (we'd need to prevent our users 
from further re-distribution, and need a click-through EULA at 
installation) - we can't live with this.  I suspect that this approach 
would also leave us with problems with PAR/PerlApp packing, even if such 
executables didn't also suffer from the same licensing problems.  I did 
find an opensource replacement for unicows.dll, but it doesn't implement 
the full set of apis we need (not by a long way), and I don't want a 
pre-requsite to be working on that codebase. 
(http://opencow.sourceforge.net/)

(3) Drop support for Win95/98/ME - I don't want to do this yet.

(4) Write code that branches based on OS version and calls the 'A' or 
'W' apis as appropriate for the platform.  This will result in larger 
code size, and an overhead for the switch, but is, I believe, the best 
compromise.  I want to work on reducing the code size anyway, and an 
confident in the long term that we can minimise the number of places we 
need to do this, and that the overhead can be made small.  By writing 
the branches carefully, and judicious usage of #ifdefs and macros it 
will be possible for someone who knows that their code will only run on 
NT and higher to compile a smaller and faster version with no Win9X/ME 
support.  This approach also makes it easy to strip the legacy Win9X/ME 
code at a later date when we de-support these platforms.

Comments welcome.  In the meantime I'll get on with the implementation.

Regards,
Rob.

Re: [win32gui] [perl-win32-gui-hackers] Creating a new Win32-GUI class

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

Jeremy White wrote:
> Brian Millham skin email on the users list has highlighted something 
> that I've been thinking about for a while - how to make creating 
> Win32-GUI classes easier/safer.
> 
> One of the problems creating a Win32-GUI class is were to store the 
> instance data for the object while allowing the events to have access to 
> this data.
> 
> In the current version of Win32-GUI you can stuff data into a structure 
> and store it via the window with the UserData method, and then retrieve 
> it in the event handler:

[snip]

> This works well, but there is huge scope for clobbering the data if this 
> approach was used for a formal class. Ok - in the class documentation 
> you could mention that the instance data is stored as a hash, and if you 
> need to store data via UserData you should use your own key - but I'm 
> wondering if there is a better way to handle this? For example, we could 
> add a "Data" method which could be used to store instance data, leaving 
> the UserData method free for the user?

I've been thinking about this for some time too.  My view is that 
'UserData' should be just that, for the script writer to use.  Modules 
should have somewhere else.  Inheritance causes problems, as each level 
in the inheritance chain may want to store some instance data, without 
clobbering any other layer.

How about something like this:
- The 'userdata' member of the (internal) stored data always holds a 
hash.  The UserData method stores the passed SV in the 'UserData' member 
of that hash.
The 'Data' method stores the passed SV in the hash with a key equal to 
the current classname (obtained from ref($_[0])).  As you can't have 2 
classes with the same name in an inheritance hierarchy, nothing ever 
clobbers anything else.

This would be problematic if you ever wanted access to your instance 
data from a different package from where you set it - but you really 
should be using accessor methods to do this anyway.

Does this work, and is it sensible?

Regards,
Rob.

[perl-win32-gui-hackers] -tooltip

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

I want to use methods on the windows -tooltip object.
e.g. to use multiline texts I have to use the SetMaxTipWidth method.

But GUI_Helper.cpp:CreateTooltip only stores the tooltip handle
and not the XS object in the hash at -tooltip.

Well, I can SendMessage to this handle:
  use constant TTM_SETMAXTIPWIDTH =3D> (1024+24);
  SendMessage($W->{-tooltip}, TTM_SETMAXTIPWIDTH, 0, $width);
but what do we have this object for if we cannot access it?

Shouldn't these Win32::GUI::Tooltip::Add options be also supported?

    #  -maxtipwidth =3D> width
    #     required for enable multiline
    #  -alwaystip  =3D> 0/1
    #  -noprefix   =3D> 0/1
    #  -balloon    =3D> 0/1
--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [win32-gui] [perl-win32-gui-hackers] How to create/use COM components in plain C, without MFC, ATL, WTL, or any other

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

Nice article.  I've tucked it away for future reference.

Rob.

Jeremy White wrote:
> I came across this great article - may be of interest to some people:
> 
> Introduction
> There are numerous examples that demonstrate how to use/create 
> COM/OLE/ActiveX components. But these examples typically use Microsoft 
> Foundation Classes (MFC), .NET, C#, WTL, or at least ATL, because those 
> frameworks have pre-fabricated "wrappers" to give you some boilerplate 
> code. Unfortunately, these frameworks tend to hide all of the low level 
> details from a programmer, so you never really do learn how to use COM 
> components per se. Rather, you learn how to use a particular framework 
> riding on top of COM.
> 
> If you're trying to use plain C, without MFC, WTL, .NET, ATL, C#, or 
> even any C++ code at all, then there is a dearth of examples and 
> information on how to deal with COM objects. This is the first in a 
> series of articles that will examine how to utilize COM in plain C, 
> without any frameworks.
> 
> http://www.codeproject.com/com/com_in_c1.asp
> 
> Cheers,
> 
> jez.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> http://perl-win32-gui.sourceforge.net/
> 

[perl-win32-gui-hackers] Re: [win32-gui] Re: [perl-win32-gui-users] Start dir in BrowseForFolder without -root

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

Reini Urban wrote:
> Attached patch fixes this issue.

Thanks.  Will apply before the next release.

Regards,
Rob.

[perl-win32-gui-hackers] How to create/use COM components in plain C, without MFC, ATL, WTL, or any other

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

I came across this great article - may be of interest to some people:

Introduction
There are numerous examples that demonstrate how to use/create 
COM/OLE/ActiveX components. But these examples typically use Microsoft 
Foundation Classes (MFC), .NET, C#, WTL, or at least ATL, because those 
frameworks have pre-fabricated "wrappers" to give you some boilerplate code. 
Unfortunately, these frameworks tend to hide all of the low level details 
from a programmer, so you never really do learn how to use COM components 
per se. Rather, you learn how to use a particular framework riding on top of 
COM.

If you're trying to use plain C, without MFC, WTL, .NET, ATL, C#, or even 
any C++ code at all, then there is a dearth of examples and information on 
how to deal with COM objects. This is the first in a series of articles that 
will examine how to utilize COM in plain C, without any frameworks.

http://www.codeproject.com/com/com_in_c1.asp

Cheers,

jez.

[perl-win32-gui-hackers] Re: [perl-win32-gui-users] Start dir in BrowseForFolder without -root

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

Attached patch fixes this issue.

2006/4/5, Amondsen, Nikolaj Berg DK - AFI <nb...@af...>:
>
> That is perfect!
> Thank you very much :)
> I wonder why that isn=B4t mentioned in the documentation, it seems like a=
 normal
> and usefull feature.
>
>
> - Nikolaj
>
>
> > -----Original Message-----
> > From: darrik [mailto:da...@my...]
> > Sent: 4. april 2006 21:22
> > To: Amondsen, Nikolaj Berg DK - AFI
> > Cc: per...@li...
> > Subject: Re: [perl-win32-gui-users] Start dir in
> > BrowseForFolder without -root
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: RIPEMD160
> >
> > the -directory option specifies starting folder.
> >
> > ex.:
> >
> > Win32::GUI::BrowseForFolder(
> >       -root =3D> 'c:\\',
> >       -directory =3D> 'c:\\program files\\',
> >       );
> >
> > this will start at "c:\program files\" but you can browse up to "c:\"
> > (the root).
> >
> > ~darrik
> >
> >
> >
> > Amondsen, Nikolaj Berg DK - AFI wrote:
> > > Hi
> > >
> > > Is it possible to specify a startdir for the
> > BrowseForFolder function
> > > so that is is still posible to browse for folders above
> > this folder in
> > > the filestructure.
> > > Using -root hides everything above the specified root-dir,
> > allthough
> > > it is still possible to select files outside this dir by
> > filling out
> > > the textfield manually..
> > >
> > > What I would like to use this for is having my application
> > start the
> > > BrowseForFolder dialog in the folder most resently used, but still
> > > alloving the user to browse outside that folder.
> > >
> > >
> > > - Nikolaj
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > language that extends applications into web and mobile
> > media. Attend
> > > the live webcast and join the prime developer group
> > breaking into this new coding territory!
> > > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=12164=
2
> > > _______________________________________________
> > > Perl-Win32-GUI-Users mailing list
> > > Per...@li...
> > > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> > > http://perl-win32-gui.sourceforge.net/
> > >
> > >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2.1 (MingW32)
> >
> > iD8DBQFEMsdjNLjD3/G9w0YRA/EYAJ4sWk/EgKAq4bci6vQxxZa1Sge+2wCfZTwr
> > tQdid6uo+B3ouW72QdopBgI=3D
> > =3D4V1L
> > -----END PGP SIGNATURE-----
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>


--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

[perl-win32-gui-hackers] Creating a new Win32-GUI class

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

Hi,

Brian Millham skin email on the users list has highlighted something that 
I've been thinking about for a while - how to make creating Win32-GUI 
classes easier/safer.

One of the problems creating a Win32-GUI class is were to store the instance 
data for the object while allowing the events to have access to this data.

In the current version of Win32-GUI you can stuff data into a structure and 
store it via the window with the UserData method, and then retrieve it in 
the event handler:

my $win=create the window
my $instancedata = create the instance data
#attach the instance data to the window
$win->UserData($instancedata);

in the event handlers:

#for window events
my $instancedata=$self->UserData();

#for child events, such as buttons on the window
my $instancedata=$self->GetParent->UserData();

This works well, but there is huge scope for clobbering the data if this 
approach was used for a formal class. Ok - in the class documentation you 
could mention that the instance data is stored as a hash, and if you need to 
store data via UserData you should use your own key - but I'm wondering if 
there is a better way to handle this? For example, we could add a "Data" 
method which could be used to store instance data, leaving the UserData 
method free for the user?

Thoughts?

Cheers,

jez.

Re: [win32gui] Re: [perl-win32-gui-hackers] DrapDrop support for Win32::GUI

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

Glenn Linderman wrote:
> On approximately 3/19/2006 10:49 AM, came the following characters from 
> the keyboard of Robert May:
>> it is my understanding that PAR 
>> has the ability to determine what methods are used, and only package 
>> up the autoload subs that are required.
> 
> I'm unaware of such abilities in PAR.  If you find documentation of 
> such, point me at it.  PAR uses Module::ScanDeps to determine 
> dependencies, but I believe that is all module granularity.

I thought I had read this, but I could well be wrong.  If I find a 
reference then I'll be sure to post it.

Regards,
Rob.

[perl-win32-gui-hackers] ListView Bug? - Column Width (0 , -2)

[Eric H. <eh...@co...>]

#-- This is a code snipet from a Dual Listbox control dialog which
allows=20
#-- the user to reorder the columns of a ListView "on-the-fly".  The
order
#-- of columns saved is saved in a MS-ACCESS table for each unique
username
#-- so that the user will retain those column order settings for future
#-- sessions. =20
#-- =20
#-- BUG REPORT:=20
#-- I am noticing column 0 of the Listview is much wider than the
#-- width of the column header text?  This appears to be a bug in the
#-- widget. See code below for setting column widths.=20

#####################
sub BTN_Save4_Click {
#####################  =20
   my $ls_text;          #-- local scalar
   my $ls_sel;
   my $ls_i;
   my $ls_sqltxt;
   my $ls_ret;
   my $ls_error;
   my $ls_len;

   #-- if all column names have not been selected from left listbox,
return.=20
   if ($LB_List1->Count() > 0) {return 1;}

   @ga_ColumnOrder=3D();
   %gh_ColumnOrder=3D();
   %gh_ColumnList=3D();
=20
   $ls_sqltxt =3D "UPDATE tblColumnOrder SET ";
   =20
   for ($ls_sel=3D0;$ls_sel<=3D36;$ls_sel++) {
      $ls_text=3D$LB_List2->GetString($ls_sel);
      $gh_ColumnOrder{$ls_sel}=3D$ls_text;
      $gh_ColumnList{$ls_text}=3D$ls_sel;
      $ga_ColumnOrder[$ls_sel]=3D$gh_OrigColumnList{$ls_text};
      $ls_sqltxt =3D $ls_sqltxt . "[" . $ls_text . "]=3D" . $ls_sel . =
",";
   }

   $LV->SetColumnOrderArray(@ga_ColumnOrder);
   $LV->RedrawItems(0,$LV->Count()-1);
   for($ls_i=3D0;$ls_i<=3D36;$ls_i++) {
      $LV->SetColumnWidth($ls_i,-2);  #-- adjust to fit column header
text=20
   }
   #-- for some reason, column 0 stretches out wide way! past the width
of
   #-- the column header text?  All other columns are as wide as header
   #-- text.   This appears to be a bug in the widget.=20

   $ls_len=3Dlength($ls_sqltxt);
   $ls_sqltxt=3Dsubstr($ls_sqltxt,0,($ls_len-1));=20
   $ls_sqltxt=3D$ls_sqltxt . " WHERE username =3D '" . $gs_LoggedUser . =
"'";


   ...
}

Re: [win32gui] Re: [perl-win32-gui-hackers] DrapDrop support for Win32::GUI

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

Jeremy White wrote:
 > Robert May wrote:
>> NotifyIcon I certainly have on my list of candidates.  I haven't 
>> thought much beyond that, but I am hopeful that a restructuring like 
>> this might reduce GUI.xs and GUI.pm to more manageable sizes.  I also 
>> want to experiment with moving a lot of the per-control methods from 
>> XS back into perl.  There are many methods implemented in XS that do a 
>> single call to SendMessage.  By moving them back into perl I don't 
>> think we'll see much of a performance hit (there's still one 'thunk' 
>> between perl and XS, which I suspect to be the largest time overhead), 
>> and will be able to move all such methods to be AUTOLOADed, so we only 
>> take compile time and memory hits if we use them in our apps.
> 
> I think we also have to bare in mind that a Win32-GUI app isn't deployed 
> and run in the same way as a normal perl module/application. Most of the 
> time a Win32-GUI app is run as an exe produced by PerlApp/Perl2exe/PAR. 
> Even if the dll is reduced in size by moving out simple sendmessage 
> calls, we just add bloat to the perl packages which would increase the 
> size of the exe - even if those functions are never used. OK - if we 
> split things out into separate packages they shouldn't be included in 
> the exe - but I'm just wondering if we're making work for ourselves 
> without any "real" tangible benefits i.e., if it's not broke why "fix it"?

I think there are 2 main uses for Win32::GUI:
(1) Very simple front ends for Windows platforms.  For example, consider 
the recent request in the users list for implementing a dialog to enter 
a text string.  When doing simple things like this we shouldn't have to 
pull in 3MB of dll plus all the perl code.

(2) The example you give on an app packed with PAR/PerlApp/Perl2exe etc. 
  Even in this case it would be nice to minimise the amount of stuff 
that we need to package up.

I can' speak for PerlApp and Perl2exe, but it is my understanding that 
PAR has the ability to determine what methods are used, and only package 
up the autoload subs that are required.  I am sympathetic to using these 
packaging tools, and certainly don't want to do anything that increases 
the difficulty of making such exes.  Equally I don't want to see their 
size increase either.  The perl vs. xs split is a difficult call to 
make, and one that I am not convinced I know the right answers to yet, 
but I do want to experiment with some ideas, and see how the 
size/performance trade-offs work.

> I'm a little "sensitive" when it comes to memory usage, as one of my 
> Win32-GUI apps uses 50 meg before it's even done anything - a good chunk 
> of that is due to Win32-GUI - I use a lot of controls, and think of all 
> those SV's that are used for each one:) Getting rid of the tied hash 
> would be a good start:)

Getting rid of the tied hash mechanism is on my list of things to look 
at.  I think that I do now understand all that it is doing for 
Win32::GUI, however, I'm nervous about touching it, as the potential for 
introducing memory leaks and destruction problems is very large 
(although as currently implemented there are already some problems).  I 
will get around to looking at this, but it needs care.

I don't think the perl vs. xs issue significantly affects the number of 
SV's that will be used per-say.

> Assuming you mean the typemap code when you talk about the "thunk" - the 
> Win32-GUI typemap it's relatively efficient - more so than the "classic" 
> way of doing a typemap conversion (when you check for the correct 
> object) - so it'll probably be worth doing some performance testing to 
> see what (if any) the impact would be.

Not just the typemap.  By the 'thunk' (and I think 'thunking' is a 
proper perl term) I mean all the stack and variable manipulation that is 
required to call into XS - conversion of SV's to C variables and back 
has overhead ... Where I'm going here is that we don't want to move 
functions/methods that call multiple windows apis from xs back into 
perl, as that would leave us with a function that does multiple 
perl-xs-perl transitions, rather than a single one.

More work required, and it will happen in time.  I hope that it can be a 
gradual evolution, during which we learn what works and what doesn't.

Regards,
Rob.

Re: [win32gui] Re: [perl-win32-gui-hackers] DrapDrop support for Win32::GUI

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

100% agreed with all points. Thanks.

2006/3/18, Robert May <rm...@po...>:
> Reini Urban wrote:
>  >Robert May wrote:
> >>Here's what I am proposing:
> >>
> >>(1) All windows/controls will gain the -acceptfiles option that will be
> >>used to set/unset the WS_EX_ACCEPTFILES extended style on the
> >>window/control (For those of you familiar with it, this is all that the
> >>Win32 DrapAcceptFiles() API does). This is a minor change to
> >>GUI_Options.cpp, and improves on the original implementation that only
> >>supported dropping for Window/DialogBox.
> >
> > Great!
>
> OK.
>
> >>(2) All Windows/Controls will gain the AcceptFiles() method to get/set
> >>the WS_EX_ACCEPTFILES extended style.  Additionally, as this informatio=
n
> >>is available from the extended style, no additional storage is needed t=
o
> >>track a window's dragdrop state.
> >
> > The only minor inconvenience is with the naming.
> >   DragDrop object
> >   -acceptfiles option
> >   DropFiles ( =3D> WM_DROPFILES ) NEM or OEM eventname
> >   GetDroppedFiles() vs. DragQueryFile() methods
> >
> > I'd rather prefer -dropfiles over -acceptfiles, so that the supported
> > event has the same name as the option which declares it.
> > On the other side, WS_EX_ACCEPTFILES and DrapAcceptFiles() is also
> > established on the API side.
>
> I'm not wedded to the API call names, particularly when we have methods
> that don't directly map to the API.  As I think about it I propose the
> following public API:
>
> - flag to turn on/off WS_EX_ACCEPTFILES will be -acceptfiles - we have
> precedent for naming style options like this.
> - the callback will be -onDropFiles and <window_name)_DropFiles, as
> that's what it is called today, and matches precedent for naming events
> (cf. WM_DROPFILES)
> - For consistency the module will be named Win32::GUI::DropFiles.  This
> better reflects the actual functionality, and avoids a namespace clash
> with the existing Loft Win32::GUI::DragDop
> - There will an AccepFiles() method on the window objects for
> getting/setting the WS_EX_ACCEPTFILES style.  This is consistent with
> current naming conventions (e.g. -dialogui/DialogUI()) Note that we can
> also use $win->Change(-acceptfiles =3D> 0|1) for setting.
>
> >>(2) The DropFiles callback which is already supported for all
> >>windows/controls (handling WM_DROPFILES) will change it's callback
> >>parameter from the current HDROP integer to a Win32::GUI::DropFiles
> >>object.  This is a minor change to GUI_MessageLoops.cpp
>
> This change will only be made if our new Win32::GUI::DropFiles module is
> loaded.  If it is not, then the existing callback with a drophandle will
> be used - this gives us the backwards compatibility we are looking for.
>
> >>(3) The Win32::GUI::DropFiles object will expose the following methods:
> >>
> >>- GetDroppedFiles, which will return:
> >>    in scalar context the number of files dropped
> >>    in list context a list of dropped file names
> >>- GetDroppedFile, which will take a zero-based index for
> >>    the dropped file, and will return the file name
> >
> > hmm.
>
> Why hmm?  We need to provide some sort of iterator access so that the
> user can efficiently deal with large numbers of dropped files, rather
> than only being able to get a list of all the files.  Perhaps a proper
> interator api would be better with a Reset() and GetNextFile[Name]()
> interface?
>
> >>- GetDropPos, which will return:
> >>    in scalar context whether the drop was in the client or
> >>      non-client area of the window
> >
> > Is this possible at all?
>
> Yes, it's the return value of DragQueryPos
>
> >>    in list context the position of the mouse when the drop
> >>      occurred in client co-ordinates
> >
> >>It should be possible to write GetDroppedFiles() so that code written t=
o
> >>use the GUI Loft's GetDroppedFiles() method will continue to work,
> >>without modification.
>  > That was my idea also.
>  > The only problem is with the naming, DragQueryFile() vs
>  > GetDroppedFile()
>
> This is no longer necessary, and deals with the naming conflict for
> DragQueryFile
>
> > It's only the Loft which introduced the name GetDroppedFiles().
> > WINAPI declares DragQueryFile and DragQueryPoint. I would like to stay
> > with the WINAPI names.
>
> I'm not wedded to the API calls, but the module will also provide the
> following (non-?)public APIs:
>
> Win32::GUI::DropFiles::DrapAcceptFiles(HWND,FLAG)
> - direct mapping of the win32 api.  Included only for completeness.
>
> Win32::GUI::DropFiles::DragQueryFile(HDROP, [ITEM])
> - mapping of the win32 api DragQueryFile api: if called with only the
> HDROP parameter, returns a count of the dropped files; if called with
> the HDROP and ITEMS parameter returns the filename for ITEM
>
> Win32::GUI::DropFiles::DragQueryPoint(HDROP)
> - returns a list of 3 scalars: X-pos, y-pos and (non-)client flag
>
> Win32::GUI::DropFiles::DragFinish(HDROP)
> - direct mapping of the win32 api
>
> > GetDropPos: Doesn't DragQueryPoint report the position
> > while being dragged also? So it's not only after being dropped.
>
> No.  We only get the HDROP handle after the drop occurs (in the
> WM_DROPFILES message) You need to implement a full COM IDropTarget
> interface and use RegisterDragDrop() api to get this sort of
> functionality.  You'd then get DragEnter, DragOver, DragLeave and Drop
> callbacks, and more control over what the cursor looks like etc.  A
> future enhancement to this module? :-)
>
> > The idea behind the high level GetDroppedFiles() is to automatically
> > cleanup the object.
>
> I don't agree with this - that might have been the intention of the
> original DragDrop module, but is not mine.
>
> > I'm not sure if this is a good idea, since perl
> > automatically will DESTROY the HDROP, and a DragQueryPoint afterward
> > will fail. So please back this idea out.
>
> Right - calling DragFinish makes the HDOP handle invalid, and so it
> can't be re-used later.  My implementation of GetDroppedFiles() does not
> call DragFinish(), and I have DrapFinish called in the object's DESTORY
> method, so that it gets called when the object goes out of scope
> (typically at the end of the DropFiles callback).
>
> This approach is problematic, as if the DropFiles module is not loaded,
> then there is no DESTROY method, and DragFinish never gets called,
> resulting in a memory leak.  Note that this is no worse than today's
> situation, where if you set the WS_EX_ACCEPTFILES style and don't
> explicitly call DragFinish() somewhere in the callback we have a leak.
>
> Really the WM_DROPFILES handling code should call DragFinish() and
> return 0.  This is easy enough to implement, but does mean that object
> passed to the callback is only valid during the callback.  As I will be
> checking to see if our module is loaded before deciding whether to pass
> a HDROP handle, or Win32::GUI::DropFiles object to the callback I
> propose that if the module is not loaded, we'll explicitly call
> DragFinish when the callback returns.  From what I can see there's no
> harm in calling it if it's already been called during the callback, and
> doing this will solve the memory leak problem.
>
> >>(4) I intend to write all this as a separable module, with its own DLL
> >>for the new Win32 api calls required.  Whilst there is some overhead of
> >>this approach I want to use it as a proof of concept, as it gives the
> >>following advantages:
> >>- the code is separable, and hence more maintainable
> >>- there will be no overhead (in fact a saving) for applications that
> >>don't need the functionality (GUI.dll and GUI.pm are already way too bi=
g)
> >>- I believe that writing tests for smaller bits of functionality will
> >>prove significantly easier. (although I'm not sure this is a good examp=
le)
> >>- It will be possible to 'dual-life' modules like this, allowing for
> >>fixes/upgrades outside the normal Win32::GUI release cycle
> >
> > Ok. I like that idea and I did this with CustomDraw.pm
> > The basic event and the object property getters do work without
> > use Win32::GUI::CustomDraw;
> > You only need to use it - and import a lot of autoloaded methods and
> > helper constants - if you want to call a method, primarly for setting a
> > value, and need some constants.
>
> Right.
>
> > Maybe we should export the CustomDraw XS calls to a seperate DLL which
> > should be imported by the user or AUTOLOAD'ed.
> > But it's by far not that big as the convenience methods in the perl par=
t.
>
> Probably - but I haven't had a chance to look at your CustomDraw code yet=
.
>
> > For DragDrop:
> > The WM_DROPFILES event should work without use Win32::GUI::DragDrop;
>  > But calling the methods might require it.
>
> Without Win32::GUI::DropFiles it'll work as today, passing a HDROP
> handle. If you use Win32::GUI::DropFiles; then you'll get an object in
> the callback and acceess to the methods.
>
> > Or AUTOLOAD it based on the object name.
> > Same with the Brush and DC maybe.
> >
> >
> >>If it proves to be the wrong approach, then it will be easy to fold the
> >>changes back into the main GUI.xs and GUI.pm files.  If it proves good,
> >>the over time I hope to move other less used features out of GUI.pm and
> >>GUI.xs.
> >>
> >>Additionally I want to look at putting more of the code than we might
> >>usually in perl rather than XS so that we can keep the DLL sizes small
> >>and (in the future) take better advantages of AUTOLOADing little used
> >>methods.
> >
> > OwnerDraw, NotifyIcon and such.
> > Yes.
>
> NotifyIcon I certainly have on my list of candidates.  I haven't thought
> much beyond that, but I am hopeful that a restructuring like this might
> reduce GUI.xs and GUI.pm to more manageable sizes.  I also want to
> experiment with moving a lot of the per-control methods from XS back
> into perl.  There are many methods implemented in XS that do a single
> call to SendMessage.  By moving them back into perl I don't think we'll
> see much of a performance hit (there's still one 'thunk' between perl
> and XS, which I suspect to be the largest time overhead), and will be
> able to move all such methods to be AUTOLOADed, so we only take compile
> time and memory hits if we use them in our apps.

I believe XS code is much more performant than simple perl wrappers
over SendMessage. Memory and time wise. I'll do some research.
Our only problem is probably size and memory, time is good enough.
At least for me.
Maintainencewise simple perl pm's are much easier to
handle, even if the worst time performance is on searching and opening
of those extra files.

Pulling them only optionally in via AUTOLOAD is a good argument,
even for deployed exe's with embedded dll and pm modules.
Which is Jeremy's point.

> > PS:
> > Note that I did some wrong guards with the new NotifyIcon members.
> > It should be compiler dependent and not IE dependent, when the shell
> > version call will fail.
>
> I haven't looked yet.  It's not really compiler dependent, but SDK
> version dependent.  I'm using VC6++ compiler on Win98, but with the
> latest SDK headers, and I don't get hit by any problems.  I may make it
> a requirement to have the lastest headers, so that I can remove much of
> the work-arounds from GUI.h (or perhaps just move it all to separate
> header files) ... something to think about in the future.
--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/

Re: [win32gui] Re: [perl-win32-gui-hackers] DrapDrop support for Win32::GUI

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

>NotifyIcon I certainly have on my list of candidates.  I haven't thought 
>much beyond that, but I am hopeful that a restructuring like this might 
>reduce GUI.xs and GUI.pm to more manageable sizes.  I also want to 
>experiment with moving a lot of the per-control methods from XS back into 
>perl.  There are many methods implemented in XS that do a single call to 
>SendMessage.  By moving them back into perl I don't think we'll see much of 
>a performance hit (there's still one 'thunk' between perl and XS, which I 
>suspect to be the largest time overhead), and will be able to move all such 
>methods to be AUTOLOADed, so we only take compile time and memory hits if 
>we use them in our apps.

I think we also have to bare in mind that a Win32-GUI app isn't deployed and 
run in the same way as a normal perl module/application. Most of the time a 
Win32-GUI app is run as an exe produced by PerlApp/Perl2exe/PAR. Even if the 
dll is reduced in size by moving out simple sendmessage calls, we just add 
bloat to the perl packages which would increase the size of the exe - even 
if those functions are never used. OK - if we split things out into separate 
packages they shouldn't be included in the exe - but I'm just wondering if 
we're making work for ourselves without any "real" tangible benefits i.e., 
if it's not broke why "fix it"?

I'm a little "sensitive" when it comes to memory usage, as one of my 
Win32-GUI apps uses 50 meg before it's even done anything - a good chunk of 
that is due to Win32-GUI - I use a lot of controls, and think of all those 
SV's that are used for each one:) Getting rid of the tied hash would be a 
good start:)

Assuming you mean the typemap code when you talk about the "thunk" - the 
Win32-GUI typemap it's relatively efficient - more so than the "classic" way 
of doing a typemap conversion (when you check for the correct object) - so 
it'll probably be worth doing some performance testing to see what (if any) 
the impact would be.

Cheers,

jez.

Re: [win32gui] Re: [perl-win32-gui-hackers] DrapDrop support for Win32::GUI

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

Reini Urban wrote:
 >Robert May wrote:
>>Here's what I am proposing:
>>
>>(1) All windows/controls will gain the -acceptfiles option that will be
>>used to set/unset the WS_EX_ACCEPTFILES extended style on the
>>window/control (For those of you familiar with it, this is all that the
>>Win32 DrapAcceptFiles() API does). This is a minor change to
>>GUI_Options.cpp, and improves on the original implementation that only
>>supported dropping for Window/DialogBox.
> 
> Great!

OK.

>>(2) All Windows/Controls will gain the AcceptFiles() method to get/set
>>the WS_EX_ACCEPTFILES extended style.  Additionally, as this information
>>is available from the extended style, no additional storage is needed to
>>track a window's dragdrop state.
> 
> The only minor inconvenience is with the naming.
>   DragDrop object
>   -acceptfiles option
>   DropFiles ( => WM_DROPFILES ) NEM or OEM eventname
>   GetDroppedFiles() vs. DragQueryFile() methods
> 
> I'd rather prefer -dropfiles over -acceptfiles, so that the supported
> event has the same name as the option which declares it.
> On the other side, WS_EX_ACCEPTFILES and DrapAcceptFiles() is also
> established on the API side.

I'm not wedded to the API call names, particularly when we have methods 
that don't directly map to the API.  As I think about it I propose the 
following public API:

- flag to turn on/off WS_EX_ACCEPTFILES will be -acceptfiles - we have 
precedent for naming style options like this.
- the callback will be -onDropFiles and <window_name)_DropFiles, as 
that's what it is called today, and matches precedent for naming events 
(cf. WM_DROPFILES)
- For consistency the module will be named Win32::GUI::DropFiles.  This 
better reflects the actual functionality, and avoids a namespace clash 
with the existing Loft Win32::GUI::DragDop
- There will an AccepFiles() method on the window objects for 
getting/setting the WS_EX_ACCEPTFILES style.  This is consistent with 
current naming conventions (e.g. -dialogui/DialogUI()) Note that we can 
also use $win->Change(-acceptfiles => 0|1) for setting.

>>(2) The DropFiles callback which is already supported for all
>>windows/controls (handling WM_DROPFILES) will change it's callback
>>parameter from the current HDROP integer to a Win32::GUI::DropFiles
>>object.  This is a minor change to GUI_MessageLoops.cpp

This change will only be made if our new Win32::GUI::DropFiles module is 
loaded.  If it is not, then the existing callback with a drophandle will 
be used - this gives us the backwards compatibility we are looking for.

>>(3) The Win32::GUI::DropFiles object will expose the following methods:
>>
>>- GetDroppedFiles, which will return:
>>    in scalar context the number of files dropped
>>    in list context a list of dropped file names
>>- GetDroppedFile, which will take a zero-based index for
>>    the dropped file, and will return the file name
> 
> hmm.

Why hmm?  We need to provide some sort of iterator access so that the 
user can efficiently deal with large numbers of dropped files, rather 
than only being able to get a list of all the files.  Perhaps a proper 
interator api would be better with a Reset() and GetNextFile[Name]() 
interface?

>>- GetDropPos, which will return:
>>    in scalar context whether the drop was in the client or
>>      non-client area of the window
> 
> Is this possible at all?

Yes, it's the return value of DragQueryPos

>>    in list context the position of the mouse when the drop
>>      occurred in client co-ordinates
> 
>>It should be possible to write GetDroppedFiles() so that code written to
>>use the GUI Loft's GetDroppedFiles() method will continue to work,
>>without modification.
 > That was my idea also.
 > The only problem is with the naming, DragQueryFile() vs
 > GetDroppedFile()

This is no longer necessary, and deals with the naming conflict for 
DragQueryFile

> It's only the Loft which introduced the name GetDroppedFiles().
> WINAPI declares DragQueryFile and DragQueryPoint. I would like to stay
> with the WINAPI names.

I'm not wedded to the API calls, but the module will also provide the 
following (non-?)public APIs:

Win32::GUI::DropFiles::DrapAcceptFiles(HWND,FLAG)
- direct mapping of the win32 api.  Included only for completeness.

Win32::GUI::DropFiles::DragQueryFile(HDROP, [ITEM])
- mapping of the win32 api DragQueryFile api: if called with only the 
HDROP parameter, returns a count of the dropped files; if called with 
the HDROP and ITEMS parameter returns the filename for ITEM

Win32::GUI::DropFiles::DragQueryPoint(HDROP)
- returns a list of 3 scalars: X-pos, y-pos and (non-)client flag

Win32::GUI::DropFiles::DragFinish(HDROP)
- direct mapping of the win32 api

> GetDropPos: Doesn't DragQueryPoint report the position
> while being dragged also? So it's not only after being dropped.

No.  We only get the HDROP handle after the drop occurs (in the 
WM_DROPFILES message) You need to implement a full COM IDropTarget 
interface and use RegisterDragDrop() api to get this sort of 
functionality.  You'd then get DragEnter, DragOver, DragLeave and Drop 
callbacks, and more control over what the cursor looks like etc.  A 
future enhancement to this module? :-)

> The idea behind the high level GetDroppedFiles() is to automatically
> cleanup the object.

I don't agree with this - that might have been the intention of the 
original DragDrop module, but is not mine.

> I'm not sure if this is a good idea, since perl
> automatically will DESTROY the HDROP, and a DragQueryPoint afterward
> will fail. So please back this idea out.

Right - calling DragFinish makes the HDOP handle invalid, and so it 
can't be re-used later.  My implementation of GetDroppedFiles() does not 
call DragFinish(), and I have DrapFinish called in the object's DESTORY 
method, so that it gets called when the object goes out of scope 
(typically at the end of the DropFiles callback).

This approach is problematic, as if the DropFiles module is not loaded, 
then there is no DESTROY method, and DragFinish never gets called, 
resulting in a memory leak.  Note that this is no worse than today's 
situation, where if you set the WS_EX_ACCEPTFILES style and don't 
explicitly call DragFinish() somewhere in the callback we have a leak.

Really the WM_DROPFILES handling code should call DragFinish() and 
return 0.  This is easy enough to implement, but does mean that object 
passed to the callback is only valid during the callback.  As I will be 
checking to see if our module is loaded before deciding whether to pass 
a HDROP handle, or Win32::GUI::DropFiles object to the callback I 
propose that if the module is not loaded, we'll explicitly call 
DragFinish when the callback returns.  From what I can see there's no 
harm in calling it if it's already been called during the callback, and 
doing this will solve the memory leak problem.

>>(4) I intend to write all this as a separable module, with its own DLL
>>for the new Win32 api calls required.  Whilst there is some overhead of
>>this approach I want to use it as a proof of concept, as it gives the
>>following advantages:
>>- the code is separable, and hence more maintainable
>>- there will be no overhead (in fact a saving) for applications that
>>don't need the functionality (GUI.dll and GUI.pm are already way too big)
>>- I believe that writing tests for smaller bits of functionality will
>>prove significantly easier. (although I'm not sure this is a good example)
>>- It will be possible to 'dual-life' modules like this, allowing for
>>fixes/upgrades outside the normal Win32::GUI release cycle
> 
> Ok. I like that idea and I did this with CustomDraw.pm
> The basic event and the object property getters do work without
> use Win32::GUI::CustomDraw;
> You only need to use it - and import a lot of autoloaded methods and
> helper constants - if you want to call a method, primarly for setting a
> value, and need some constants.

Right.

> Maybe we should export the CustomDraw XS calls to a seperate DLL which
> should be imported by the user or AUTOLOAD'ed.
> But it's by far not that big as the convenience methods in the perl part.

Probably - but I haven't had a chance to look at your CustomDraw code yet.

> For DragDrop:
> The WM_DROPFILES event should work without use Win32::GUI::DragDrop;
 > But calling the methods might require it.

Without Win32::GUI::DropFiles it'll work as today, passing a HDROP 
handle. If you use Win32::GUI::DropFiles; then you'll get an object in 
the callback and acceess to the methods.

> Or AUTOLOAD it based on the object name.
> Same with the Brush and DC maybe.
> 
> 
>>If it proves to be the wrong approach, then it will be easy to fold the
>>changes back into the main GUI.xs and GUI.pm files.  If it proves good,
>>the over time I hope to move other less used features out of GUI.pm and
>>GUI.xs.
>>
>>Additionally I want to look at putting more of the code than we might
>>usually in perl rather than XS so that we can keep the DLL sizes small
>>and (in the future) take better advantages of AUTOLOADing little used
>>methods.
> 
> OwnerDraw, NotifyIcon and such.
> Yes.

NotifyIcon I certainly have on my list of candidates.  I haven't thought 
much beyond that, but I am hopeful that a restructuring like this might 
reduce GUI.xs and GUI.pm to more manageable sizes.  I also want to 
experiment with moving a lot of the per-control methods from XS back 
into perl.  There are many methods implemented in XS that do a single 
call to SendMessage.  By moving them back into perl I don't think we'll 
see much of a performance hit (there's still one 'thunk' between perl 
and XS, which I suspect to be the largest time overhead), and will be 
able to move all such methods to be AUTOLOADed, so we only take compile 
time and memory hits if we use them in our apps.

> PS:
> Note that I did some wrong guards with the new NotifyIcon members.
> It should be compiler dependent and not IE dependent, when the shell
> version call will fail.

I haven't looked yet.  It's not really compiler dependent, but SDK 
version dependent.  I'm using VC6++ compiler on Win98, but with the 
latest SDK headers, and I don't get hit by any problems.  I may make it 
a requirement to have the lastest headers, so that I can remove much of 
the work-arounds from GUI.h (or perhaps just move it all to separate 
header files) ... something to think about in the future.

Regards,
Rob.

Re: [perl-win32-gui-hackers] DrapDrop support for Win32::GUI

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

Robert May schrieb:
> Reini Urban's patches have spurred me into digging out some work I was
> doing to integrate The GUI Loft's DragDrop.pm file into Win32::GUI
> proper.  There are some nice ideas from Reini that I would like to steal
> to enhance what I was doing.
> 
> Here's what I am proposing:
> 
> (1) All windows/controls will gain the -acceptfiles option that will be
> used to set/unset the WS_EX_ACCEPTFILES extended style on the
> window/control (For those of you familiar with it, this is all that the
> Win32 DrapAcceptFiles() API does). This is a minor change to
> GUI_Options.cpp, and improves on the original implementation that only
> supported dropping for Window/DialogBox.

Great!

> (2) All Windows/Controls will gain the AcceptFiles() method to get/set
> the WS_EX_ACCEPTFILES extended style.  Additionally, as this information
> is available from the extended style, no additional storage is needed to
> track a window's dragdrop state.

The only minor inconvenience is with the naming.
  DragDrop object
  -acceptfiles option
  DropFiles ( => WM_DROPFILES ) NEM or OEM eventname
  GetDroppedFiles() vs. DragQueryFile() methods

I'd rather prefer -dropfiles over -acceptfiles, so that the supported
event has the same name as the option which declares it.
On the other side, WS_EX_ACCEPTFILES and DrapAcceptFiles() is also
established on the API side.

> (2) The DropFiles callback which is already supported for all
> windows/controls (handling WM_DROPFILES) will change it's callback
> parameter from the current HDROP integer to a Win32::GUI::DropFiles
> object.  This is a minor change to GUI_MessageLoops.cpp
> 
> (3) The Win32::GUI::DropFiles object will expose the following methods:
> 
> - GetDroppedFiles, which will return:
>     in scalar context the number of files dropped

good.

>     in list context a list of dropped file names
> - GetDroppedFile, which will take a zero-based index for
>     the dropped file, and will return the file name

hmm.

> - GetDropPos, which will return:
>     in scalar context whether the drop was in the client or
>       non-client area of the window

Is this possible at all?

>     in list context the position of the mouse when the drop
>       occurred in client co-ordinates

> It should be possible to write GetDroppedFiles() so that code written to
> use the GUI Loft's GetDroppedFiles() method will continue to work,
> without modification.

That was my idea also.
The only problem is with the naming, DragQueryFile() vs GetDroppedFile()

It's only the Loft which introduced the name GetDroppedFiles().
WINAPI declares DragQueryFile and DragQueryPoint. I would like to stay
with the WINAPI names.

GetDropPos: Doesn't DragQueryPoint report the position
while being dragged also? So it's not only after being dropped.

The idea behind the high level GetDroppedFiles() is to automatically
cleanup the object. I'm not sure if this is a good idea, since perl
automatically will DESTROY the HDROP, and a DragQueryPoint afterward
will fail. So please back this idea out.

> (4) I intend to write all this as a separable module, with its own DLL
> for the new Win32 api calls required.  Whilst there is some overhead of
> this approach I want to use it as a proof of concept, as it gives the
> following advantages:
> - the code is separable, and hence more maintainable
> - there will be no overhead (in fact a saving) for applications that
> don't need the functionality (GUI.dll and GUI.pm are already way too big)

yep.

> - I believe that writing tests for smaller bits of functionality will
> prove significantly easier. (although I'm not sure this is a good example)
> - It will be possible to 'dual-life' modules like this, allowing for
> fixes/upgrades outside the normal Win32::GUI release cycle

Ok. I like that idea and I did this with CustomDraw.pm
The basic event and the object property getters do work without
use Win32::GUI::CustomDraw;
You only need to use it - and import a lot of autoloaded methods and
helper constants - if you want to call a method, primarly for setting a
value, and need some constants.

Maybe we should export the CustomDraw XS calls to a seperate DLL which
should be imported by the user or AUTOLOAD'ed.
But it's by far not that big as the convenience methods in the perl part.

For DragDrop:
The WM_DROPFILES event should work without use Win32::GUI::DragDrop;
But calling the methods might require it.
Or AUTOLOAD it based on the object name.
Same with the Brush and DC maybe.

> If it proves to be the wrong approach, then it will be easy to fold the
> changes back into the main GUI.xs and GUI.pm files.  If it proves good,
> the over time I hope to move other less used features out of GUI.pm and
> GUI.xs.
> 
> Additionally I want to look at putting more of the code than we might
> usually in perl rather than XS so that we can keep the DLL sizes small
> and (in the future) take better advantages of AUTOLOADing little used
> methods.

OwnerDraw, NotifyIcon and such.
Yes.

PS:
Note that I did some wrong guards with the new NotifyIcon members.
It should be compiler dependent and not IE dependent, when the shell
version call will fail.
-- 
Reini Urban
http://phpwiki.org/
http://helsinki.at/  http://spacemovie.mur.at/

[perl-win32-gui-hackers] Commit Frenzy

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

All,

It's been a busy day on the commit front.  Let me explain ...

This morning Jeremy committed a set of patches that Reini Urban 
submitted to the users list.  I then backed these changes out. I had a 
couple of motivations:

(1) I wanted the commits in smaller chunks, to reflect the (fairly 
major) bits of functionality Reini had provided.  There's a set of minor 
enhancements that I have already committed again, changes relating to 
shell DropDrop integration and changes related to Custom Draw support.

(2) Some of what Reini has done overlaps with work I already had in 
progress, and I want a chance to get the 2 bits of work merged before 
committing.

so, expect more activity over the next week or so.  I'm working towards 
a V1.04 release, which needs the following completing:

- completion and integration of my Win32::GUI::Constants work
- integration of my thread-safe support work (Win32::GUI::ThreaUtils)
- integration of Reini and my DragDrop support
- integration of Reini's CustomDraw support

Regards,
Rob.

[perl-win32-gui-hackers] DrapDrop support for Win32::GUI

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

Reini Urban's patches have spurred me into digging out some work I was 
doing to integrate The GUI Loft's DragDrop.pm file into Win32::GUI 
proper.  There are some nice ideas from Reini that I would like to steal 
to enhance what I was doing.

Here's what I am proposing:

(1) All windows/controls will gain the -acceptfiles option that will be 
used to set/unset the WS_EX_ACCEPTFILES extended style on the 
window/control (For those of you familiar with it, this is all that the 
Win32 DrapAcceptFiles() API does). This is a minor change to 
GUI_Options.cpp, and improves on the original implementation that only 
supported dropping for Window/DialogBox.

(2) All Windows/Controls will gain the AcceptFiles() method to get/set
the WS_EX_ACCEPTFILES extended style.  Additionally, as this information 
is available from the extended style, no additional storage is needed to 
track a window's dragdrop state.

(2) The DropFiles callback which is already supported for all 
windows/controls (handling WM_DROPFILES) will change it's callback 
parameter from the current HDROP integer to a Win32::GUI::DropFiles 
object.  This is a minor change to GUI_MessageLoops.cpp

(3) The Win32::GUI::DropFiles object will expose the following methods:

- GetDroppedFiles, which will return:
     in scalar context the number of files dropped
     in list context a list of dropped file names
- GetDroppedFile, which will take a zero-based index for
     the dropped file, and will return the file name
- GetDropPos, which will return:
     in scalar context whether the drop was in the client or
       non-client area of the window
     in list context the position of the mouse when the drop
       occurred in client co-ordinates

It should be possible to write GetDroppedFiles() so that code written to 
use the GUI Loft's GetDroppedFiles() method will continue to work, 
without modification.

(4) I intend to write all this as a separable module, with its own DLL 
for the new Win32 api calls required.  Whilst there is some overhead of 
this approach I want to use it as a proof of concept, as it gives the 
following advantages:
- the code is separable, and hence more maintainable
- there will be no overhead (in fact a saving) for applications that 
don't need the functionality (GUI.dll and GUI.pm are already way too big)
- I believe that writing tests for smaller bits of functionality will 
prove significantly easier. (although I'm not sure this is a good example)
- It will be possible to 'dual-life' modules like this, allowing for 
fixes/upgrades outside the normal Win32::GUI release cycle

If it proves to be the wrong approach, then it will be easy to fold the 
changes back into the main GUI.xs and GUI.pm files.  If it proves good, 
the over time I hope to move other less used features out of GUI.pm and 
GUI.xs.

Additionally I want to look at putting more of the code than we might 
usually in perl rather than XS so that we can keep the DLL sizes small 
and (in the future) take better advantages of AUTOLOADing little used 
methods.

Comments, as always, welcome.

Regards,
Rob.

Re: [perl-win32-gui-hackers] CustomDraw finished

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

The Custom Draw changes have been checked in.

Cheers,

jez.

Re: [perl-win32-gui-hackers] CustomDraw finished

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

I also find this GUI.xs method useful:
(place right after SetWindowLong)
    #######################################################################=
####
    # (@)METHOD:SetWindowPos(WINDOW,INSERTAFTER,X,Y,cx,cy,FLAGS)
    # The SetWindowPos function changes the size, position,
    # and Z order of a child, pop-up, or top-level
    # window. Child, pop-up, and top-level windows are
    # ordered according to their appearance on the
    # screen. The topmost window receives the highest rank
    # and is the first window in the Z order.
    #
    # INSERTAFTER - Handle to the window to precede the positioned window
    # in the Z order. This parameter must be a window handle
    # or one of the following integer values.
    #   HWND_BOTTOM
    #     Places the window at the bottom of the Z order. If
    #     the WINDOW parameter identifies a topmost window,
    #     the window loses its topmost status and is placed
    #     at the bottom of all other windows.
    #   HWND_NOTOPMOST
    #     Places the window above all non-topmost windows
    #     (that is, behind all topmost windows). This flag
    #     has no effect if the window is already a
    #     non-topmost window.
    #   HWND_TOP
    #     Places the window at the top of the Z order.
    #   HWND_TOPMOST
    #     Places the window above all non-topmost
    #     windows. The window maintains its topmost position
    #     even when it is deactivated.
BOOL
SetWindowPos(handle, insertafter =3D NULL, X =3D -1, Y =3D -1, cx =3D 0, cy=
 =3D
0, flags =3D (SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER |
SWP_FRAMECHANGED))
    HWND handle
    HWND insertafter
    int X
    int Y
    int cx
    int cy
    int flags
PREINIT:
    RECT myRect;
CODE:
    if ((X =3D=3D -1) || (Y =3D=3D -1)) {
      if(!GetWindowRect(handle, &myRect)) {
        XSRETURN_NO;
      } else {
=09if (Y =3D=3D -1)
=09  Y =3D (int) myRect.top;
=09if (X =3D=3D -1)
=09  X =3D (int) myRect.left;
      }
    }
    RETVAL =3D SetWindowPos(handle, insertafter, X, Y, cx, cy, flags);
OUTPUT:
    RETVAL


--
Reini Urban
http://phpwiki.org/
http://spacemovie.mur.at/   http://helsinki.at/