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

Re: [perl-win32-gui-hackers] Commit - enhanced resource loading

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

Robert May schrieb:
> Earlier this-evening I committed a change to they way the internal
> LoadImage() functions searches for Bitmaps, Icons and Cursors, prompted
> by a patch Reini Urban submitted to me.
> 
> I've updated the docs for Win32::GUI::Icon->new to read:
> 
> # (@)METHOD:new Win32::GUI::Icon(FILENAME)
> # Creates a new Icon object reading from FILENAME.
> #
> # If FILENAME is a string, then it is first tried as a resource
> # name, then a filename.  If FILENAME is a number it is tried
> # as a resource identifier.
> #
> # Resources are searched for in the current exe (perl.exe unless
> # you have packed your application using perl2exe, PAR or similar),
> # then in the Win32::GUI GUI.dll, and finally as an OEM resource
> # identifier
> 
> And similar wording for the bitmap and cursor constructors.
> 
> The result is that now, as well as loading these object from files, you
> now have better access to embedded resources:
> 
> for example:
> my $icon = Win32::GUI::Icon->new(IDI_DEFAULTCON);
>   gives you the Win32::GUI camel icon
> my $icon = Win32::GUI::Icon->new("PERLEXE");
>   gives you the ActiveState 'lizard' icon (assuming you're using AS perl)

Thanks! Much better.


> There's a new application in the samples directory that allows you to
> browse all the win32 built-in resources (standard icons, bitmaps and
> cursors), 

very good!

> and Win32::GUI::Constants has been updated to include the
> required identifiers.
> 
> Regards,
> Rop.

Rop ?? :)
-- 
Reini

Re: [perl-win32-gui-hackers] Changes to SourceForge CVS platform

[darrik <da...@my...>]

Glenn Linderman wrote:
> On approximately 6/3/2006 3:22 AM, came the following characters from 
> the keyboard of Robert May:
>> Glenn Linderman wrote:
>>> On approximately 5/17/2006 1:10 PM, came the following characters from 
>>> the keyboard of Robert May:
>>>> Glenn Linderman wrote:
>>>>> ... but what about backups?  I'd be happy to backup Win32::GUI's CVS 
>>>>> if there is a Windows rsync that I can use to do it... unless you 
>>>>> have already set up something.
>>>> I already investigated, and found cwRsync
>>>> http://www.itefix.no/cwrsync/
>>> Do you have a command line that does the job that you could share as a 
>>> starting point for creating my own command line?
>> I just followed the instructions at:
>> https://sourceforge.net/docs/E04/en/#rsync
>>
>> which led me to having the following .bat file (adjust paths as 
>> necessary; last line may wrap - it's supposed to be one line only):
>>
>> @echo off
>> rem backup the perl-win32-gui sourceforge CVS repository
>> rem into the current directory
>> C:\PROGRA~1\cwRsync\bin\rsync -av 
>> rsync://perl-win32-gui.cvs.sourceforge.net/cvsroot/perl-win32-gui/* .
>>
>> Thanks,
>> Rob.
> 
> OK, that was relatively simple.  I modified the script a bit so I'll 
> keep one backup per day-of-the-week so the script chooses the directory 
> for the day of the week, and then does your command.  So I'll always 
> have 7 copies, generally from the last 7 days, and, no doubt, often 
> redundant when not much is happening.  But only when I'm not on 
> vacation, so there will be some sporadic behaviour then, when some of my 
> backups could be older... it is part of my bootup-first-time-each-day 
> script.


If it's helpful, I have a linux server running 24/7 at my house, so I
can automate a daily backup and keep them as far back as it suits you
guys (as I'm not in any danger [yet] of filling the 800GBs of disk space
on it). ;)

I'll set that up Monday at first opportunity.

Darrik Mazey

Re: [perl-win32-gui-hackers] Win32::GUI::Console

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

