perl-win32-gui-users Mailing List for Win32::GUI

On approximately 7/30/2009 1:21 AM, came the following characters from 
the keyboard of Angelos Karageorgiou:
> Hello folks, I have this interesting little thing
>
> I ma using perl 5.10  and par 0.994. My project uses both Win32::GUI and
> threads for background operations. The strange thing is that when I 
> run the executable (Rautor) it appears twice in the task manager list 
> of processes.
>
> Is this expected behaviour ? 

An artifact of PAR: one is the loader, and the other is the real program.

Hello folks, I have this interesting little thing

I ma using perl 5.10  and par 0.994. My project uses both Win32::GUI and
threads for background operations. The strange thing is that when I run 
the executable (Rautor) it appears twice in the task manager list of 
processes.

Is this expected behaviour ?

Many thanks.

Hey,

 

Instead of trying to use symbolic references to the objects, one solution would be to store the objects in an array and simply iterate over the array to access the objects. You could also use a hash if you want to access them by name. I've used this method when using TabStrip controls. Here is an example:

 

#creating objects

my @objects;

foreach(0..4){

 push @objects, $parent->AddDateTime->new(-name => "DateTime$_");
}

 

#accessing objects

foreach(0..4){

 $objects[$_]->SetDateTime(...);

}

__END__

 

Hope this helps.

 

Kevin.
 
> From: ki...@ne...
> To: per...@li...
> Date: Thu, 30 Jul 2009 13:14:48 +1000
> Subject: [perl-win32-gui-users] blessed object dereferencing unusual behaviour...
> 
> Hi,
> 
> I was having a problem with a DateTime object, and I noticed some behaviour 
> that differs from other Perl programs, so I thought I'd ask here if this is 
> a bug, and if there's anyway around it. The unusual behaviour is as 
> follows:
> 
> DB<52> x $datetime1_tab0
> 0 Win32::GUI::DateTime=HASH(0x7b54a54)
> '-accel' => 0
> '-handle' => 1705748
> '-name' => 'DateTime1_tab0'
> '-type' => 24
> 
> This is a typical object created by AddDateTime to a window.
> 
> DB<53> x ${datetime1_tab0}
> 0 Win32::GUI::DateTime=HASH(0x7b54a54)
> '-accel' => 0
> '-handle' => 1705748
> '-name' => 'DateTime1_tab0'
> '-type' => 24
> 
> Same object, but with a bit of syntax sugar difference.
> 
> DB<54> x ${"datetime1_tab0"}
> 0 HASH(0x7b87064)
> empty hash
> 
> Huh? It's my understanding (and testing this with a couple of other modules 
> confirms this) that anything with the braces {} gets "evaluated" and if it 
> returns a valid result, then everything should be fine.
> 
> The reason I'm trying to do it this way is because I have quite a few of 
> these objects, and I want to create a simple loop to iterate over them, 
> setting each one to the right time according to my script, but if I can't 
> substitute "1/2/3" as needed in the variable name, then I'm stuck.
> 
> I've also tried:
> 
> DB<59> $temp = "datetime1_tab0"
> 
> 
> DB<60> x ${$temp}
> 0 HASH(0x7b87064)
> empty hash
> 
> DB<61> x $$temp
> 0 HASH(0x7b87064)
> empty hash
> 
> As you can see, no such luck. I'm completely stumped. Does anyone have any 
> tips or advice on how to proceed ?
> 
> Thank you. 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/

_________________________________________________________________
Use Windows Live Messenger from your Hotmail inbox Web IM has arrived!
http://windowslive.ninemsn.com.au/article.aspx?id=823454

Hi,

I was having a problem with a DateTime object, and I noticed some behaviour 
that differs from other Perl programs, so I thought I'd ask here if this is 
a bug, and if there's anyway around it.  The unusual behaviour is as 
follows:

  DB<52> x $datetime1_tab0
0  Win32::GUI::DateTime=HASH(0x7b54a54)
   '-accel' => 0
   '-handle' => 1705748
   '-name' => 'DateTime1_tab0'
   '-type' => 24

This is a typical object created by AddDateTime to a window.

  DB<53> x ${datetime1_tab0}
0  Win32::GUI::DateTime=HASH(0x7b54a54)
   '-accel' => 0
   '-handle' => 1705748
   '-name' => 'DateTime1_tab0'
   '-type' => 24

Same object, but with a bit of syntax sugar difference.

  DB<54> x ${"datetime1_tab0"}
0  HASH(0x7b87064)
     empty hash

Huh?  It's my understanding (and testing this with a couple of other modules 
confirms this) that anything with the braces {} gets "evaluated" and if it 
returns a valid result, then everything should be fine.

The reason I'm trying to do it this way is because I have quite a few of 
these objects, and I want to create a simple loop to iterate over them, 
setting each one to the right time according to my script, but if I can't 
substitute "1/2/3" as needed in the variable name, then I'm stuck.

I've also tried:

  DB<59> $temp = "datetime1_tab0"


  DB<60> x ${$temp}
0  HASH(0x7b87064)
     empty hash

  DB<61> x $$temp
0  HASH(0x7b87064)
     empty hash

As you can see, no such luck.  I'm completely stumped.  Does anyone have any 
tips or advice on how to proceed ?

Thank you. 

I just pushed Win32::GUI::SplashScreen V0.04 to CPAN.

V0.03 was shipped with debugging turned on.

I also found a report of a bug with obtaining the bitmap from an
executable packed with PAR (pp - a ....) - this is now fixed.

Regards,
Rob.

