Menu
▾
▴
perl-win32-gui-hackers — Hacking and developing the Win32::GUI Perl extension
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(31) |
Dec
(80) |
| 2004 |
Jan
(30) |
Feb
(31) |
Mar
(46) |
Apr
(31) |
May
(48) |
Jun
(16) |
Jul
|
Aug
|
Sep
(20) |
Oct
(31) |
Nov
(13) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(7) |
Mar
|
Apr
(3) |
May
(1) |
Jun
(37) |
Jul
(39) |
Aug
(22) |
Sep
(3) |
Oct
(48) |
Nov
(24) |
Dec
(31) |
| 2006 |
Jan
(4) |
Feb
(6) |
Mar
(19) |
Apr
(17) |
May
(39) |
Jun
(62) |
Jul
(11) |
Aug
(21) |
Sep
(10) |
Oct
(26) |
Nov
(8) |
Dec
|
| 2007 |
Jan
(7) |
Feb
(6) |
Mar
(2) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2008 |
Jan
(19) |
Feb
(24) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert M. <rm...@po...> - 2005-06-26 18:14:16
|
OK, I have just committed a large set of changes to the documentation.
Hope it looks good to you all. I don't think that I've lost any of the
original content, but I think it is now a little better organised. I
also added some targets to the makefile (and some related scripts) to
generate all the docs for you:
make - (or make all) now generates the POD documentation in the blib/lib
directories, as well as performing the build.
make poddocs - makes the POD documentation in the blib/lib directories
make htmldocs - converts the pod to html in the blib/html directories
make ppm - does a make all, make htmldocs and make ppd, wrapping the
whole lot up in a PPM.zip ready for distribution.
CHANGELOG:
+ [Robert May] : Documentation re-work
- new documentation structure
- new build_tools directory with scripts for building the documentation
- additions to makefiles to build docs as part of a standard build
- removal of old, superceeded scripts
- addition of ppm target to makefiles, including building of HTML docs
- auto generation of Readme and Readme.html from
Win32::GUI::UserGuide::Readme POD
- upped version to 1.01_02
- tidied up MANIFEST.SKIP
- new MANIFEST to reflect changes
- added $Id$ ident to documentation files
There is more documentation about how it all works in
'docs/Documentation.txt'
Regards,
Rob.
Robert May wrote:
> All,
>
> As part of building the recent release candidates I have had to have a
> look at the documentation, and it's a bit of a mess. I propose to
> tidy it up.
>
> So that the source distribution results in good PPMs with all the
> documentation enclosed it is important that it is possible to run
> pod2html on the blib directory tree to generate the html pages. As I
> understand it this is exactly what make_ppm (see PPM::Make package
> from CPAN) does.
>
> So, I am proposing:
> (1) to throw away docs/dodoc and docs/dohtml, replacing them with a
> single tool in a new directory 'build_tools' called doPodDocs.pl that
> will
> - parse the XS/PM/CPP files extracting the documentation, and building
> the per-package POD documentation, and putting it in the correct
> location under blib.
> - copy any static POD content from the docs directory to the correct
> location under blib
> (2) to re-work the static content in the docs directory, as there is a
> lot of duplicated content currently, as well as a lot of content that
> really needs to be generated dynamically, but is not - more details
> below.
> (3) re-work the format of every page to be more pod2html friendly, and
> to get a better look with the ActiveState Perl CSS style sheet.
> (3) add a target to Makefile.PL that will result in building the POD
> documentation as part of the standard build process (nmake or nmake all).
> (4) adding a target to the makefile to allow the html to be generated
> (using pd2html)
> (5) adding a target to the makefile to build a PPM distribution
>
> I propose the following structure for the documentation:
>
> Win32/GUI.pod - introductory page, very similar to current one.
>
> Win32/GUI/*.pod - dynamically built documentation for each package
> (except Win32::GUI)
>
> Win32/GUI/UserGuide/Introduction.pod - introduction page
> Win32/GUI/UserGuide/Concepts.pod - general concepts page
> Win32/GUI/UserGuide/FAQ.pod - FAQ
>
> Win32/GUI/Tutorial.pod - contents page for the
> tutorials
> Win32/GUI/Tutorial/PartN - page for each part of
> the tutorial
>
> Win32/GUI/Reference/Packages.pod - dynamically generated list of
> packages
> Win32/GUI/Reference/Methods.pod - common methods - dynamic
> (documentation for Win32::GUI package)
> Win32/GUI/Reference/Events.pod - common events - dynamic:
> all events marked as APPLIES_TO:*
> Win32/GUI/Reference/Options.pod - static documentation of the
> common options
>
> In the longer term even the static POD documents need some type of
> simple templating to allow dates and version numbers to be updated
> automatically.
>
> I am starting work on this imminently, and would welcome feedback.
>
> Regards,
> Rob.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
>
|
|
From: Reini U. <ru...@x-...> - 2005-06-22 05:14:18
|
Robert May schrieb: > Reini Urban wrote: >> Jeremy White sagte: > [summary] MinGW build of Win32::GUI with ActiveState perl works with no > binary compatibility issues. >> >> Just a PAR from the PAR ppm does not work for Win32::GUI. >> You'd need to compile your own PAR from CPAN, esp. with the latest fixes. >> >> Cygwin Win32::GUI has a seperate package from cygwin's setup.exe >> maintained by me. It would be nice if the CPAN Win32::GUI would also >> contain these patches. > > If you have a set of Cygwin patches that you'd like to get into the main > source tree, then if you send them to me I'll look at doing that. The attached patch leads to the official CYGWIN version. Without the CYGWIN-PATCHES/README would be fine. I added the samples to our distro also. (I sent these last year, 2004-12-01) > I'm afraid that I don't understand your comments about PAR - I'm using > PAR fine with ActiveState Perl 5.8.6 and my MinGW built Win32::GUI. Hmm, I tried the old PAR.ppm from ActiveState and failed with certain calls: I'll sne detauls from my work address. Newer PAR's do work fine and also have the -gui switch for pp.bat -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Robert M. <rm...@po...> - 2005-06-20 18:29:47
|
Glenn Linderman wrote: [snipped conversation on the merits of MinGW, VC++ 6.0 and VC++ 7.0 (aka .net) > I believe there are some library changes and such that cause VC++ 6.0 > and 7.0 and .net to require different versions of the libraries... and > since ActiveState is compiled with 6.0 that it is best to compile XS > extensions with 6.0 rather than the newer compilers. Not that it > can't be made to work, I think, but that the footprint of required > libraries is larger. PAR-built applications could balloon in size, > for example, if built with multiple compilers. At least, that I how I > understand it. OK, there's an article discussing the VC 6/7 issues here: http://www.perlmonks.org/?node=Free%20MSVC%20tools%20%2B%20Activestate%20to%20compile%20CPAN%20Modules You need to be able to sort the wheat from the chaff, but I think the bottom line is that VC7 links against a new msvcr71.dll. As I see it this will have the following effects: (1) On a system with the new DLL it will load an extra DLL into memory. I may then still not work. (2) On a system without the new DLL it will fail to load. In either case this is not what we want, and so I think rules out this route. VC5 might be a possibility if there is a free download for that? I think this leaves us with either MinGW or VC6 for the release builds. I'm leaning towards VC6 for the size reasons (there seems to be suggestions that it is better, as ActiveState use it, but I have yet to see convincing arguments for this particular reason). Glenn, when we get to it I assume that you could do the perl 5.8 build. Do we have anyone with VC++ and perl 5.6 who can do the 5.6 build for us? If not we might have to go with MinGW for this? Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-19 22:44:30
|
Glenn Linderman wrote: > On approximately 6/19/2005 11:29 AM, came the following characters > from the keyboard of Robert May: > >> Glenn Linderman wrote: >> >>> Sorry, I was gone for a week or so. I have MS VC++ 6.0 and know how >>> to build the package, but not the whole process for release. Would >>> that still be helpful? (especially regarding the PAR issue?) I only >>> have Perl 5.8 installed though, and have never played with having >>> multiple Perls installed... I'd be willing to try installing 5.6 if >>> someone can show the way to do multiple Perls. >> >> I'm not really sure what difference using the VC complier makes vs. >> the MinGW one. I'm certainly happy about the binary compatibility >> issue, but size of the resulting binary may be the deciding factor. > > Me neither. I offered, because I (1) have VC++ 6.0 and (2) someone > mentioned some possible incompatibility with PAR and MinGW-built GUI. > I have no idea if this is an issue or not, but, I use PAR and GUI > together, so want it to keep working. I am having no troubles with my MinGW build and PAR. I asked for confirmation of the PAR issue on another thread - it may be cygwin related. >> I've got the current HEAD revision from CVS comming in at 979KB - >> perhaps you would be kind enough to do a build using VC and let us >> know the size of GUI.dll. > > OK, I did that.... > > 06/19/2005 02:21p 860,240 GUI.dll > 1 File(s) 860,240 bytes > > So it seems that VC++ is a little more compact for whatever reason. Indeed. I'm not sure what to make of that. >> In the mean time I'll go to the pain of downloading the SDK and >> commandline tools from micosoft, and installing them on a WIn2k >> system so that I can do that build too. > > Hmm. Is MS VC++ 6.0 available from MS as a download? I didn't think > they started that until VC++ 7.0 ... The .net command line tools (no IDE) are available for free download from microsoft at http://msdn.microsoft.com/visualc/vctoolkit2003/ Thanks for your assistance. Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-19 19:15:14
|
All, As part of building the recent release candidates I have had to have a look at the documentation, and it's a bit of a mess. I propose to tidy it up. So that the source distribution results in good PPMs with all the documentation enclosed it is important that it is possible to run pod2html on the blib directory tree to generate the html pages. As I understand it this is exactly what make_ppm (see PPM::Make package from CPAN) does. So, I am proposing: (1) to throw away docs/dodoc and docs/dohtml, replacing them with a single tool in a new directory 'build_tools' called doPodDocs.pl that will - parse the XS/PM/CPP files extracting the documentation, and building the per-package POD documentation, and putting it in the correct location under blib. - copy any static POD content from the docs directory to the correct location under blib (2) to re-work the static content in the docs directory, as there is a lot of duplicated content currently, as well as a lot of content that really needs to be generated dynamically, but is not - more details below. (3) re-work the format of every page to be more pod2html friendly, and to get a better look with the ActiveState Perl CSS style sheet. (3) add a target to Makefile.PL that will result in building the POD documentation as part of the standard build process (nmake or nmake all). (4) adding a target to the makefile to allow the html to be generated (using pd2html) (5) adding a target to the makefile to build a PPM distribution I propose the following structure for the documentation: Win32/GUI.pod - introductory page, very similar to current one. Win32/GUI/*.pod - dynamically built documentation for each package (except Win32::GUI) Win32/GUI/UserGuide/Introduction.pod - introduction page Win32/GUI/UserGuide/Concepts.pod - general concepts page Win32/GUI/UserGuide/FAQ.pod - FAQ Win32/GUI/Tutorial.pod - contents page for the tutorials Win32/GUI/Tutorial/PartN - page for each part of the tutorial Win32/GUI/Reference/Packages.pod - dynamically generated list of packages Win32/GUI/Reference/Methods.pod - common methods - dynamic (documentation for Win32::GUI package) Win32/GUI/Reference/Events.pod - common events - dynamic: all events marked as APPLIES_TO:* Win32/GUI/Reference/Options.pod - static documentation of the common options In the longer term even the static POD documents need some type of simple templating to allow dates and version numbers to be updated automatically. I am starting work on this imminently, and would welcome feedback. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-19 18:35:25
|
Reini Urban wrote: >Jeremy White sagte: > > [summary] MinGW build of Win32::GUI with ActiveState perl works with no binary compatibility issues. > >Just a PAR from the PAR ppm does not work for Win32::GUI. >You'd need to compile your own PAR from CPAN, esp. with the latest fixes. > >Cygwin Win32::GUI has a seperate package from cygwin's setup.exe >maintained by me. It would be nice if the CPAN Win32::GUI would also >contain these patches. > > Reini, If you have a set of Cygwin patches that you'd like to get into the main source tree, then if you send them to me I'll look at doing that. I'm afraid that I don't understand your comments about PAR - I'm using PAR fine with ActiveState Perl 5.8.6 and my MinGW built Win32::GUI. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-19 18:29:49
|
Glenn Linderman wrote: > Sorry, I was gone for a week or so. I have MS VC++ 6.0 and know how > to build the package, but not the whole process for release. Would > that still be helpful? (especially regarding the PAR issue?) I only > have Perl 5.8 installed though, and have never played with having > multiple Perls installed... I'd be willing to try installing 5.6 if > someone can show the way to do multiple Perls. Glenn, I'm not really sure what difference using the VC complier makes vs. the MinGW one. I'm certainly happy about the binary compatibility issue, but size of the resulting binary may be the deciding factor. I've got the current HEAD revision from CVS comming in at 979KB - perhaps you would be kind enough to do a build using VC and let us know the size of GUI.dll. In the mean time I'll go to the pain of downloading the SDK and commandline tools from micosoft, and installing them on a WIn2k system so that I can do that build too. Afraid that I can't help with multiple perls, as I've not had to try it yet. Regards, Rob. |
|
From: Robert M. <rm...@po...> - 2005-06-14 18:32:26
|
Robert May wrote: > OK. I've stuck up a PPM for ActiveState Perl 5.8 at > http://www.robmay.me.uk/win32gui/ Thanks to Jez White there's now a PPM for ActiveState Perl 5.6 at the same location. Regards, Rob. |
|
From: Jeremy W. <jez...@ho...> - 2005-06-14 07:36:24
|
>Is there anyone with a V5.6 Perl who would like to see if they can build a >corresponding release candidate? Yeah, I'll have a go:) Cheers, jez. |
|
From: Johan L. <jo...@Da...> - 2005-06-13 21:20:20
|
At 20:41 2005-06-13, Robert May wrote: >OK. I've stuck up a PPM for ActiveState Perl 5.8 at >http://www.robmay.me.uk/win32gui/ Well, at least I can confirm that the bug concerning me the most, Perl crashing, seems to be fixed. /J |
|
From: Robert M. <rm...@po...> - 2005-06-13 18:41:40
|
OK. I've stuck up a PPM for ActiveState Perl 5.8 at http://www.robmay.me.uk/win32gui/ It's a build from today's CVS head revision, after I checked in the last few fixes I had in my local repository. I made the following changes before building: - GUI.pm - changed $VERSION to be '1.01_01' (i.e. v1.01 release candidate 1) - GUI.pm - added line $VERSION = eval $VERSION; (see perldoc perlmodstyle) - README.TXT - added some works on installing using PPM and set version/dates For anyone interested, the build steps I took are below. Is there anyone with a V5.6 Perl who would like to see if they can build a corresponding release candidate? Regards, Rob. (1) Create the MinGW Makefile: perl Makefile_m.pl BINARY_LOCATION=Win32-GUI.tar.gz (BINARY_LOCATION is used as the HREF field for CODEBASE in the PPD file) (2) Modify the Makefile to get GUI.ddl size down: (a) remove -g from LDDLFLAGS (b) remove -g -O2 from CCFLAGS (c) change -O2 to -Os in OPTIMIZE (3) Make nmake (4) Create the documentation: cd docs perl dodoc.pl perl dohtml.pl cd .. (5) Copy the html docs to the build tree: mkdir blib\html mkdir blib\html\site mkdir blib\html\site\lib mkdir blib\html\site\lib\Win32 mkdir blib\html\site\lib\Win32\GUI copy docs\html\*.html blib\html\site\lib\Win32\GUI (6) Copy the samples to the build tree mkdir blib\lib\Win32\GUI\demos copy samples\* blib\lib\Win32\GUI\demos (7) create the PPD file nmake ppd (8) Create the distribution tar cvf Win32-GUI.tar blib gzip -9 Win32-GUI.tar (9) Create the Win32::GUI PPM file mkdir Win32-GUI-1.01RC1-PPM-5.8 move Win32-GUI.tar.gz Win32-GUI-1.01RC1-PPM-5.8 move Win32-GUI.ppd Win32-GUI-1.01RC1-PPM-5.8 copy CHANGELOG Win32-GUI-1.01RC1-PPM-5.8\CHANGELOG.TXT copy README.txt Win32-GUI-1.01RC1-PPM-5.8\README.TXT zip -r9 Win32-GUI-1.01RC1-PPM-5.8.zip Win32-GUI-1.01RC1-PPM-5.8 |
|
From: Robert M. <rm...@po...> - 2005-06-13 17:42:37
|
I've just committed a couple of fixes:
+ [Robert May] :
- Label.xs: Tracker 1164780: fix to -bitmap option for labels
+ Fixed test for icon/bitmap in Label_onPostCreate
- Richedit.xs:
+ Minor documentation changes
- docs/dohtml.pl:
+ change to CSS path for correct install location
.../html/site/lib/Win32/GUI
Regards,
Rob.
|
|
From: Reini U. <ru...@x-...> - 2005-06-13 17:40:32
|
Jeremy White sagte: >>Regarding that old binary compatibility thing: would a PPM built with >>MinGW work with ActiveState Perl, or only under Cygwin? > > Yes it would work with ActiveState Perl (there should be no compatibili= ty > issues). I've been using PerlApp with MinGW built modules for a while n= ow > (including win32-gui) with no problems. Just a PAR from the PAR ppm does not work for Win32::GUI. You'd need to compile your own PAR from CPAN, esp. with the latest fixes. Cygwin Win32::GUI has a seperate package from cygwin's setup.exe maintained by me. It would be nice if the CPAN Win32::GUI would also contain these patches. |
|
From: Jeremy W. <jez...@ho...> - 2005-06-13 08:30:41
|
>Regarding that old binary compatibility thing: would a PPM built with MinGW >work with ActiveState Perl, or only under Cygwin? Yes it would work with ActiveState Perl (there should be no compatibility issues). I've been using PerlApp with MinGW built modules for a while now (including win32-gui) with no problems. Cheers, jez. |
|
From: Johan L. <jo...@Da...> - 2005-06-13 08:01:02
|
At 18:45 2005-06-12, Robert May wrote: >I was going to mail you off-list, as I was playing with the MinGW build >last week to try to get the size down, and I succeeded in reducing the >size of my GUI.dll for the current head build from 3104 KB down to 979 KB >(which is only 100k or so bigger than the VC build of the 1.0 source). Regarding that old binary compatibility thing: would a PPM built with MinGW work with ActiveState Perl, or only under Cygwin? /J -------- ------ ---- --- -- -- -- - - - - - Johan Lindström Sourcerer @ Boss Casinos johanl AT DarSerMan.com Latest bookmark: "TCP Connection Passing" http://tcpcp.sourceforge.net/ dmoz: /Computers/Programming/Languages/JavaScript/ 12 |
|
From: Jeremy W. <jez...@ho...> - 2005-06-13 07:52:29
|
>We need to agree a version number for the next release. I would propose >1.01 - I think that we should be using a 2-digit second part of the version >number to be CPAN friendly (See perldoc perlmodstyle), and don't see that >there's enough change to justify anything other than incrementing the minor >version by the smallest increment. 1.01 sounds fine by me. >If we can agree the version numbering issue,. I'd be happy to make a >release candidate available from my website. Cool:) >I'll also write up my notes on building the PPM, so others can do it. I've >added a note to my TODO list to look at adding a PPM target to the makefile >(so we can just do nmake ppm (or whatever). I've also noticed that many of >the document links with a page are broken, but don't have time to explore >this further right now. I've noticed these broken links before, and have tried to fix a few of them when updating documentation. I suspect that the document parser could be improved a little to cope with the differing styles of text - it's a rather manual process otherwise. Cheers, jez. |
|
From: Robert M. <rm...@po...> - 2005-06-12 22:21:33
|
> To create the HTML docs, I run: > > perl dodoc.pl > perl dohtml.pl > > in Win32-GUI\docs directory - although I've no idea how these files > would be included in the PPM:) > Thanks - I was a bit confused by the fact that dodoc.pl seems to have options for building html too. I've got a PPM built from my local source, and I've made the following changes to what seems to have been done before: (1) Moved document install from C:\Perl\html\lib\Win32\GUI to C:\Perl\html\site\lib\Win32\GUI. I believe that this is the correct place to install the html files, and results in other documentation generated with pod2html linking to the right pages. (2) Add the contents of the CVS samples directory to C:\Perl\site\lib\Win32\GUI\demos (i.e. in a sub directory of the install location, in a directory called demos.) This is consistent with what the Tk package does, but I'd be happy to call it samples if that's the general consensus. (3) I've added some notes on performing a PPM installation into the Readme.txt file We need to agree a version number for the next release. I would propose 1.01 - I think that we should be using a 2-digit second part of the version number to be CPAN friendly (See perldoc perlmodstyle), and don't see that there's enough change to justify anything other than incrementing the minor version by the smallest increment. If we can agree the version numbering issue,. I'd be happy to make a release candidate available from my website. I'll also write up my notes on building the PPM, so others can do it. I've added a note to my TODO list to look at adding a PPM target to the makefile (so we can just do nmake ppm (or whatever). I've also noticed that many of the document links with a page are broken, but don't have time to explore this further right now. Regards, Rob. |
|
From: Jeremy W. <jez...@ho...> - 2005-06-12 20:07:25
|
>I did the following to my Makefile: >(1) remove -g from LDDLFLAGS >(2) remove -g -O2 from CCFLAGS >(3) change -O2 to -Os in OPTIMIZE > >The '-g' is the biggest culprit, which adds huge amounts of extra stuff to >allow debuggers (and particularly gdb) to run well with the code. The >'-Os' optimises for size (it's nearly the same as -O2 according to the >docs), and shaves around 200KB off the size compared to '-O2' Nice. I'll have a play with these options. >If someone can explain to me how to build the documentation, then I'd be >happy to put together a release candidate. (I've also got a couple more bug >fixes that are not currently checked in). To create the HTML docs, I run: perl dodoc.pl perl dohtml.pl in Win32-GUI\docs directory - although I've no idea how these files would be included in the PPM:) Cheers, jez. |
|
From: Robert M. <rm...@po...> - 2005-06-12 16:45:32
|
Jez, I was going to mail you off-list, as I was playing with the MinGW build last week to try to get the size down, and I succeeded in reducing the size of my GUI.dll for the current head build from 3104 KB down to 979 KB (which is only 100k or so bigger than the VC build of the 1.0 source). I did the following to my Makefile: (1) remove -g from LDDLFLAGS (2) remove -g -O2 from CCFLAGS (3) change -O2 to -Os in OPTIMIZE The '-g' is the biggest culprit, which adds huge amounts of extra stuff to allow debuggers (and particularly gdb) to run well with the code. The '-Os' optimises for size (it's nearly the same as -O2 according to the docs), and shaves around 200KB off the size compared to '-O2' I suspect that it might be better to change these values in Comfig_m.pm, as then you'd get the benefit for any other perl modules that you build. If someone can explain to me how to build the documentation, then I'd be happy to put together a release candidate. (I've also got a couple more bug fixes that are not currently checked in). Regards, Rob. Jeremy White wrote: >> In short, can we please release a new version of Win32::GUI in the >> near future? I would be happy to test a release candidate to make >> sure it works with TGL. > > > I dropped a mail to Laurent to see if he could do a build a week or so > ago - but no reply. Mingw produces larger dll files than the MS > compiler that Laurent uses, but I'm sure Rob or myself could put a > build together using Mingw? > > Cheers, > > jez. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. Play > to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers > |
|
From: Jeremy W. <jez...@ho...> - 2005-06-11 11:30:37
|
>In short, can we please release a new version of Win32::GUI in the near >future? I would be happy to test a release candidate to make sure it works >with TGL. I dropped a mail to Laurent to see if he could do a build a week or so ago - but no reply. Mingw produces larger dll files than the MS compiler that Laurent uses, but I'm sure Rob or myself could put a build together using Mingw? Cheers, jez. |
|
From: Johan L. <jo...@Da...> - 2005-06-11 10:59:20
|
At 21:10 2005-05-25, Robert May wrote: >Jez White has kindly committed a set of changes that have been >accumulating in my workspace. Details below: I will post a further >message (to the users list only) about the Coolmenu changes mentioned below. -snip- > - GUI.pm (Fix for Richedit crash. Tracker: 1064828, 1153899) > + Moved LoadLibrary for richedit.dll to constructor to prevent > loading library unnecessarily > + Removed end block to FreeLibrary*(), as not necessary (and can get > executed before Richedit's DESTROY method) This RichEdit bug is very severe and is annoying a whole bunch of people, not the least on the TGL mailing list. Now I've tried three times to work _around_ this bug so I can make a release with a working RichEdit control, but the behaviour is truly bizarre, and I haven't suceeded (things don't behave the same for simple examples as from within TGL). In short, can we please release a new version of Win32::GUI in the near future? I would be happy to test a release candidate to make sure it works with TGL. /J |
|
From: Robert M. <rm...@po...> - 2005-05-25 19:10:47
|
All,
Jez White has kindly committed a set of changes that have been
accumulating in my workspace. Details below: I will post a further
message (to the users list only) about the Coolmenu changes mentioned below.
+ [Robert May] : Fixes for Toolbars:
- Toolbar.xs:
+ Fixed message processing to switch on lparam->code, rather than
HIWORD(wparam)
+ Various documentation changes where functions take command
identifier, rather than button index
+ Fixed GetButtonInfo test for error conditions
+ Fixed GetButtonInfo returned flags to be 0 or 1 only.
+ Added missing GetString method
+ Fixed SetButtonInfo to set required cbsize element of button
structure.
- GUI.h
+ Added define for TB_GETSTRING for MinGW.
+ [Robert May] : Support for Coolmenu
- GUI.h
+ Added prototyle for ProcessEventError so it can be called from
GUI_Helpers.cpp
+ Added 'message' WM_TRACKPOPUP_MSGHOOK to use as a callback
handle in the hooks array (see TrackPopupMenu, GUI.xs)
- GUI_Helpers.cpp
+ Added WindowsHookMsgProc callback to be used by SetWindowsHookEx
in TrackPopupMenu (GUI.xs)
- GUI.xs
+ Re-worked TrackPopupMenu to:
(1) allow X,Y to be optional, and use current cursor position if
not provided.
(2) use TrackPopupMenuEx, rather than TrackPopupMenu, and allow
an (optional) excluded rectangle to be provided
(3) to allow a (optional) code reference to a callback funtion
to be provided that will be called for events
occuring while the menu is displayed.
+ Added RemoveMenu() to Win32::GUI::Menu
+ [Robert May] : Support for chevrons in rebars
- GUI.h
+ Added define for RBN_CHEVRONPUSHED for MinGW.
- GUI_Options.cpp:
+ Added -idealwidth to ParseRebarBandOptions
- Rebar.xs
+ Added ChevronPushed event: Rebar_onParseEvent, Rebar_onEvent
+ Added -idealwidth to GetBandInfo, InsertBand, and SetBandInfo
(via ParseRebarBandOptions), including documentation
+ Documented RBBS_USECHEVRON style
+ [Robert May] :
- GUI_MessageLoops.cpp
+ Fixed second parameter to DoHook() during WM_NOTIFY messages to
be lparam->code, rather than HIWORD(wparam).
+ [Robert May] :
- GUI.pm (Fix for Richedit crash. Tracker: 1064828, 1153899)
+ Moved LoadLibrary for richedit.dll to constructor to prevent
loading library unnecessarily
+ Removed end block to FreeLibrary*(), as not necessary (and can
get executed before Richedit's DESTROY method)
+ [Robert May] :
- Trackbar.xs
+ Modifed Pos() to get one argument call have correct default for
second argument.
+ Modifed Min() to get one argument call have correct default for
second argument.
+ Modifed Max() to get one argument call have correct default for
second argument.
+ Modifed SelStart() to get one argument call have correct default
for second argument.
+ Modifed SelEnd() to get one argument call have correct default
for second argument.
Regards,
Rob.
|
|
From: Jez W. <je...@je...> - 2005-04-30 12:53:04
|
+ Added SetWindowRgn method
- DC.xs=20
+ Added CombineRgn method
Cheers,
jez. |
|
From: Jez W. <je...@je...> - 2005-04-06 07:37:14
|
All, I've just committed Alexander Romanenko's changes to the GridLayout = object.=20 Cheers, jez. |
|
From: Alexander R. <al...@pa...> - 2005-04-02 18:31:41
|
Hello,
I have corrected and have modified module GridLayout.pm.
Now cells of a grid can have absolute and relative size. Controls can
be expanded (justify) on some cells. The module supports old job, but
methods apply() and add() can be called with new parameters.
Please, check up correctness of job and the documentation. If all is
correct, change the version and publish it.
--------------------------------------------------------------------
package Win32::GUI::GridLayout;
$VERSION = "0.03";
sub new {
my($class, $c, $r, $w, $h, $xpad, $ypad) = @_;
my $r_grid = {
"cols" => $c,
"rows" => $r,
"width" => $w,
"height" => $h,
"xPad" => $xpad,
"yPad" => $ypad,
};
bless $r_grid, $class;
return $r_grid;
}
sub apply {
my($class, $to, $c, $r, $xpad, $ypad) = @_;
my $w = $to->ScaleWidth();
my $h = $to->ScaleHeight();
my $r_grid = {
"cols" => $c,
"rows" => $r,
"width" => $w,
"height" => $h,
"xPad" => $xpad,
"yPad" => $ypad,
"source" => $to,
};
bless $r_grid, $class;
return $r_grid;
}
sub add {
my($grid, $o, $c, $r, $align) = @_;
my @content = @{$grid->{'content'}};
my($halign, $valign) = split(/\s*,\s*|\s+/, $align);
push(@content, [$o, $c, $r, $halign, $valign] );
$grid->{'content'} = [ @content ];
}
sub recalc {
my($grid) = @_;
$grid->{'width'} = $grid->{'source'}->ScaleWidth();
$grid->{'height'} = $grid->{'source'}->ScaleHeight();
if(ref $grid->{'cols'} eq 'ARRAY') {
my @colw = @{$grid->{'cols'}};
my @absw = grep(/^\d+$/, @colw);
my $absw = 0;
map($absw+=$_, @absw);
my $relw = int(($grid->{'width'}-$absw)/($#colw-$#absw));
for my $i (0..$#colw) {
$grid->{'_cols_w'}[$i] = ($colw[$i] eq '*') ? $relw : $colw[$i];
}
}
else {
my $relw = int($grid->{'width'}/$grid->{'cols'});
for my $i (0..($grid->{'cols'}-1)) {
$grid->{'_cols_w'}[$i] = $relw;
}
}
if(ref $grid->{'rows'} eq 'ARRAY') {
my @rowh = @{$grid->{'rows'}};
my @absh = grep(/^\d+$/, @rowh);
my $absh = 0;
map($absh+=$_, @absh);
my $relh = int(($grid->{'height'}-$absh)/($#rowh-$#absh));
for my $i (0..$#rowh) {
$grid->{'_rows_h'}[$i] = ($rowh[$i] eq '*') ? $relh : $rowh[$i];
}
}
else {
my $relh = int($grid->{'height'}/$grid->{'rows'});
for my $i (0..($grid->{'rows'}-1)) {
$grid->{'_rows_h'}[$i] = $relh;
}
}
foreach $inside (@{$grid->{'content'}}) {
$widgetWidth = $inside->[0]->Width();
$widgetHeight = $inside->[0]->Height();
if($inside->[3] =~ /^j/i) {
$inside->[0]->Resize(
$grid->col_w($inside->[1]),
$inside->[0]->Height,
);
}
if($inside->[4] =~ /^j/i) {
$inside->[0]->Resize(
$inside->[0]->Width,
$grid->row_h($inside->[2]),
);
}
$inside->[0]->Move(
$grid->col($inside->[1], $inside->[3]),
$grid->row($inside->[2], $inside->[4]),
);
}
}
sub draw {
my($grid) = @_;
return undef unless $grid->{'source'};
my $DC = $grid->{'source'}->GetDC();
my $colWidth = int($grid->{'width'} / $grid->{'cols'});
my $rowHeight = int($grid->{'height'} / $grid->{'rows'});
my($i, $s);
$s = 0;
for $i (@{$grid->{'_cols_w'}}) {
$s += $i;
$DC->MoveTo($s, 0);
$DC->LineTo($s, $grid->{'height'});
}
$s = 0;
for $i (@{$grid->{'_rows_h'}}) {
$s += $i;
$DC->MoveTo(0, $s);
$DC->LineTo($grid->{'width'}, $s);
}
}
sub column {
my($grid_param, $col, $align) = @_;
$col = $col->[0] if(ref $col);
$col--;
my $x = 0;
if($grid_param->{'_cols_w'}) {
my @colw = @{$grid_param->{'_cols_w'}};
$colWidth = $colw[$col];
for(my $i=0; $i<=$col-1; $i++) {
$x += $colw[$i];
}
$x += $grid_param->{'xPad'};
}
else {
$colWidth = int($grid_param->{'width'} / $grid_param->{'cols'});
$x = ($col * $colWidth) + ($grid_param->{'xPad'});
}
$x += int(($colWidth - $widgetWidth) / 2)
if $align =~ /^c/i;
$x += ($colWidth - $widgetWidth) - 2*$grid_param->{'xPad'}
if $align =~ /^r/i;
$widgetWidth=0; # in case a width declaration is missed or not used
return $x;
}
sub col { column @_; }
sub row {
my($grid_param, $row, $align) = @_;
$row = $row->[0] if(ref $row);
$row--;
my $y = 0;
if($grid_param->{'_rows_h'}) {
my @rowh = @{$grid_param->{'_rows_h'}};
$rowHeight = $rowh[$row];
for(my $i=0; $i<=$row-1; $i++) {
$y += $rowh[$i];
}
$y += $grid_param->{'yPad'};
}
else {
$rowHeight = int($grid_param->{'height'} / $grid_param->{'rows'});
$y = ($row * $rowHeight) + ($grid_param->{'yPad'});
}
$y += int(($rowHeight - $widgetHeight) / 2)
if $align =~ /^c/i;
$y += ($rowHeight - $widgetHeight) - 2*$grid_param->{'yPad'}
if $align =~ /^b/i;
$widgetHeight=0; # same reason as coment in &column
return $y;
}
sub width {
my ($grid_param,$w) = @_;
$widgetWidth = $w;
return $widgetWidth;
}
sub height {
my ($grid_param,$h) = @_;
$widgetHeight = $h;
return $widgetHeight;
}
sub col_w {
my($grid_param, $col) = @_;
$col->[0] = $col unless(ref $col);
my $w = 0;
for my $col (@$col) {
$w += $grid_param->{'_cols_w'}[$col-1];
}
$w -= 2*$grid_param->{'xPad'};
return $w;
}
sub row_h {
my($grid_param, $row) = @_;
$row->[0] = $row unless(ref $row);
my $h = 0;
for my $row (@$row) {
$h += $grid_param->{'_rows_h'}[$row-1];
}
$h -= 2*$grid_param->{'yPad'};
return $h;
}
1;
__END__
=head1 NAME
Win32::GUI::GridLayout - Grid layout support for Win32::GUI
=head1 SYNOPSIS
use Win32::GUI::
use Win32::GUI::GridLayout;
# 1. make a "static" grid
$grid = new Win32::GUI::GridLayout(400, 300, 3, 3, 0, 0);
$win = new Win32::GUI::Window(
$win->AddLabel(
-name => "label1",
-text => "Label 1",
-width => $grid->width(35),
-height => $grid->height(11),
-left => $grid->col(1, "left"),
-top => $grid->row(1, "top"),
);
# 2. make a "dynamic" grid
$grid = apply Win32::GUI::GridLayout($win, 3, 3, 0, 0);
or
$grid = apply Win32::GUI::GridLayout($win,
[qw(10 * * 10)],
[qw(10 * 40)],
0, 0);
$win->AddLabel(
-name => "label1",
-text => "Label 1",
);
$grid->add($win->label1, 1, 1, "left top");
or
$grid->add($win->label1, [2..3], 1, "justify justify");
$grid->recalc();
=head1 DESCRIPTION
=head2 Constructors
=over 4
=item new Win32::GUI::GridLayout(WIDTH, HEIGHT, COLS, ROWS, XPAD, YPAD)
=item apply Win32::GUI::GridLayout(WINDOW, COLS, ROWS, XPAD, YPAD),
COLS - quantity of columns or arrayref of width colomns (number - absolute width,
* - relative width),
ROWS - quantity of rows or arrayref of height rows (number - absolute height,
* - relative height)
=back
=head2 Methods
=over 4
=item add(CONTROL, COL, ROW, ALIGN)
Adds CONTROL to the grid at (COL, ROW).
ALIGN can specify both horizontal and vertical
alignment (see the col() and row() methods),
separated by at least one blank and/or a comma.
Example:
$grid->add($win->label1, 1, 1, "left top");
or
$grid->add($win->label1, [2..3], 1, "justify top");
COL and ROW may be arrayref for adds CONTROL into more than one cell.
If ALIGN is justify (j) than CONTROL expands up to cell.
=item col(N, ALIGN)
Positions the control at the Nth column in the grid,
optionally with an ALIGN; this can be feed to a
C<-left> option when creating a control.
ALIGN can be C<left>, C<center> or C<right> (can be
shortened to C<l>, C<c>, C<r>); default is C<left>.
Note that for alignment to work properly, the width()
and height() methods must have been previously
called.
Example:
$win->AddLabel(
-name => "label1",
-text => "Label 1",
-width => $grid->width(35),
-height => $grid->height(11),
-left => $grid->col(1, "left"),
-top => $grid->row(1, "top"),
);
=item draw()
Draws the GridLayout in the associated window
(may be useful for debugging); is only meaningful
if the GridLayout was created with the apply()
constructor.
=item height(N)
Sets the height of the control for subsequent
alignment; this can be feed to a C<-height> option
when creating a control.
Example: see col().
=item recalc()
Recalculates the grid and repositions all the add()ed
controls, taking into account the actual window and
controls sizes;
is only meaningful if the GridLayout was created
with the apply() constructor.
Example:
sub Window_Resize {
$grid->recalc();
}
=item row(N, ALIGN)
Positions the control at the Nth row in the grid,
optionally with an ALIGN; this can be feed to a
C<-top> option when creating a control.
ALIGN can be C<top>, C<center> or C<bottom> (can be
shortened to t, c, b); default is top.
Note that for alignment to work properly, the width()
and height() methods must have been previously
called.
Example: see col().
=item width(N)
Sets the width of the control for subsequent
alignment; this can be feed to a C<-width> option
when creating a control.
Example: see col().
=back
=head1 VERSION
Win32::GUI::GridLayout version 0.03, 13 April 1999.
=head1 AUTHOR
Mike Kangas ( C<ka...@an...> );
additional coding by Aldo Calpini ( C<da...@pe...> ).
=cut
|
18 messages has been excluded from this view by a project administrator.