Glenn Linderman wrote:
> On approximately 5/30/2006 12:10 PM, came the following characters from 
> the keyboard of Robert May:
>> Jeremy White wrote:
>>>> Something like this:
>>>> - ability to close Console if there is one present and its not needed
>>>> - automatically re-create a console window if any reads/writes are 
>>>> done on stdin/out/err
>>>> - ability to set the Console window title, Icon etc.
>>>>
>>>> Eventually remove GetPerlWindow() from GUI.xs??
>>>
>>> I suspect I'm missing the point:) But why do any of this? During 
>>> development most people would run with the console window showing - 
>>> makes debugging a GUI app so much simpler. Then when the script needs 
>>> to be deployed (either by wperl, or one of the exe creators) - the 
>>> console is automatically not created?
> 
> Yes, that can/has been done.
> 
> My personal twist on this is that I hide the console window, but have a 
> button to show it again, if the user wants to see the debugging message, 
> or if I am working with the user, and want them to read them to me.

That's nice. I'd like to hide the console, and have it automatically 
re-appear when something bad happens (e.g. a warn/carp/croak ... in fact 
probably when anything is written to STDERR).  I've got a prototype 
running using tie()d file handles;  I also want to investigate using a 
perlIO layer for this, as it feels that would be cleaner, but that can 
only be used on perl 5.7 and above.

> For my applications (packaged with PAR), it isn't likely that the user 
> will start them from a console window (CMD), but I do it, and get plenty 
> annoyed when the app crashes and my CMD goes away.

I think an option to add an END block that prints a message and waits 
for a keystroke would be useful here - it won't keep the console around 
if perl really crashes, but it should keep it around to allow reading of 
most script-level warnings/errors.

> I have no idea how to detect if the console for the APP is the same as 
> the one used to launch the APP, or even if it is possible to determine 
> that, but if it is possible to determine that, I'd like the option 
> (which I would use in several APPs) of then detaching from the original 
> console and creating a new one for the APP.  Preferably, the new one 
> could be initially hidden.