2009/7/17 Robert May <rob...@us...>:
> Hi again,
>
> While I am in a releasing mood, there's a new version of
> Win32::GUI::SplashScreen on CPAN.
>
> The only change is to fix up the build process a litte.  No new functionality.
>
> It will be at http://search.cpan.org/~robertmay/Win32-GUI-SplashScreen-0.03/
> once search.cpan.org catches up.
>
> Regards,
> Rob.
>

Hey everyone,

 

Here is an alternative method for extracting a structure out of a wParam or lParam parameter. I pieced this together from various posts on the mailing list. This method is message specific and requires knowledge of the size and members of the specific structure. This example uses the WM_HELP message, which is sent when a user click the '?' button in the top-right corner:

 

$win->Hook(WM_HELP, sub {
  my ($this, $wParam, $lParam, $type, $msgcode) = @_;
  return unless $type == 0;
  return unless $msgcode == WM_HELP;
  my %helpinfo;
  #Here's how to get a stucture when only given a memory address:
  # 1. Pack the $lParam arg into a Long using pack "L" This turns the number into a usable memory address
  # 2. Unpack the result into a string using the size of the structure in bytes using unpack "P28"
  # 3. Unpack the result using the typedef for the structure and the appropriate pack formats
  @helpinfo{qw(cbSize iContextType iCtrlId hItemHandle dwContextId X Y)} = unpack("IiiLLll", unpack("P28", pack("L", $lParam)));
  #The internal Win32::GUI::GetWindowObject can get a window object from its handle
  my $control = Win32::GUI::GetWindowObject($helpinfo{hItemHandle});
  #process message...
  return 1;
 });

 

Remember, that if the structure contains any structures as parameters, they have to unpacked as well. For example, the X and Y above is part of a POINT structure.

 

Refer to the Windows SDK documentation for information about the various messages and structures.

 

Hope this helps.

 

Kevin.
 


Date: Sat, 18 Jul 2009 01:17:40 +0000
From: le...@we...
To: per...@li...
Subject: Re: [perl-win32-gui-users] Interpreting an lParam pointer

perl-win32-gui-users list,

I wrote:
> But how do I find and read the [COPYDATASTRUCT] structure pointed 
>    to by the integer $lParam ?

Well, I figured it out.
Here's a sub, not completely general, but handles the case
of a scalar message string.

Thanks for your indulgence.
(Maybe this will be useful for someone else searching the list archive.)

Cheers,
-Len

use Tie::Array::Pointer ;

sub read_COPYDATASTRUCT {
   ## input: $CopyData_p   (eg from an lParam)
   ## output (scalar): $Msg    (list): ($Msg, dwData_p)
   my $CopyData_p = shift ;

   my @CopyData_a ;
   tie @CopyData_a, 'Tie::Array::Pointer',
      {length => 3,    type   => 'L',    address => $CopyData_p } ;
   my ($dwData_p, $cbData_len, $lpData_p) = @CopyData_a ;

   my @Msg_a ;
   tie @Msg_a, 'Tie::Array::Pointer',
      {length => $cbData_len,  type   => 'C',  address => $lpData_p } ;

   pop @Msg_a if @Msg_a[-1] eq "\0" ;    ## pop off trailing null   (more??)
   my $Msg = pack "C$#Msg_a", @Msg_a ;
   wantarray ? ($Msg, $dwData_p)  : $Msg ;
}




On Jul 17, 2009, le...@we... wrote:


I am trying to use Win32::GUI from a Perl/Tk program
to receive and interpret a message sent from another window.

I have successfully set up a window to receive and a hook to
   handle the message.
   Using the example in Win32::GUI::Reference/Methods.pod, I have

 sub msg_handler {
    ($object, $wParam, $lParam, $type, $msgcode) = @_;
    print "Click handler called!\n";
 }

The result looks reasonable in the debugger, 
and $lParam is supposed to be a pointer to a WM_COPYDATA structure.

But how do I find and read the structure pointed to by the integer $lParam ?
I have a hunch that Win32::API::Struct could help, but I don't quite see how.

Thanks,
-Len

_________________________________________________________________
What goes online, stays online Check the daily blob for the latest on what's happening around the web
http://windowslive.ninemsn.com.au/blog.aspx

