From: Robert M. <rm...@po...> - 2006-05-13 15:47:47
|
I just added my code for the Win32::GUI::Constants module that we have discussed here recently. The build process is internally a bit convoluted, but should happen smoothly from the outside! I've not built under perl 5.6 or cygwin yet, but I don't envisage any problems there. Still to do: - Integrate the module with GUI.pm, so that we can seamlessly use the same options from the 'use Win32::GUI' statement. - Re-implement Win32::GUI::constant() to delegate (with a deprecated warning) to Win32::GUI::Constants::Constant() - Remove the existing constant implementation: remove code from GUI.pm and remove GUI_constants.cpp; update Makefile.PL as necessary I hope I'll have these changes before long - I've got a few other things to look at first. As always comments on success and/or failures in your build environment are encouraged. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ |
From: Jeremy W. <jez...@ho...> - 2006-05-14 08:38:55
|
>I just added my code for the Win32::GUI::Constants module that we have >discussed here recently. The build process is internally a bit convoluted, >but should happen smoothly from the outside! >As always comments on success and/or failures in your build environment are >encouraged. No cup final for you eh?:) Ok - builds fine under my environment, with all tests passing. Cheers, jez. |
From: Robert M. <rm...@po...> - 2006-05-14 22:34:55
|
Jeremy White wrote: > Ok - builds fine under my environment, with all tests passing. Thanks for the feedback. I was feeling brave this-afternoon and I've made the changes to GUI.pm and elsewhere to remove the existing constants support and integrate Win32::GUI::Constants. I think I resolved the issues that I introduced, but the current implementation has an (unnecessarily?) complex inter-twining of class hierarchies and AUTOLOADing, and I had to make a couple of changes in areas that I wasn't expecting to. I'll keep running the new code for a couple of days here, then check it in for everyone to have a play with, and find out if (1) I've seriously broken any existing scripts. (2) If the deprecated warnings that I've added are too noisy. (3) the new functionality works In the mean time, can anybody suggest why it might be a bad idea to remove 'Win32::GUI' from the @ISA of Win32::GUI::Class Win32::GUI::MenuButton or Win32::GUI::MenuItem? Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ |
From: Jeremy W. <jez...@ho...> - 2006-05-15 07:34:18
|
>In the mean time, can anybody suggest why it might be a bad idea to remove >'Win32::GUI' from the @ISA of Win32::GUI::Class Win32::GUI::MenuButton or >Win32::GUI::MenuItem? Not that I can think off. Cheers, jez. |
From: Robert M. <rm...@po...> - 2006-05-16 19:19:00
|
I just committed changes to GUI.pm, GUI.xs (and removed GUI_Constants.cpp) to introduce the 'delegation' of constant support in Win32::GUI to Win32::GUI::Constants. Other files change - see the CHANGELOG for details I'd appreciate it if people can build and what's in CVS and run their current scripts against these changes to see what (if any) change in behaviour you get. I hope none (except perhaps for a few warnings), but I need help to ensure I've covered all the ways people were accessing the constants previously. Additionally I'd like some confidence that I haven't accidentally broken anything elsewhere - everything seems OK here, and all the tests still pass (they didn't with my first attempt, showing the value of having such tests). You will find that you probably get warnings for the old usage. Before we release this on the unsuspecting masses: (1) Are the warnings too noisy? I.e. do you end up with thousands of the same warning? (2) Are the warnings suitably worded? I.e. is it clear what changes you should be making? (3) Does including "no warnings 'deprecated';" in your script silence the warnings? As a side affect of this I had to visit the samples folder, and update some of the demos to 'use Win32::GUI()'. In this process I've made each demo script run under strict and warnings; fixed some bug: - added a bitmap so the SplashScreen demo works - using FindBin module so that demos that load files can find them even if the the working directory is elsewhere (more on why I want this later) - fixed huge resource leaks in Draw.pl and Region.pl; Added some code to Region.pl to clear the background, it is now a little more obvious what it is doing. - added some missing constants to Win32::GUI::Constants Here's hoping it all hangs together for you. Regards, Rob. -- Robert May Win32::GUI, a perl extension for native Win32 applications http://perl-win32-gui.sourceforge.net/ |
From: Jeremy W. <jez...@ho...> - 2006-05-17 09:35:38
|
>I'd appreciate it if people can build and what's in CVS and run their >current scripts against these changes to see what (if any) change in >behaviour you get. I hope none (except perhaps for a few warnings), but I >need help to ensure I've covered all the ways people were accessing the >constants previously. Additionally I'd like some confidence that I haven't >accidentally broken anything elsewhere - everything seems OK here, and all >the tests still pass (they didn't with my first attempt, showing the value >of having such tests). Bareword "Win32::GUI::MB_OK" not allowed while "strict subs" in use at C:/perl/s ite/lib/Client/WindowManager.pm line 120. Bareword "Win32::GUI::MB_ICONINFORMATION" not allowed while "strict subs" in use at C:/perl/site/lib/Client/WindowManager.pm line 120. :) In the WindowManager package I've got the following code: Win32::GUI::MessageBox($mainwindow,$text,"Message", Win32::GUI::MB_OK | Win32::GUI::MB_ICONINFORMATION); Turns out I'm doing this all over the place - for example in another package: $grahicwin = new Win32::GUI::Window ( -parent => $w, -name => 'Time', -pos => [8,160], -size => [562,105], -popstyle => Win32::GUI::WS_CAPTION | Win32::GUI::WS_SIZEBOX, -pushstyle => Win32::GUI::WS_CHILD | Win32::GUI::WS_CLIPCHILDREN, -pushexstyle => Win32::GUI::WS_EX_CLIENTEDGE, The reason I did this was to stop the namespace pollution of doing a use Win32::GUI in each package:) Hopefully I'll have time later today to change my logic. Cheers, jez. |
From: Robert M. <rm...@po...> - 2006-05-17 21:10:45
|
Jeremy White wrote: > > Bareword "Win32::GUI::MB_OK" not allowed while "strict subs" in use at > C:/perl/site/lib/Client/WindowManager.pm line 120. > Bareword "Win32::GUI::MB_ICONINFORMATION" not allowed while "strict > subs" in use at C:/perl/site/lib/Client/WindowManager.pm line 120. > > In the WindowManager package I've got the following code: > > Win32::GUI::MessageBox($mainwindow,$text,"Message", Win32::GUI::MB_OK | > Win32::GUI::MB_ICONINFORMATION); Hmm. This is problematic with the current code. You must be doing an unadorned 'use Win32::GUI;' somewhere (and if running under warnings you'll get a warning about this). I've got a small patch to Constants.pm that fixes this issue - it'll be in CVS shortly. Under warnings you should find (with the new code) that you get a warning for each unadorned use Win32::GUI; and a warning for the first time each constant that you use that way is called. But things should keep working. Regards, Rob. |
From: Robert M. <rm...@po...> - 2006-05-17 22:03:42
|
Robert May wrote: > Jeremy White wrote: >> >> Bareword "Win32::GUI::MB_OK" not allowed while "strict subs" in use at >> C:/perl/site/lib/Client/WindowManager.pm line 120. >> Bareword "Win32::GUI::MB_ICONINFORMATION" not allowed while "strict >> subs" in use at C:/perl/site/lib/Client/WindowManager.pm line 120. >> >> In the WindowManager package I've got the following code: >> >> Win32::GUI::MessageBox($mainwindow,$text,"Message", Win32::GUI::MB_OK >> | Win32::GUI::MB_ICONINFORMATION); > > Hmm. This is problematic with the current code. You must be doing an > unadorned 'use Win32::GUI;' somewhere (and if running under warnings > you'll get a warning about this). I've got a small patch to > Constants.pm that fixes this issue - it'll be in CVS shortly. It's in CVS, but I've broken non-qualified barewords. Back to the drawing board. Rob. |
From: Robert M. <rm...@po...> - 2006-05-17 22:30:26
|
Robert May wrote: > Robert May wrote: >> Jeremy White wrote: >>> >>> Bareword "Win32::GUI::MB_OK" not allowed while "strict subs" in use >>> at C:/perl/site/lib/Client/WindowManager.pm line 120. >>> Bareword "Win32::GUI::MB_ICONINFORMATION" not allowed while "strict >>> subs" in use at C:/perl/site/lib/Client/WindowManager.pm line 120. >>> >>> In the WindowManager package I've got the following code: >>> >>> Win32::GUI::MessageBox($mainwindow,$text,"Message", >>> Win32::GUI::MB_OK | Win32::GUI::MB_ICONINFORMATION); >> >> Hmm. This is problematic with the current code. You must be doing an >> unadorned 'use Win32::GUI;' somewhere (and if running under warnings >> you'll get a warning about this). I've got a small patch to >> Constants.pm that fixes this issue - it'll be in CVS shortly. > > It's in CVS, but I've broken non-qualified barewords. Back to the > drawing board. Another attempt in CVS - I think that's nailed it, but there's a problem with the test that I have to get to the bottom of: they all pass when using 'prove' from the command line, but there's some failures under 'make test'. Rob. |
From: Robert M. <rm...@po...> - 2006-05-17 22:57:07
|
Robert May wrote: > Another attempt in CVS - I think that's nailed it, but there's a problem > with the test that I have to get to the bottom of: they all pass when > using 'prove' from the command line, but there's some failures under > 'make test'. Not sure what I messed up in my environment - but all tests are actually fine. Jez, does the current CVS allow your scripts to run, albeit with lots of warnings? Regards, Rob. |
From: Jeremy W. <jez...@ho...> - 2006-05-18 09:51:23
|
>Jez, does the current CVS allow your scripts to run, albeit with lots of >warnings? New odd issue - same scenario - use of constants in another package: Can't locate auto/Win32/GUI/Grid/DT_CENTER.al in @INC (@INC contains: C:/perl/li b C:/perl/site/lib .) at ... the offending line: $Grid->InsertColumn($_,Win32::GUI::Grid::DT_CENTER|Win32::GUI::Grid::DT_VCENTER|Win32::GUI::Grid::DT_SINGLELINE); The strange thing is that even if I do: use Win32::GUI::Grid; ... $Grid->InsertColumn($_,DT_CENTER|DT_VCENTER|DT_SINGLELINE); I still get the same error. Thinking about it, I do remember having constant issues with Grid - but this was a long, long time ago. I don't understand how your changes could be effecting things? Cheers, jez. |
From: Robert M. <rm...@po...> - 2006-05-18 19:13:17
|
Jeremy White wrote: >> Jez, does the current CVS allow your scripts to run, albeit with lots >> of warnings? > > New odd issue - same scenario - use of constants in another package: Jeremy and I have got to the bottom of all his issues off-list. To summarise: (1) We found a bug in the way Win32::GUI::Grid handles constants. - I will fix this, and move Win32::GUI::Grid into the core distribution (2) We found that Scintilla tries to get one of the Win32__GUI__* constants using Win32::GUI::constants() - I will fix up Win32::GUI::constants() to handle this, with a warning. As a result of this I want to look at moving Grid, Scintilla, DIBitmap and AxWindow into the core distribution - I have been putting this off for some time. The only thing that concerns me is that the distribution is growing in size quite rapidly, and once things are in it's difficult to take them out. Is anyone concerned if the binary distribution doubles in size? How about if it trebles in size? I guess the real question is how do we decide what's in the core and what's not. Should we start separate distributions for some modules instead of having one large distribution? Regards, Rob. |
From: Robert M. <rm...@po...> - 2006-05-18 19:42:14
|
Robert May wrote: > (2) We found that Scintilla tries to get one of the Win32__GUI__* > constants using Win32::GUI::constants() > - I will fix up Win32::GUI::constants() to handle this, with a warning. Fix is in CVS. |
From: Jeremy W. <jez...@ho...> - 2006-05-19 08:47:57
|
>The only thing that concerns me is that the distribution is growing in size >quite rapidly, and once things are in it's difficult to take them out. Is >anyone concerned if the binary distribution doubles in size? How about if >it trebles in size? > >I guess the real question is how do we decide what's in the core and what's >not. Should we start separate distributions for some modules instead of >having one large distribution? Personally I wouldn't mind if the binary distribution increased by 10 times - even then it would still be small compared to some toolkits!:) As long as the runtime sizes are kept the same (i.e., we're not loading modules if they aren't being used) and the exe generators (PAR, perl2exe & perlapp) don't automatically include them - then there really isn't any issue other than bandwidth. There are other advantages of bundling them together - there is some shared code which could be removed, with other code simplified. Going forward, all these modules need to brought together anyway so we can support the NEM, improved class logic (via UserData type methods), Unicode and no doubt other things too:) We could always assume that the user will have these modules installed. Your win32-gui "widget" script for example, would show Perl code via Scintilla and link to the documentation (locally or on the web) via AxWindow (click on a method in the Scintilla window, and the documentation is shown). Cheers, jez. |
From: Robert M. <rm...@po...> - 2006-06-03 10:02:21
|
Glenn Linderman wrote: > I don't care how large the binary > distribution of Win32::GUI gets, as long as the pieces I don't use don't > get loaded at runtime and are not redistributed by PAR. We should be OK then :-) Rob. |
From: Robert M. <rm...@po...> - 2006-06-11 21:35:03
|
Glenn Linderman wrote: > On approximately 6/3/2006 3:02 AM, came the following characters from > the keyboard of Robert May: >> Glenn Linderman wrote: >>> I don't care how large the binary distribution of Win32::GUI gets, as >>> long as the pieces I don't use don't get loaded at runtime and are >>> not redistributed by PAR. >> >> We should be OK then :-) > > Right :) I don't pretend to speak for everyone, of course. I was a > little concerned, though, about Jeremy's comment of sharing stuff that > isn't presently shared, betweeen sub-modules... I don't know how much > that is, or if it can be done without making more dependencies or bigger > hunks of stuff. I think Jeremy's comment was about sharing GUI.h (and other headers etc.) during the build process - not about increasing dependencies between modules. Rob. |
From: Jeremy W. <jez...@ho...> - 2006-06-12 09:07:13
|
> > Right :) I don't pretend to speak for everyone, of course. I was a > > little concerned, though, about Jeremy's comment of sharing stuff that > > isn't presently shared, betweeen sub-modules... I don't know how much > > that is, or if it can be done without making more dependencies or bigger > > hunks of stuff. > >I think Jeremy's comment was about sharing GUI.h (and other headers >etc.) during the build process - not about increasing dependencies >between modules. Yeah, there are also some helper functions that could become "common" across modules - even if they just get defined as macros. Cheers, jez. |