I think it should be possible to tell which case we're in:  if perl.exe 
is run from an existing command window, then the perl.exe process is a 
'child' of its command window process;  if perl.exe is launched by 
double-clicking the .pl file, then the command window process is a 
'child' of perl.exe.  It's just that there doesn't seem to be a simple, 
cross-platform way of determining child-parent process relationships in 
windows.  With some XS code I think I can determine this relationship on 
all the platforms that we need to support other than NT. (so it'll be OK 
on W95/98/ME/2K/XP.


If you don't mind it looking a bit clunky, then you can already achieve 
a process always having it's own console:

use Win32::GUI();
use Win32::Console();

# Detach from any existing console, fails silently
# if there is no existing console
Win32::Console::Free();

# Create and then hide a new console
Win32::Console::Alloc();
my $chwnd = Win32::GetPerlWindow();
Win32::GUI::Hide($chwnd);

You get a flash of console once when launching from the command line 
(the Free() does nothing, the Alloc() creates a new visible console 
which then gets hidden almost immediately.)

You get 2 console flashes for an app that is double-clicked to start 
(the app creates it's own visible console, which then disappears when 
Free() is called, the Alloc() creates a new, visible console that then 
gets hidden.)

If only there was a way to ask AllocWindow() to create a hidden console, 
but I read that it's impossible.  (I do want to explore the possibility 
of using a global hook to see if I can catch one of the messages that 
happens early during window creation, and fiddle the WS_VISIBLE style, 
but I'm not hopeful!)

Rob.

Re: [perl-win32-gui-hackers] Changes to SourceForge CVS platform

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

Glenn Linderman wrote:
> On approximately 5/17/2006 1:10 PM, came the following characters from 
> the keyboard of Robert May:
>> Glenn Linderman wrote:
>>> ... but what about backups?  I'd be happy to backup Win32::GUI's CVS 
>>> if there is a Windows rsync that I can use to do it... unless you 
>>> have already set up something.
>>
>> I already investigated, and found cwRsync
>> http://www.itefix.no/cwrsync/
> 
> Do you have a command line that does the job that you could share as a 
> starting point for creating my own command line?

I just followed the instructions at:
https://sourceforge.net/docs/E04/en/#rsync

which led me to having the following .bat file (adjust paths as 
necessary; last line may wrap - it's supposed to be one line only):

@echo off
rem backup the perl-win32-gui sourceforge CVS repository
rem into the current directory
C:\PROGRA~1\cwRsync\bin\rsync -av 
rsync://perl-win32-gui.cvs.sourceforge.net/cvsroot/perl-win32-gui/* .

Thanks,
Rob.

Re: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

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

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.

[perl-win32-gui-hackers] Commit - enhanced resource loading

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

Earlier this-evening I committed a change to they way the internal 
LoadImage() functions searches for Bitmaps, Icons and Cursors, prompted 
by a patch Reini Urban submitted to me.

I've updated the docs for Win32::GUI::Icon->new to read:

# (@)METHOD:new Win32::GUI::Icon(FILENAME)
# Creates a new Icon object reading from FILENAME.
#
# If FILENAME is a string, then it is first tried as a resource
# name, then a filename.  If FILENAME is a number it is tried
# as a resource identifier.
#
# Resources are searched for in the current exe (perl.exe unless
# you have packed your application using perl2exe, PAR or similar),
# then in the Win32::GUI GUI.dll, and finally as an OEM resource
# identifier

And similar wording for the bitmap and cursor constructors.

The result is that now, as well as loading these object from files, you 
now have better access to embedded resources:

for example:
my $icon = Win32::GUI::Icon->new(IDI_DEFAULTCON);
   gives you the Win32::GUI camel icon
my $icon = Win32::GUI::Icon->new("PERLEXE");
   gives you the ActiveState 'lizard' icon (assuming you're using AS perl)

There's a new application in the samples directory that allows you to 
browse all the win32 built-in resources (standard icons, bitmaps and 
cursors), and Win32::GUI::Constants has been updated to include the 
required identifiers.

Regards,
Rop.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

[perl-win32-gui-hackers] CVS structural changes (AxWindow/DiBitmap/Grid/Scintilla)

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

Just a heads-up that I've asked the sourceforge admins to move the 
Win32-GUI-AxWindow, Win32-GUI-DIBitmap, Win32-GUI-Grid and 
Win32-GUI-Scintilla directories into the main Win32-GUI directory in 
preparation for me committing code changes to bring these modules into 
the core distribution.  This change should happen sometime in the next 
3-5 working days.

Please take care when synchronising with the repository if you have 
directories of these names (unlikely, I know) in your Win32-GUI source 
directory.

Also, once the change is made and until I have time to commit my changes 
you may find that your build process fails - if so, delete the new 
directories.

I will try to keep any inconsistent periods as short as possible.

Regards
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/

Re: [win32-gui] RE: [perl-win32-gui-hackers] Constants, Scintilla, Grid, DIBitmap and AxWindow

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

Jeremy White wrote:
>> Here's how I stand:
>>
>> Scintilla - no problems with this. I have the code ready to become 
>> Grid - I'm ready to make this part of core too.  As it relies on the 
>> DIBitmap - Whilst this should technically be compilable (sp?) using 
>> AxWindow - relies on the MS ATL framework, so I doubt it can ever be
> 
>> Unless anyone want me to stop, I intend to raise a support request
> 
> Sounds good to me. I assume that we'll end up with one PPM that will 
> install all the modules?

That's the current plan.

Rob.

RE: [perl-win32-gui-hackers] Constants, Scintilla, Grid, DIBitmap and AxWindow

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

>Here's how I stand:
>
>Scintilla - no problems with this. I have the code ready to become Grid - 
>I'm ready to make this part of core too.  As it relies on the DIBitmap - 
>Whilst this should technically be compilable (sp?) using AxWindow - relies 
>on the MS ATL framework, so I doubt it can ever be

>Unless anyone want me to stop, I intend to raise a support request

Sounds good to me. I assume that we'll end up with one PPM that will install 
all the modules?

Cheers,

jez.

[perl-win32-gui-hackers] Com in C, part 4 & 5

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

http://www.codeproject.com/com/com_in__c4.asp
http://www.codeproject.com/useritems/com_in_c5.asp

Cheers,

jez.

[perl-win32-gui-hackers] RE: Win32::GUI::Console

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

Jeremy White wrote:
>> Something like this:
>> - ability to close Console if there is one present and its not needed
>> - automatically re-create a console window if any reads/writes are 
>> done on stdin/out/err
>> - ability to set the Console window title, Icon etc.
>>
>> Eventually remove GetPerlWindow() from GUI.xs??
> 
> I suspect I'm missing the point:) But why do any of this? During 
> development most people would run with the console window showing - 
> makes debugging a GUI app so much simpler. Then when the script needs to 
> be deployed (either by wperl, or one of the exe creators) - the console 
> is automatically not created?

Good question that set me off thinking.  The initial though was spurred 
by not wanting to have to re-write all the demos so that they could be 
launched without consoles, but still have one when needed.  Having 
thought further, I think I can make a case for it:

(1) You're right about how you and I (and others) would probably develop 
apps, but I'm pretty sure that most people don't package their perl 
scripts as executables.  It would be nice for these people to have 
something more powerful than
   Win32::GUI::Hide(Win32::GUI::GetPerlWindow());
that wouldn't hide the console if started from the command line, and 
didn't launch a console when double clicking the .pl script, unless the 
script produces some output.

(2) If I use other peoples modules in my apps, then I don't know what 
errors will be produced to stdout/stderr, and I'd get better bug reports 
if people could see something, rather than the app silently terminating.

I'm going to have a go at this, as I think it's a pretty simple wrapper 
round Win32::Console.  Then we'll see what people think (besides, I 
think I need something to complete the win32-gui-demos.pl script)

Regards,
Rob.

[perl-win32-gui-hackers] Constants, Scintilla, Grid, DIBitmap and AxWindow

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

A quick status update and a few issues to discuss.

Constants - I just commited a quick fix to stop subclasses of Win32::GUI 
(and of Win32::GUI::Window etc.) inheriting Win32::GUI's import function 
- this will quiet a few of the new warnings.

I spent some time over the last week and a half investigating the code 
from Laurent's modules to integrate it with the Win32::GUI core.  In all 
cases I have:
- modified the build process to be in line with the other modules I have 
been added (DropFiles, Constants);
- made the modules work under warnings and strictures
- added basic tests
- visited the demos, tidied them up and ensured they all work
- in some cases, added a demo or two that I wrote to ensure that I 
understood how the modules worked.

Here's how I stand:

Scintilla - no problems with this. I have the code ready to become part
of the Win32::GUI core

Grid - I'm ready to make this part of core too.  As it relies on the MS
MFC framework, then I don't believe that this module can ever be
compiled using mingw (or under cygwin), and I currently have the build 
process printing a warning and skipping the build unless the compiler is 
cl.exe.   Unless anyone knows any different, this is how it will remain, 
as I don't have the time to investigate further.

DIBitmap - Whilst this should technically be compilable (sp?) using gcc, 
  I haven't been able to make it happen, and don't want to invest any 
further time on this.  It too, is currently skipped unless building with 
cl.exe  compiler.  Again, if anyone knows any different I'll be happy to 
integrate patches.

AxWindow - relies on the MS ATL framework, so I doubt it can ever be 
compiled with gcc.  Again this is skipped unless using the MS compiler.

Unless anyone want me to stop, I intend to raise a support request with 
sourceforge to get the existing repositories moved to underneath the 
Win32-GUI directory;  I will then commit my chages on top of that.

Regards
Rob.

[perl-win32-gui-hackers] resolve Package.html =item links to <li> entries

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

Sorry, I didn't check current CVS if this is already fixed.
I have no access to the cvs port through our company firewall.

My Package.html didn't resolve the =item links to <li> entries.
To fix this I had to add this:

doPodDocs.pl: add "\n" to Package.pod =item list for pod2html to
expand the links

$packages .= BuildTools::macro_subst("__W32G_PKGTPL__") . "\n";

-- 
Reini Urban

Re: [win32-gui] RE: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

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

>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.

[perl-win32-gui-hackers] Re: CVS Commit - More Win32::GUI::Constants changes

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

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.

Re: [win32-gui] RE: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

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

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.

[perl-win32-gui-hackers] RE: Win32::GUI::Console [Was: Application that in installed in perl bin directory to start up samples]

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

>Something like this:
>- ability to close Console if there is one present and its not needed
>- automatically re-create a console window if any reads/writes are done on 
>stdin/out/err
>- ability to set the Console window title, Icon etc.
>
>Eventually remove GetPerlWindow() from GUI.xs??

I suspect I'm missing the point:) But why do any of this? During development 
most people would run with the console window showing - makes debugging a 
GUI app so much simpler. Then when the script needs to be deployed (either 
by wperl, or one of the exe creators) - the console is automatically not 
created?

Cheers,

jez.

RE: [perl-win32-gui-hackers] Distributing manifests [Was: Application that in installed in perl bin directory to start up samples]

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

>I don't have access to XP, so have not looked into manifests.  I can see 
>that distributing them (or otherwise making them available) would be a good 
>thing, but I'm not so sure about installing them in the perl bin directory 
>- is there any down side to doing that?

The manifest is a simple XML string:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <assemblyIdentity
          processorArchitecture="x86"
          version="5.1.0.0"
          type="win32"
          name="Your application"
      />
      <description>Win32::GUI Application</description>
      <dependency>
          <dependentAssembly>
              <assemblyIdentity
                  type="win32"
                  name="Microsoft.Windows.Common-Controls"
                  version="6.0.0.0"
                  publicKeyToken="6595b64144ccf1df"
                  language="*"
                  processorArchitecture="x86"
          />
      </dependentAssembly>
      </dependency>
  </assembly>

When saved as "perl.exe.manifest" in the bin dir it automatically turns on 
XP styles for any script ran with perl.pl - the manifest has no effect with 
other versions of Windows. When converted to an exe, the manifest can exist 
as a separate file or you can add the manifest as a resource to the exe 
(which is the approach I take).

Perhaps it's worth including the manifest in the source - and even for the 
PPM the manifest is extracted somewhere?

>How about a Wiki page explaining what is needed as a starting point?

Sure, no problem - it might be worth having it as part of the core 
documentation aswell.

Cheers,

jez.

Re: [win32-gui] RE: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

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

>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.

Re: [win32-gui] RE: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

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

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.

Re: [win32-gui] RE: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

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

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.

Re: [win32-gui] RE: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

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

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.

RE: [perl-win32-gui-hackers] CVS Commit - More Win32::GUI::Constants changes

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

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.

Re: [win32-gui] Re: [perl-win32-gui-hackers] Changes to SourceForge CVS platform

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

Glenn Linderman wrote:
> ... but what about 
> backups?  I'd be happy to backup Win32::GUI's CVS if there is a Windows 
> rsync that I can use to do it... unless you have already set up 
> something.

I already investigated, and found cwRsync
http://www.itefix.no/cwrsync/
that seems to do the job.  I'll be doing sporadic backups (as I have 
been doing under the previous regime with the tarballs, and for the 
website, Wiki and tracker data ...) - but I'd be very happy to know 
someone else was doing it too.

> Maybe, to cover vacations and such, more than one backup location should 
> be created.

I'm not sure that we're active enough that vacations etc, are a problem. 
  Although I haven't looked into it yet, I could easily have a cron job 
do  a backup daily.  Multiple locations is definitely a good idea, and 
if you're happy to look into this then please go ahead.

Thanks,
Rob.

[perl-win32-gui-hackers] Win32::GUI::Console [Was: Application that in installed in perl bin directory to start up samples]

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

Jeremy White wrote:
 > Robert May wrote:
>> Is this a good thing to pursue?  Suggestions for changes or 
>> alternative approaches welcome.  A better name for the script would be 
>> good too!
> 
> Nice - with a good set of examples it would certainly show what 
> Win32-GUI is capable off.

Based on the feedback I'm going to have a go at completing this.  I want 
to do some more work on understanding Win32 Consoles - partly spurred on 
by this effort, and partly spurred on by Steve Loughran's questions 
about launching sub-processes on the users' list.

I'm thinking about a Win32::GUI::Console module that extends the 
Win32::Console module (another of Aldo's creations), to wrap the things 
that GUI apps might find useful when dealing with Consoles  (I already 
have something that I call Win32::GUI::Console that wraps a RichEdit 
Control for use as pseudo Console).

Something like this:
- ability to close Console if there is one present and its not needed
- automatically re-create a console window if any reads/writes are done 
on stdin/out/err
- ability to set the Console window title, Icon etc.

Eventually remove GetPerlWindow() from GUI.xs??

It'd be especially good if you could then use the module like
   perl -MWin32::GUI::Console script.pl
to launch apps that weren't written with Console hiding in mind, and you 
didn't know whether there would be console output of not; Additionally
   wperl -MWin32::GUI::Console script.pl would provide a console if any 
input or output was required, meaning that you wouldn't miss warnings etc.

Regards,
Rob.
-- 
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/