perl-win32-gui-users list,<br /><br />I wrote:<br />&gt; But how do I find and read the [COPYDATASTRUCT] structure pointed <br />&gt;&nbsp;&nbsp;&nbsp; to by the integer $lParam ?<br /><br />Well, I figured it out.<br />Here's a sub, not completely general, but handles the case<br />of a scalar message string.<br /><br />Thanks for your indulgence.<br />(Maybe this will be useful for someone else searching the list archive.)<br /><br />Cheers,<br />-Len<br /><br />use Tie::Array::Pointer ;<br /><br />sub read_COPYDATASTRUCT {<br />&nbsp;&nbsp; ## input: $CopyData_p&nbsp;&nbsp; (eg from an lParam)<br />&nbsp;&nbsp; ## output (scalar): $Msg&nbsp;&nbsp;&nbsp; (list): ($Msg, dwData_p)<br />&nbsp;&nbsp; my $CopyData_p = shift ;<br /><br />&nbsp;&nbsp; my @CopyData_a ;<br />&nbsp;&nbsp; tie @CopyData_a, 'Tie::Array::Pointer',<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {length =&gt; 3,&nbsp;&nbsp;&nbsp; type&nbsp;&nbsp; =&gt; 'L',&nbsp;&nbsp;&nbsp; address =&gt; $CopyData_p } ;<br />&nbsp;&nbsp; my ($dwData_p, $cbData_len, $lpData_p) = @CopyData_a ;<br /><br />&nbsp;&nbsp; my @Msg_a ;<br />&nbsp;&nbsp; tie @Msg_a, 'Tie::Array::Pointer',<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {length =&gt; $cbData_len,&nbsp; type&nbsp;&nbsp; =&gt; 'C',&nbsp; address =&gt; $lpData_p } ;<br /><br />&nbsp;&nbsp; pop @Msg_a if @Msg_a[-1] eq "\0" ;&nbsp;&nbsp;&nbsp; ## pop off trailing null&nbsp;&nbsp; (more??)<br />&nbsp;&nbsp; my $Msg = pack "C$#Msg_a", @Msg_a ;<br />&nbsp;&nbsp; wantarray ? ($Msg, $dwData_p)&nbsp; : $Msg ;<br />}<br /><br /><br /><br />
<p>On Jul 17, 2009, <strong>le...@we...</strong> wrote:</p>
<div class="replyBody">
<blockquote class="email_quote" style="border-left: 2px solid #267fdb; margin: 0pt 0pt 0pt 1.8ex; padding-left: 1ex;">I am trying to use Win32::GUI from a Perl/Tk program<br />to receive and interpret a message sent from another window.<br /><br />I have successfully set up a window to receive and a hook to<br />&nbsp;&nbsp; handle the message.<br />&nbsp;&nbsp; Using the example in Win32::GUI::Reference/Methods.pod, I have<br /><br />&nbsp;sub msg_handler {<br />&nbsp;&nbsp;&nbsp; ($object, $wParam, $lParam, $type, $msgcode) = @_;<br />&nbsp;&nbsp;&nbsp; print "Click handler called!\n";<br />&nbsp;}<br /><br />The result looks reasonable in the debugger, <br />and $lParam is supposed to be a pointer to a WM_COPYDATA structure.<br /><br />But how do I find and read the structure pointed to by the integer $lParam ?<br />I have a hunch that Win32::API::Struct could help, but I don't quite see how.<br /><br />Thanks,<br />-Len<br /></blockquote>
</div>

I am trying to use Win32::GUI from a Perl/Tk program<br />to receive and interpret a message sent from another window.<br /><br />I have successfully set up a window to receive and a hook to<br />&nbsp;&nbsp; handle the message.<br />&nbsp;&nbsp; Using the example in Win32::GUI::Reference/Methods.pod, I have<br /><br />&nbsp;sub msg_handler {<br />&nbsp;&nbsp;&nbsp; ($object, $wParam, $lParam, $type, $msgcode) = @_;<br />&nbsp;&nbsp;&nbsp; print "Click handler called!\n";<br />&nbsp;}<br /><br />The result looks reasonable in the debugger, <br />and $lParam is supposed to be a pointer to a WM_COPYDATA structure.<br /><br />But how do I find and read the structure pointed to by the integer $lParam ?<br />I have a hunch that Win32::API::Struct could help, but I don't quite see how.<br /><br />Thanks,<br />-Len<br />

Hi again,

While I am in a releasing mood, there's a new version of
Win32::GUI::SplashScreen on CPAN.

The only change is to fix up the build process a litte.  No new functionality.

It will be at http://search.cpan.org/~robertmay/Win32-GUI-SplashScreen-0.03/
once search.cpan.org catches up.

Regards,
Rob.

Hi all,

While I am in a releasing mood, there's a new version of
Win32::GUI::HyperLink on CPAN.

The only significant changes are:
- now depends on Win32::GUI 1.02, enabling removal of dependencies on
Win32::API, and simplifying the code a bit
- minor build fixes.

It will be at http://search.cpan.org/~robertmay/Win32-GUI-HyperLink-0.14/
once search.cpan.org catches up.

Regards,
Rob.

Hi
here is an example using the new Win32-GUI-OpenGLFrame , it is displaying
either a rotating triangle or a rotating cube when you click an appropriate
button.
yes thanks , i am sure this addition will be used heavily when the people
know about it.
here is the downloadable example:
http://rapidshare.com/files/256462790/cube_Triangle.pl

#!perl -w
use strict;
use warnings;
use Win32::GUI qw(WS_CLIPCHILDREN);
use Win32::GUI::OpenGLFrame qw(w32gSwapBuffers);
use OpenGL qw(:all);
my $spin = 0.0;
my $toggle = 0;
my $xrot = 0;
my $yrot = 0;
my $rtri  = 0.0;
my $rtcube = 0.0;
my $objectXRot = 0.0;
my $objectYRot = 0.0;
my $objectZRot = 0.0;
my $flag = 1;
my $mw = Win32::GUI::Window->new(
 -title => "OpenGL Demonstration",
 -pos   => [0,0],
 -size  => [640,480],
 -pushstyle => WS_CLIPCHILDREN,  # stop flickering on resize
 -onResize  => \&mainWinResize,
);
my $glw = $mw->AddOpenGLFrame(
 -name    => 'oglwin',
 -width   => $mw->ScaleWidth(),
 -height  => $mw->ScaleHeight() - 50,
 -display => \&display,
 -init    => \&Init,
 -reshape => \&reshape,
 -doubleBuffer => 1,
);

