Menu
▾
▴
perl-win32-gui-hackers
|
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: Johan L. <johanl@DarSerMan.com> - 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: 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: 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-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 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-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: Johan L. <johanl@DarSerMan.com> - 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 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: 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: 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: Reini U. <ru...@x-...> - 2005-06-22 05:14:18
Attachments:
perl-Win32-GUI-1.0-2.patch
|
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-28 00:00:33
|
All, I have a small number of items that I wish to conclude before a v1.01 release: (1) Merging Reini's cygwin fixes - the changes are small, and really shouldn't bother anyone. I have most of them merged in my local workspace, and no problems with either the MinGW or VC++ builds yet. (2) reverting to a single Makefile. I propose to merge the Makefile.PL and Makefile_m.PL files to get us to a stage where the build procedure is the same for all platforms. Anyone who has downloaded the documentation change that I made may have discovered that I got a bit ahead of myself here, and the build instructions in the Readme file already assume that this has happened. I propose to keep Makefile_m.PL that will simply call the real Makefile.PL, having added '-MConfig_m' to the command line, so that those of you with an ingrained methodology will keep on working fine. Assuming the I get responses from Reini regarding the small number of questions I have about his patches quickly, then I think that we'll be ready for a V1.01 release in about a week's time. I'll solicit further feedback from the users group, but given the current level of response (zero from 15 or so downloads) I'm not sure whether an RC2 release serves any purpose ... comments? Thanks to everyone who has made comments and given help so far. Regards, Rob. |
|
From: Reini U. <ru...@x-...> - 2005-06-28 06:28:07
|
Robert May schrieb: > I have a small number of items that I wish to conclude before a v1.01 > release: > > (1) Merging Reini's cygwin fixes - the changes are small, and really > shouldn't bother anyone. I have most of them merged in my local > workspace, and no problems with either the MinGW or VC++ builds yet. Thanks. I'll get back to you in the afternoon with my comments and counter tests. > (2) reverting to a single Makefile. I propose to merge the Makefile.PL > and Makefile_m.PL files to get us to a stage where the build procedure > is the same for all platforms. Anyone who has downloaded the > documentation change that I made may have discovered that I got a bit > ahead of myself here, and the build instructions in the Readme file > already assume that this has happened. I propose to keep Makefile_m.PL > that will simply call the real Makefile.PL, having added '-MConfig_m' to > the command line, so that those of you with an ingrained methodology > will keep on working fine. > > Assuming the I get responses from Reini regarding the small number of > questions I have about his patches quickly, then I think that we'll be > ready for a V1.01 release in about a week's time. I'll solicit further > feedback from the users group, but given the current level of response > (zero from 15 or so downloads) I'm not sure whether an RC2 release > serves any purpose ... comments? > > Thanks to everyone who has made comments and given help so far. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Jeremy W. <jez...@ho...> - 2005-06-28 07:38:15
|
>Assuming the I get responses from Reini regarding the small number of >questions I have about his patches quickly, then I think that we'll be >ready for a V1.01 release in about a week's time. I'll solicit further >feedback from the users group, but given the current level of response >(zero from 15 or so downloads) I'm not sure whether an RC2 release serves >any purpose ... comments? With only 15 download, then it's probably not worth having a RC2. If there are any problems, then they can be fixed quickly. Cheers, jez. |
|
From: Robert M. <rm...@po...> - 2005-06-28 21:16:41
|
Jeremy White wrote: >> Assuming the I get responses from Reini regarding the small number of >> questions I have about his patches quickly, then I think that we'll >> be ready for a V1.01 release in about a week's time. I'll solicit >> further feedback from the users group, but given the current level of >> response (zero from 15 or so downloads) I'm not sure whether an RC2 >> release serves any purpose ... comments? > > With only 15 download, then it's probably not worth having a RC2. If > there are any problems, then they can be fixed quickly. OK, I think I agree. No RC2 PPM distribution. But, I have just rolled Reini's cygwin changes into my local build, and merged Makefile_m.pl and Makefile.PL (this was easier than I expected, really not much different), and I'd like to ensure that it still builds in everyone's environments before we go for a release. I'm waiting for feedback from Reini before I check the changes into CVS. If you'd like a heads up, there's a snapshot of my working copy source at http://robmay.me.uk/win32gui/. If you do download and compile it, then feedback (as always) appreciated. Please include perl version and compiler type/versions. Thanks, Rob. |
|
From: Johan L. <johanl@DarSerMan.com> - 2005-06-28 22:16:52
|
At 23:15 2005-06-28, Robert May wrote: >I'm waiting for feedback from Reini before I check the changes into >CVS. If you'd like a heads up, there's a snapshot of my working copy >source at http://robmay.me.uk/win32gui/. If you do download and compile >it, then feedback (as always) appreciated. Please include perl version >and compiler type/versions. 403 Forbidden. I'm planning on trying it with MSVC++ 6 if I get the time. And RC1 worked fine btw, the little I tried. We really need a decent test suite, at the very least a sanity check. /J |
|
From: Reini U. <ru...@x-...> - 2005-06-29 05:04:06
|
Johan Lindström schrieb: > At 23:15 2005-06-28, Robert May wrote: > And RC1 worked fine btw, the little I tried. We really need a decent > test suite, at the very least a sanity check. I'll think of one. There are enough samples, which could be automated with one of the available GUI testers. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Robert M. <rm...@po...> - 2005-06-28 23:12:39
|
Johan Lindstr=F6m wrote: > At 23:15 2005-06-28, Robert May wrote: > >> I'm waiting for feedback from Reini before I check the changes into=20 >> CVS. If you'd like a heads up, there's a snapshot of my working copy=20 >> source at http://robmay.me.uk/win32gui/. If you do download and=20 >> compile it, then feedback (as always) appreciated. Please include=20 >> perl version and compiler type/versions. > > 403 Forbidden. No idea what was going on. There seems to be something a bit=20 intermittent since lunchtime today, but it seems to be OK again now. =20 Let me know if you continue to have problems. > I'm planning on trying it with MSVC++ 6 if I get the time. That would be great. > And RC1 worked fine btw, the little I tried. We really need a decent=20 > test suite, at the very least a sanity check. It's on my list, but it's such a huge task that until I get some time to=20 think about it I don't really even know where to start. I think that a=20 sanity check is a more likely short-term goal. Is it something that=20 you've given any though to? Rob. |
|
From: Reini U. <ru...@x-...> - 2005-06-29 05:02:41
|
Robert May schrieb: > Johan Lindström wrote: >> At 23:15 2005-06-28, Robert May wrote: >>> I'm waiting for feedback from Reini before I check the changes into >>> CVS. If you'd like a heads up, there's a snapshot of my working copy >>> source at http://robmay.me.uk/win32gui/. If you do download and >>> compile it, then feedback (as always) appreciated. Please include >>> perl version and compiler type/versions. >> >> >> 403 Forbidden. > > No idea what was going on. There seems to be something a bit > intermittent since lunchtime today, but it seems to be OK again now. > Let me know if you continue to have problems. Again 403 Forbidden. |
|
From: Johan L. <johanl@DarSerMan.com> - 2005-06-29 06:34:35
|
At 01:12 2005-06-29, Robert May wrote: >It's on my list, but it's such a huge task that until I get some time to >think about it I don't really even know where to start. I think that a >sanity check is a more likely short-term goal. Is it something that >you've given any though to? Well, the first test is to just create each control and see that it doesn't blow up today either. Like the RichEdit, we did a really bad QA job there :) I've done that as a regression test in TGL. Then everything that's a bug gets a test so it doesn't come back. /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: Reini U. <ru...@x-...> - 2005-06-29 07:40:04
|
Please file some of the admins a sf.net "Project CVS Services" request. MM complains about that. http://sourceforge.net/tracker/?func=3Dadd&group_id=3D1&atid=3D200001 Category: Project CVS Services Subject: cvs file rename: perl-win32-gui Please: mv perl-win32-gui/Win32-GUI/ToolTip.xs perl-win32-gui/Win32-GUI/Tooltip.x= s |
|
From: Robert M. <rm...@po...> - 2005-06-30 23:01:36
|
Robert May wrote: > I have a small number of items that I wish to conclude before a v1.01 > release: > > (1) Merging Reini's cygwin fixes > (2) reverting to a single Makefile. I just checked in a somewhat larger set of changes than I was anticipating. Most of the changes are in GUI.h and Makefile.PL. I would very much appreciate feedback on whether I've broken the build process for anyone or not. The main points: - now builds from CVS in a cygwin environment (although in my tests, there are still a lot of compiler warnings for casts that the compiler considers iffy) - Makefile.PL and Makefile_m.pl have been merged - Makefile.PL now determines the build environment (one of 3 possibles: MSwin32 and VC++, MSWin32 and MinGW, Cygwin). If it doesn't get it right for you I'd like to know. You can force the issue by passing BUILDENV=xxxx on the command line if necessary (read the first bit of Makefile.PL for instructions). - there are a few extra rules in the makefile, particularly related to deleting stuff properly when doing 'make clean' I have, today, built and run 'make test' (although no more than that) successfully in the following environments: (1) Win98, MinGW (gcc v3.2.3), ActivePerl 5.6.1 (2) Win98, MinGW (gcc v3.2.3), ActivePerl 5.8.7 (3) Win2k, MSVC++ 2003 Toolkit (cl v13.10.3077), ActivePerl 5.6.1 (4) Win2k, MSVC++ 2003 Toolkit (cl v13.10.3077), ActivePerl 5.8.7 (5) Win2k, Cygwin (gcc v3.4.4), Perl 5.8.6 If there are no issues, then I propose that we turn this into a release at the start of next week I have also just realised that these release candidates should have been numbered 1.00_XX - I guess the release should really be v1.02 to keep the numbers increasing :-) For Reini and anyone else who wants it I have replace the RC2 source with RC3 source at http://www.robmay.me.uk/win32gui/ Regards, Rob. |
|
From: Reini U. <ru...@x-...> - 2005-07-01 06:01:40
|
>> I have, today, built and run 'make test' (although no more than that) >> successfully in the following environments: >> (1) Win98, MinGW (gcc v3.2.3), ActivePerl 5.6.1 >> (2) Win98, MinGW (gcc v3.2.3), ActivePerl 5.8.7 >> (3) Win2k, MSVC++ 2003 Toolkit (cl v13.10.3077), ActivePerl 5.6.1 >> (4) Win2k, MSVC++ 2003 Toolkit (cl v13.10.3077), ActivePerl 5.8.7 >> (5) Win2k, Cygwin (gcc v3.4.4), Perl 5.8.6 To add: I also tested against (6) Win2k, MSVC6 no SP and SP2 (cl 1200), ActivePerl 5.8.7 (7) Win2k, MSVC6 SP2 (cl 1200), ActivePerl 5.6.1 Hopefully I can test against some older perls of mine also sooner or later. Hmm, CVS works for my MSVC6 12.00.8804, ActivePerl 5.6.1 Maybe the math.h logic must be enhanced to be included also on newer versions. They still didn't guard the templates against extern C linkage. So I suggest to use #if defined(_MSC_VER) #include <math.h> #endif Also note that the GUI.res file is incompatible between windres and rc, MS LINK.EXE even crashes with an internal error when linking against the windres file. >> If there are no issues, then I propose that we turn this into a >> release at the start of next week I have also just realised that >> these release candidates should have been numbered 1.00_XX - I guess >> the release should really be v1.02 to keep the numbers increasing :-) > > > Well, I have an issue. Configuration: > > Win2k SP4, MSVC++ 6.0, MSVC++ Toolkit 2003, ActivePerl 5.8.4 > > Error: > > cl -c -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE > -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT > -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG > -O1 -DVERSION=\"1.01_03\" -DXS_VERSION=\"1.01_03\" > "-IC:\Perl\lib\CORE" GUI.cpp > GUI.cpp > C:\PROGRA~1\MICROS~2\VC98\INCLUDE\math.h(514) : error C2894: templates > cannot be declared to have 'C' linkage > > From a clean, working environment from after RC2 (I think, but maybe > RC1) I did the cvs update, and ran the same batch file I'd used to build > it before, and it failed. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ http://phpwiki.org/ |
|
From: Robert M. <rm...@po...> - 2005-07-01 23:05:26
|
Glenn Linderman wrote:
> Hmmmm. Having problems with compiling math.h, I tried this, but got
>
> cl -c -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE
> -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT
> -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi
> -DNDEBUG -O1 -DVERSION=\"1.01_03\" -DXS_VERSION=\"1.01_03\"
> "-IC:\Perl\lib\CORE" GUI.cpp
> GUI.cpp
>
> *** Using Preserved Perl context.
>
> GUI.xs(200) : error C2065: '__TEMP_WORD' : undeclared identifier
> GUI.xs(288) : error C2065: 'IDI_DEFAULTICON' : undeclared identifier
> GUI.xs(328) : error C2065: 'IDC_HSPLIT' : undeclared identifier
> GUI.xs(331) : error C2065: 'IDC_VSPLIT' : undeclared identifier
> GUI.xs(4465) : error C2146: syntax error : missing ';' before
> identifier 'cClrBits'
> GUI.xs(4465) : error C2065: 'cClrBits' : undeclared identifier
> GUI.xs(4517) : error C2146: syntax error : missing ')' before
> identifier 'pbih'
> GUI.xs(4517) : error C2059: syntax error : ')'
> GUI.xs(4517) : error C2143: syntax error : missing ';' before '{'
> *** PACKAGE Win32::GUI::Menu...
> *** PACKAGE Win32::GUI::MenuButton...
> *** PACKAGE Win32::GUI::MenuItem...
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
>
>
> I think that is an improvement, in the sense that the compilation
> proceeded further than before.
I'm working on it. I think I understand all the changes that Reini gave
me as parts of the cygwi and his MSVC6 patches. I'm reverting GUI.h to
something much closer to what went out with the V1.0 release.
The problems all stem from the 'extern "C"' declarations around the perl
includes - Reini changed the conditions under which they were/were not
defined, resulting in them being added for builds usin
-DPERL_IMPLICIT_CONTEXT, when they were not before; he then added
math.h outside this block, so that when math.h was included again by
perl.h in had already been seen, and was not parsed in "C" context.
I think I've got it going - give me another 15 minutes and I'll check in
an updated version.
Rob.
|
Thanks for helping keep SourceForge clean.
X