$mw->AddButton(
 -name => 'button1',
 -text => 'Triangle',
 -left => $mw->ScaleWidth()-100,
 -top  => $mw->ScaleHeight()-30,
 #-onClick => sub{-1},
);
$mw->AddButton(
 -name => 'button2',
 -text => 'Cube',
 -left => $mw->ScaleWidth()-140,
 -top  => $mw->ScaleHeight()-30,
 #-onClick => sub{-1},

);
$mw->Show();
while(Win32::GUI::DoEvents() != -1) {

    $mw->oglwin->InvalidateRect(0);
}
#Win32::GUI::Dialog();
$mw->Hide();
exit(0);
sub mainWinResize {
 my $win = shift;
 $win->oglwin->Resize($win->ScaleWidth(), $win->ScaleHeight()-50);
 $win->button1->Move($win->ScaleWidth()-100, $win->ScaleHeight()-30);
 $win->button2->Move($win->ScaleWidth()-160, $win->ScaleHeight()-30);
 return 0;
}
sub reshape {
 my ($w, $h) = @_;
 glViewport(0, 0, $w, $h);
 glMatrixMode (GL_PROJECTION);
 glLoadIdentity (); #  define the projection
 gluPerspective(45.0, $h ? $w/$h : 0, 1.0, 20.0);
 glMatrixMode(GL_MODELVIEW);
 glLoadIdentity();
 return 0;
}
sub Init {
    glShadeModel(GL_SMOOTH);
    glClearColor(0, 0, 0, 0);
    glClearDepth(1);
    glEnable(GL_DEPTH_TEST);
    glDepthFunc(GL_LEQUAL);
    glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);
    return 1;
}
sub display {
 glPushMatrix(); #save current matrix
    if ($flag == 1){DrawTriangle();} #draw triangle
    elsif ($flag == 2){DrawCube();}; #draw cube
    glPopMatrix(); #restore matrix
 glFlush();
    w32gSwapBuffers();
    return 1;
}
sub DrawTriangle {
 glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
    glLoadIdentity();
    glTranslatef(0.0, 0.0, -6.0);
    glRotatef($rtri, 0, 1, 0);
    my $size = 1;
    glScalef($size,$size,$size);
    glBegin(GL_TRIANGLES);
        glColor3f(1.0, 0.0, 0.0);
        glVertex3f(0.0, 1.0, 0.0);
        glColor3f(0.0, 1.0, 0.0);
     glVertex3f(-1.0, -1.0, 0.0);
        glColor3f(0.0, 0.0, 1.0);
     glVertex3f(1.0, -1.0, 0.0);
    glEnd();
    $rtri += 2;
             }
sub DrawCube {
  glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
  glLoadIdentity();
  my $size = 1;
  glTranslatef(0.0, 0.0, -6.0);
  glRotatef($objectXRot, 1.0, 0.0, 0.0);
  glRotatef($objectYRot, 0.0, 1.0, 0.0);
  glRotatef($objectZRot, 0.0, 0.0, 1.0);

  glScalef($size,$size,$size);
  glBegin(GL_QUADS);
   # bottom face
   glColor3f(0.0,0.0,0.0);    #black
   glVertex3f(-1.0,-1.0,-1.0);
   glColor3f(1.0,0.0,0.0);    #red
   glVertex3f(1.0,-1.0,-1.0);
   glColor3f(1.0,0.0,1.0);    #magenta
   glVertex3f(1.0,-1.0,1.0);
   glColor3f(0.0,0.0,1.0);    #blue
   glVertex3f(-1.0,-1.0,1.0);
   # front face
   glColor3f(0.0,0.0,0.0);    #black
   glVertex3f(-1.0,-1.0,-1.0);
   glColor3f(0.0,1.0,0.0);    #green
   glVertex3f(-1.0,1.0,-1.0);
   glColor3f(1.0,1.0,0.0);    #yellow
   glVertex3f(1.0,1.0,-1.0);
   glColor3f(1.0,0.0,0.0);    #red
   glVertex3f(1.0,-1.0,-1.0);
   # right face
   glColor3f(0.0,0.0,0.0);    #black
   glVertex3f(-1.0, -1.0, -1.0);
   glColor3f(0.0,0.0,1.0);    #blue
   glVertex3f(-1.0,-1.0,1.0);
   glColor3f(0.0,1.0,1.0);    #cyan
   glVertex3f(-1.0,1.0,1.0);
   glColor3f(0.0,1.0,0.0);    #green
   glVertex3f(-1.0,1.0,-1.0);
   # left face
   glColor3f(1.0,1.0,1.0);    #white
   glVertex3f(1.0,1.0,1.0);
   glColor3f(1.0,0.0,1.0);    #magenta
   glVertex3f(1.0,-1.0,1.0);
   glColor3f(1.0,0.0,0.0);    #red
   glVertex3f(1.0,-1.0,-1.0);
   glColor3f(1.0,1.0,0.0);    #yellow
   glVertex3f(1.0,1.0,-1.0);
   # top face
   glColor3f(1.0,1.0,1.0);    #white
   glVertex3f(1.0,1.0,1.0);
   glColor3f(1.0,1.0,0.0);    #yelllow
   glVertex3f(1.0,1.0,-1.0);
   glColor3f(0.0,1.0,0.0);    #green
   glVertex3f(-1.0,1.0,-1.0);
   glColor3f(0.0,1.0,1.0);    #cyan
   glVertex3f(-1.0,1.0,1.0);
   # back face
   glColor3f(1.0,1.0,1.0);    #white
   glVertex3f(1.0,1.0,1.0);
   glColor3f(0.0,1.0,1.0);    #cyan
   glVertex3f(-1.0,1.0,1.0);
   glColor3f(0.0,0.0,1.0);    #blue
   glVertex3f(-1.0,-1.0,1.0);
   glColor3f(1.0,0.0,1.0);    #magenta
   glVertex3f(1.0,-1.0,1.0);

  glEnd();
  $objectXRot += 0.5;
  $objectYRot += 0.5;
  $objectZRot += 0.5;

  }
sub button1_Click {
  $flag = 1;
 }

 sub button2_Click {
  $flag = 2;
 }

Hi
Win32-GUI-OpenGLFrame is an important adition to the win32::GUI, which will
be recognized over the years.
i have installed it using vc6++  without problems on win32gui v1.06 -
activeperl 510 - winxp
i will try it and post my findings.
peter

2009/7/15 eros-9 <ero...@ho...>:
> when i close any of the examples in the demos, i get a message:
> (in cleanup) Can't call method "FETCH" on an undefined value at
> c:/perl/site/lib/Win32/GUI/OpenGLFrame.pm line 108 during global
> destruction.

What version of Win32::GUI?

When this error occurs it's down to destruction happening in an
unexpected order during perl's global cleanup at program exit.  It can
nearly always be mitigated by undef'ing the variable holding the main
window object before program exit.   It's a Win32::GUI problem, not a
Win32::GUI::OpenGLFrame problem.  I've looked into it pretty closely
in the past, and it's pretty difficult to fix with the current
code-base.

Glad you like it.

Rob.

this is like the sweets over the cake, thank you.
a small note:
when i close any of the examples in the demos, i get a message:
(in cleanup) Can't call method "FETCH" on an undefined value at
c:/perl/site/lib/Win32/GUI/OpenGLFrame.pm line 108 during global
destruction.
regards
eros olmi


Robert May-6 wrote:
> 
> All,
> 
> Following the discussions on the list recently about Win32::GUI and
> OpenGL I just tidied up and released some code that I wrote a number
> of years ago.  I'm certainly not an OpenGL expert, so would appreciate
> anyone having  look at the source and commenting.
> 
> I think this is fairly powerful, and whilst the documentation is
> probably technically complete, I'm not sure it tell the whole story -
> the demos that I've ported to Win32::GUI and included in the
> distribution are probably important reading.
> 
> Comments welcome, as always - and if anyone with a bigger OpenGL itch
> than I have wants to take this over, I'm more than happy to give
> anyone else co-ownership on CPAN - I doubt that I'll revisit this
> unless there's a big demand.
> 
> You'll need a C compiler to build it - or if you wait a few days it
> should mke it into ActiveState's PPM repository.
> 
> My apologies to those who have posted code to the list recently that I
> haven't reviewed - if your code is significantly different fro what
> I've done, then some benchmarking (or otherwise) may be in order to
> determine the best way to proceed.
> 
> Cheers,
> Rob.
> 
> CPAN: http://search.cpan.org/~robertmay/Win32-GUI-OpenGLFrame-0.01/
> GitHUb: http://github.com/remay/perl-win32-gui-openglframe
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full
> prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
> 
> 

-- 
View this message in context: http://www.nabble.com/ANNOUNCE%3A-Win32%3A%3AGUI%3A%3AOpenGLFrame-V0.01-tp24484181p24493354.html
Sent from the perl-win32-gui-users mailing list archive at Nabble.com.

[For some reason this appears not to have reached the list - retrying.]

All,

Back in May there was a discussion on this list about Visual Styles
(aka XP Styles).  Up to now we have been coping with applying style by
copying a manifest file into the perl bin directory.  This is
unsatisfactory for a number of reasons.

(1) It is difficult to make this work when packing executables (usinfg
PAR for example)
(2) It is difficult to test both with and without visual styles -
especially now that Vista may cache the manifest
(3) It is a continual problem with keeping newcomers informed with how
to do this.

I have created a module, Win32::VisualStyles, that allows you do apply
a "V6 Common Control Activation Context" (to use some of the buzz
words) at run-time.  In particular this means that it is easy to pack
an executable - it's just another dependency - and it's easy to test
with and without visual styles simply by adding
"-MWin32::VisualStyles" to the commandline.

V0.02 is currently propagating to CPAN.   The only differences from
V0.01 are to cope better with the build process - there is no internal
difference to the code that runs.

You can download the source from CPAN and build it:
http://search.cpan.org/~robertmay/Win32-VisualStyles-0.01/
or it should be available for 5.8 and 5.10 from ActiveState's new PPM
repository.

Full documentation included with the module, but let me know if you
need any further help.

Regards,
Rob.

2009/7/14 Glenn Linderman <pe...@ne...>:
>> I maintain phpwiki on sf.net and it gets worse and worse.
>
> Could you elaborate?  I'm not sure what this is.

For years we could host phpwiki on the sf.net webservers but then
they removed the cronjobs, then the shared NFS disc, then the shell,
then persistent mysql was broken, then their webserver proxy could not
deal anymore with our app leading
to cpu-eating cycles in various subrequest scenarios, and
now the layout change.
-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

Kevin et al.,

Many thanks for taking a look at this, it is certainly true that the
documentation is lacking in many areas.   I haven't been able to look
at the work you've done, as none of the mail I have seen have any
attachments (it's possible that the SourceForge mail ing list strip
zip files?)

Whilst I am not going to try to stop any activity in this area, I have
some observations that you may choose to guide your activities:

(1) My supply of tuits is very small, so I doubt that I will contribute much.
(2) I am happy to give a commit bit to anyone who wants to commit
changes to the core source code.
(3) For the core documentation (i.e. functional documentation of the
classes/methods within the Win32::GUI distribution) I'd like to see
the docs reside within the source repository and be distributed with
Win32::GUI.   Fundamentally this means writing POD (which gets
converted to HTML during the build process) or embedded docs as we
currently have, with a suitable toolset for pulling the embedded docs
into pod during the build[1].  An investigation into what other larger
projects do might be worthwhile.
(4) For other documentation (Tutorials etc) I am less concerned that
they are kept in the core source, but would propose that they be
hosted somewhere related to the project - as a first suggestion I'd be
happy to give someone enough permissions to have a play with the
hosted apps that SourceForge now offer (which weren't available last
time I looked).  There's certainly wiki and other documentation tools
available there.   Of course, it may be that none of the offered
solutions suit us.
(5) For experience, if we don't find a way to merge your changes in to
the core documentation, or host them somewhere where someone else can
take over maintenance, then they will drop into disuse over time.   It
is my experience that the closer you can put the documentation to the
code it is documenting, the more likely that it will be kept up to
date.


Finally, I am also seeking someone who would be happy to take over the
maintenance of the Win32::GUI website - it could do with a re-vamp and
some TLC.  Any takers?   This work might tie in nicely with moving us
over to a new Wiki (or similar).

Thanks for all the interest.
Rob.

[1] It would actually be better to have the embedded docs pulled into
POD before the build, so that source distributions to CPAN get their
POD displayed properly.

2009/7/14 Glenn Linderman <pe...@ne...>:
> On approximately 7/13/2009 12:51 AM, came the following characters from
> the keyboard of Reini Urban:
>> 2009/7/13 Glenn Linderman <pe...@ne...>:
>>
>>> So at the present time, I'm not sure
>>> 1) if there are any active developers
>>> 2) if there are any that would agree that moving the documentation to
>>> separate files would be a good thing
>>> 3) who would apply your documentation patches to the repository, even if
>>> you submitted them that way, rather than creating your own web site
>>>
>>> I don't remember if Reini has a commit bit or not,
>>>
>>
>> No, I don't think I have a commit bit.
>>
>>
>>> but I don't think he's ever built a release.
>>>
>>
>> No, I'm doing all the cygwin releases since years.
>>
>
> That's right!  I knew you were involved somehow, but couldn't remember
> how.  Of course building the cygwin package, is taking a release, and
> building and packaging it.  Really, building a release is likely simple,
> although likely changed since I last did it, in the sense of the file
> manipulations required, but the hard part comes in doing sufficient
> testing to be convinced that it is a good release.  And there are more
> parts now than last I did it.  I worked only on very focused bug fixes,
> even then.
>
>>> There have been significant changes to
>>> sourceforge in the intervening period, as well, so it would take some
>>> learning curve for me (and probably for Reini, although maybe he's up on
>>> the sourceforge changes from other projects) to attempt to build a
>>> release, methinks.  Or maybe Rob will poke his head in here, and say
>>> that he could find some time to commit some doc changes and build a new
>>> release...
>>>
>>
>> I maintain phpwiki on sf.net and it gets worse and worse.
>>
>
> Could you elaborate?  I'm not sure what this is.
>
>> But posting releases is still simple.
>>
>
> That sounds good.
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>

All,

Following the discussions on the list recently about Win32::GUI and
OpenGL I just tidied up and released some code that I wrote a number
of years ago.  I'm certainly not an OpenGL expert, so would appreciate
anyone having  look at the source and commenting.

I think this is fairly powerful, and whilst the documentation is
probably technically complete, I'm not sure it tell the whole story -
the demos that I've ported to Win32::GUI and included in the
distribution are probably important reading.

Comments welcome, as always - and if anyone with a bigger OpenGL itch
than I have wants to take this over, I'm more than happy to give
anyone else co-ownership on CPAN - I doubt that I'll revisit this
unless there's a big demand.

You'll need a C compiler to build it - or if you wait a few days it
should mke it into ActiveState's PPM repository.

My apologies to those who have posted code to the list recently that I
haven't reviewed - if your code is significantly different fro what
I've done, then some benchmarking (or otherwise) may be in order to
determine the best way to proceed.

Cheers,
Rob.

CPAN: http://search.cpan.org/~robertmay/Win32-GUI-OpenGLFrame-0.01/
GitHUb: http://github.com/remay/perl-win32-gui-openglframe

On approximately 7/13/2009 12:51 AM, came the following characters from 
the keyboard of Reini Urban:
> 2009/7/13 Glenn Linderman <pe...@ne...>:
>   
>> So at the present time, I'm not sure
>> 1) if there are any active developers
>> 2) if there are any that would agree that moving the documentation to
>> separate files would be a good thing
>> 3) who would apply your documentation patches to the repository, even if
>> you submitted them that way, rather than creating your own web site
>>
>> I don't remember if Reini has a commit bit or not,
>>     
>
> No, I don't think I have a commit bit.
>
>   
>> but I don't think he's ever built a release.
>>     
>
> No, I'm doing all the cygwin releases since years.
>   

That's right!  I knew you were involved somehow, but couldn't remember 
how.  Of course building the cygwin package, is taking a release, and 
building and packaging it.  Really, building a release is likely simple, 
although likely changed since I last did it, in the sense of the file 
manipulations required, but the hard part comes in doing sufficient 
testing to be convinced that it is a good release.  And there are more 
parts now than last I did it.  I worked only on very focused bug fixes, 
even then.

>> There have been significant changes to
>> sourceforge in the intervening period, as well, so it would take some
>> learning curve for me (and probably for Reini, although maybe he's up on
>> the sourceforge changes from other projects) to attempt to build a
>> release, methinks.  Or maybe Rob will poke his head in here, and say
>> that he could find some time to commit some doc changes and build a new
>> release...
>>     
>
> I maintain phpwiki on sf.net and it gets worse and worse.
>   

Could you elaborate?  I'm not sure what this is.

> But posting releases is still simple.
>   

That sounds good.

I'm willing to host the web site. I have extra space and bandwidth for 
this project.

per...@li... wrote:
> Send Perl-Win32-GUI-Users mailing list submissions to
> 	per...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> or, via email, send a message with subject or body 'help' to
> 	per...@li...
>
> You can reach the person managing the list at
> 	per...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Perl-Win32-GUI-Users digest..."
>
>
> Today's Topics:
>
>    1. Re: Win32::GUI Documentation (Reini Urban)
>    2. Re: Win32::GUI Documentation (Reini Urban)
>    3. Re: Win32::GUI Documentation (Kevin Marshall)
>    4. Re: Win32::GUI Documentation (Glenn Linderman)
>    5. Re: Win32::GUI Documentation (Kevin Marshall)
>    6. Re: Win32::GUI Documentation (Glenn Linderman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 12 Jul 2009 14:12:35 +0200
> From: Reini Urban <ru...@x-...>
> Subject: Re: [perl-win32-gui-users] Win32::GUI Documentation
> To: Kevin Marshall <kej...@ho...>
> Cc: Perl-Win32-GUI-Users List
> 	<per...@li...>
> Message-ID: <4A5...@x-...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Kevin Marshall schrieb:
>   
>> Hey everyone,
>>  
>> After digging through the Win32::GUI source and Win32 API Documentation, 
>> I have created some updated Win32::GUI documentation. Let's face it, the 
>> docs are lacking in some areas, so I decided to add to some of the 
>> information that is provided.
>>  
>> If anyone would like a copy of the updated docs, send me an email 
>> directly (off the mailing lists). If anyone has any questions, comments, 
>> or suggestions about the docs, please post them on the mailing lists.
>>  
>> These docs are a work in progress, so if anyone has any ideas for any 
>> extra content that could be included, such as more tutorials, I would be 
>> happy to look into it.
>>     
>
> Where is the patch? The documentation is mainly just POD.
>   

-- 
NEW FILE UPLOADER ADDED

Richard Noble
IBK Software
T: 646-807-2228
F: 646-536-3180
C: 917-642-9850
rp...@ib...

To upload files use this link: http://www.ibksoftware.com/fileloader/

419 West 154 Street
New York, NY 10032

This e-mail is IBK Software confidential and may not be redistributed without permission of IBK Software. 

2009/7/13 Glenn Linderman <pe...@ne...>:
> So at the present time, I'm not sure
> 1) if there are any active developers
> 2) if there are any that would agree that moving the documentation to
> separate files would be a good thing
> 3) who would apply your documentation patches to the repository, even if
> you submitted them that way, rather than creating your own web site
>
> I don't remember if Reini has a commit bit or not,

No, I don't think I have a commit bit.

> but I don't think he's ever built a release.

No, I'm doing all the cygwin releases since years.

> There have been significant changes to
> sourceforge in the intervening period, as well, so it would take some
> learning curve for me (and probably for Reini, although maybe he's up on
> the sourceforge changes from other projects) to attempt to build a
> release, methinks.  Or maybe Rob will poke his head in here, and say
> that he could find some time to commit some doc changes and build a new
> release...

I maintain phpwiki on sf.net and it gets worse and worse.
But posting releases is still simple.
-- 
Reini Urban
http://phpwiki.org/           http://murbreak.at/

I haven't read the new docs either, and can only speak as a user of
Win32::GUI, but I do use it a lot, and find the current doc situation
challenging.

The Right Thing To Do is probably fixing the POD, but right often gets
in the way of done. If correct docs can be posted somewhere, that's
better than nothing. I'm willing to help out insofar as I can.

Jack

On 7/12/09, Glenn Linderman <pe...@ne...> wrote:
> On approximately 7/12/2009 7:49 PM, came the following characters from
> the keyboard of Kevin Marshall:
>> Glenn,
>>
>> Yes, you're right, the documentation for the module is contained
>> within the source code and is extracted during the build process. For
>> a module this large, it probably made sense in the beginning to use
>> this method to create the docs, but as the module has grown, I imagine
>> it has become more difficult to manage. Perhaps moving the
>> documentation into their own files is something for the developers to
>> look at for the next release. Most of the changes I made to the docs
>> involved replacing the TBD sections with the required information, as
>> well as supplying more information about input parameters and return
>> values for most of the functions.
>
> Seems to me that the larger a project gets, the better it is for the
> documents to be in the source... because if something is changing in the
> code, the change to the documentation is right there too.
>
> However, you seem to hold the opinion that having separate documentation
> files would be better in some unstated way?
>
> I haven't had a chance to read your updated docs, but the kinds of
> changes you describe sound extremely helpful.
>
> While I hold a commit bit to the repository, and have made some minor
> bug fixes in the past, the primary developer in recent years has been
> Rob May... but I think he got busy with other things, and hasn't been
> very active here lately, which is sad for this module, as he was doing
> some excellent things to it.
>
> So at the present time, I'm not sure
> 1) if there are any active developers
> 2) if there are any that would agree that moving the documentation to
> separate files would be a good thing
> 3) who would apply your documentation patches to the repository, even if
> you submitted them that way, rather than creating your own web site
>
> I don't remember if Reini has a commit bit or not, but I don't think
> he's ever built a release.  There have been significant changes to
> sourceforge in the intervening period, as well, so it would take some
> learning curve for me (and probably for Reini, although maybe he's up on
> the sourceforge changes from other projects) to attempt to build a
> release, methinks.  Or maybe Rob will poke his head in here, and say
> that he could find some time to commit some doc changes and build a new
> release...
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>
>

-- 
Sent from my mobile device

"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

On approximately 7/12/2009 7:49 PM, came the following characters from 
the keyboard of Kevin Marshall:
> Glenn,
>  
> Yes, you're right, the documentation for the module is contained 
> within the source code and is extracted during the build process. For 
> a module this large, it probably made sense in the beginning to use 
> this method to create the docs, but as the module has grown, I imagine 
> it has become more difficult to manage. Perhaps moving the 
> documentation into their own files is something for the developers to 
> look at for the next release. Most of the changes I made to the docs 
> involved replacing the TBD sections with the required information, as 
> well as supplying more information about input parameters and return 
> values for most of the functions.

Seems to me that the larger a project gets, the better it is for the 
documents to be in the source... because if something is changing in the 
code, the change to the documentation is right there too.

However, you seem to hold the opinion that having separate documentation 
files would be better in some unstated way?

I haven't had a chance to read your updated docs, but the kinds of 
changes you describe sound extremely helpful.

While I hold a commit bit to the repository, and have made some minor 
bug fixes in the past, the primary developer in recent years has been 
Rob May... but I think he got busy with other things, and hasn't been 
very active here lately, which is sad for this module, as he was doing 
some excellent things to it.

So at the present time, I'm not sure
1) if there are any active developers
2) if there are any that would agree that moving the documentation to 
separate files would be a good thing
3) who would apply your documentation patches to the repository, even if 
you submitted them that way, rather than creating your own web site

I don't remember if Reini has a commit bit or not, but I don't think 
he's ever built a release.  There have been significant changes to 
sourceforge in the intervening period, as well, so it would take some 
learning curve for me (and probably for Reini, although maybe he's up on 
the sourceforge changes from other projects) to attempt to build a 
release, methinks.  Or maybe Rob will poke his head in here, and say 
that he could find some time to commit some doc changes and build a new 
release...

Glenn,

 

Yes, you're right, the documentation for the module is contained within the source code and is extracted during the build process. For a module this large, it probably made sense in the beginning to use this method to create the docs, but as the module has grown, I imagine it has become more difficult to manage. Perhaps moving the documentation into their own files is something for the developers to look at for the next release. Most of the changes I made to the docs involved replacing the TBD sections with the required information, as well as supplying more information about input parameters and return values for most of the functions.

 

Kevin.

 
> Date: Sun, 12 Jul 2009 18:23:30 -0700
> From: pe...@ne...
> To: kej...@ho...
> CC: ru...@x-...; per...@li...
> Subject: Re: [perl-win32-gui-users] Win32::GUI Documentation
> 
> On approximately 7/12/2009 5:41 PM, came the following characters from 
> the keyboard of Kevin Marshall:
> > Reini,
> > 
> > I understand where you are coming from, a diff would make replacement 
> > of the original files easier. I was, however, considering a complete 
> > rewrite of the documentation, including the structure, which would 
> > make patching the existing files interesting. An alternative would be 
> > to copy my docs over the docs generated in the build process, before 
> > doing "make install". Another way would be to edit the makefile to 
> > prevent the docs being generated, then move my docs into their place, 
> > then do "make install". For those people who use the PPMs they 
> > have less options. The best they can do is copy my docs over the 
> > originals after installing the PPM. It was suggested I set up a 
> > dedicated website for the documentation. This would certainly overcome 
> > any of these problems.
> 
> Well, a dedicated website for the documentation only works-around these 
> problems. I think presently the source for the documentation is in the 
> source code files for the modules. If that is preserved, it is more 
> likely that the documentation will get updated when the code gets updated.
> 
> Even if you do a complete rewrite of the documentation, if it is not 
> integrated with the module source in some way, it will likely not get 
> maintained over time.
> 
> That said, I agree that the documentation could use some help; last I 
> looked at it, there were lots of TBD areas.
> 
> 

_________________________________________________________________
View photos of singles in your area Click Here
http://dating.ninemsn.com.au/search/search.aspx?exec=go&tp=q&gc=2&tr=1&lage=18&uage=55&cl=14&sl=0&dist=50&po=1&do=2&trackingid=1046138&r2s=1&_t=773166090&_r=WLM_EndText

On approximately 7/12/2009 5:41 PM, came the following characters from 
the keyboard of Kevin Marshall:
> Reini,
>  
> I understand where you are coming from, a diff would make replacement 
> of the original files easier. I was, however, considering a complete 
> rewrite of the documentation, including the structure, which would 
> make patching the existing files interesting. An alternative would be 
> to copy my docs over the docs generated in the build process, before 
> doing "make install". Another way would be to edit the makefile to 
> prevent the docs being generated, then move my docs into their place, 
> then do "make install". For those people who use the PPMs they 
> have less options. The best they can do is copy my docs over the 
> originals after installing the PPM. It was suggested I set up a 
> dedicated website for the documentation. This would certainly overcome 
> any of these problems.

Well, a dedicated website for the documentation only works-around these 
problems.  I think presently the source for the documentation is in the 
source code files for the modules.  If that is preserved, it is more 
likely that the documentation will get updated when the code gets updated.

Even if you do a complete rewrite of the documentation, if it is not 
integrated with the module source in some way, it will likely not get 
maintained over time.

That said, I agree that the documentation could use some help; last I 
looked at it, there were lots of TBD areas.