perl-win32-gui-users — Using the Win32::GUI Perl extension

Re: [perl-win32-gui-users] Win32::GUI + OpenGL

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

> I have also experimented with OpenGL and Win32::GUI. I started to
> write a module to integrate the two, but never completed it - I did
> get it running though, and successfully ported most of the examples
> that some with the OpenGL module.

I've played with this too. Got the basics working, but found OpenGL (and DirectX for that matter) to heavy for what I needed at the time (fast simple 2D graphics).
 
> I'll make make my code available sometime next week, once I get back
> home; if anyone wants to pick this up I can give some direction on
> what needs doing to complete it.

Nice. 

Win32::GUI::OpenGL then? :)

> Rob.
> 

[snip]

> >> It is possible to create child windows that are rendered to using OpenGL
> >> instead of rendering to the parent window, but requires a lot more setup.
> >> One of the tricks needed is to specify the right styles for the window. I
> >> have yet to perfect this technique, but perhaps when I get it working
> >> correctly I'll post an example.

Good work - and thanks for the example. 

Feel free to drop me a mail off list as I can probably help here - I have got a 3rd party C++ graphics module painting into a Win32::GUI child window.

Cheers,

Jeremy.
_________________________________________________________________
View your Twitter and Flickr updates from one place – Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/

Re: [perl-win32-gui-users] Win32::GUI + OpenGL

[Robert M. <rob...@us...>]

I have also experimented with OpenGL and Win32::GUI.   I started to
write a module to integrate the two, but never completed it - I did
get it running though, and successfully ported most of the examples
that some with the OpenGL module.

I'll make make my code available sometime next week, once I get back
home;  if anyone wants to pick this up I can give some direction on
what needs doing to complete it.

Rob.

2009/5/22 Jason Plum <ma...@wa...>:
> May I be lucky enough to pick my ass up and put it back onto my chair, then
> also say thanks for the well documented and detailed example!
>
> I myself have toyed with OpenGL via perl before, but have never thought of
> combining it with Win32::GUI myself. Seeing as I'm a  maintainer for a game,
> and some people have asked for updated tools with animations from said
> game.. I may someday put this example to a very literal use.
> Thanks again,
> Jason P
>
> On Thu, May 21, 2009 at 11:18 PM, Kevin Marshall <kej...@ho...>
> wrote:
>>
>> Hey,
>>
>> This lengthy post is about how to use the Win32::GUI module together with
>> the Perl OpenGL module (POGL).
>>
>> I would first like to thank the developers of Perl-Win32-GUI module. I
>> have been using this module for a while now, and prefer using this module
>> than coding the whole thing in C/C++. Thanks. I have decided to give back
>> to the Win32::GUI community by way of sharing a solution for using OpenGL in
>> conjunction with the Win32::GUI module. I hope that someone out there will
>> find this useful.
>>
>> After reading the book OpenGL Game Programming (Premier Press), I decided
>> to port some of the code examples to Perl. Since the Win32::GUI module makes
>> the creation of windows easy, it was simply a matter of converting the
>> relevant C/C++ code into Perl. A basic knowledge of OpenGL is needed in
>> order to understand the example that I have provided. The example contains
>> comments that should explain what each section does, but I'll provide a
>> brief overview of the process. I'll only be discussing the Windows+OpenGL
>> specific code, so if you don't have a good grasp of OpenGL, I recommend
>> finding a good book or website about OpenGL programming before going any
>> further. Detailed information regarding Windows API functions, and OpenGL
>> functions can be found in the Windows Software Development Kit
>> Documentation.
>>
>> OpenGL is a powerful, low-level rendering and modelling software library.
>> OpenGL does not provide higher functionality, such as windowing, in order to
>> remain platform independent. OpenGL uses a rendering context to store OpenGL
>> commands and settings. This means that each platform must provide
>> functionality to specify a rendering context for OpenGL. For UNIX systems,
>> this is provided by GLX. For Windows this is provided by a set of functions
>> affectionately known as 'wiggle' functions, since most of these start with
>> 'wgl'. There are a number of other Win32 API functions that are also needed.
>> These 'wiggle' and Win32 API functions relate Windows Device Contexts with
>> the OpenGL rendering contexts. The Win32::API module is needed to import
>> these functions for use in the program.
>>
>> Example Program Description:
>>
>> Lines 21-51 show some setup required for the functions that are to be
>> imported. This includes creating the structure PIXELFORMATDESCRIPTOR used
>> by the SetPixelFormat() function and creating a typedef for the
>> wglMakeCurrent() function. Lines 52-63 show the functions that need to be
>> imported. Info on these functions can be found in the SDK docs.
>>
>> Lines 64-100 creates the main window and sets its icon. This should be
>> fairly basic for anyone experienced with the Win32::GUI module, so I'll just
>> cover the important parts. Line 68 sets the -left of the window to
>> CW_USEDEFAULT. This specifies that the system should position the window.
>> Lines 69-71 add the window styles WS_CLIPCHILDREN  and WS_CLIPSIBLINGS.
>> These affect how the window will be painted. For more info about these
>> styles, see the SDK docs. Lines 72-76 setup an -onTerminate event handler.
>> This will be called when the window is destroyed. At this point the
>> rendering context is deselected from the main window Device Context and is
>> then deleted. More on these functions later. Just know that each takes a
>> handle to a device or rendering context. The sub returns -1 to exit the main
>> loop. For those of you familiar with C/C++ Windows programming, this
>> function roughly corresponds to the WM_CLOSE message. Lines 77-90 setup an
>> -onResize event handler. This is called whenever the window is resized and
>> corresponds to the WM_SIZE message. The functions in the sub are OpenGL
>> specific and basically just reset the viewport to the new dimensions and
>> resets the perspective. Refer to the SDK docs or a good OpenGL resource for
>> info about these functions. Lines 91-95 setup a -onKeyDown event handler
>> which exits the program when the ESC key is pressed.
>>
>> Lines 101-106 are where the device and rendering contexts are setup. Line
>> 101 gets the device context of the main window and stores it in a global
>> variable. Lines 102-104 calls the SetupPixelFormat() function, passing it
>> the handle to the main window device context. If this sub fails the program
>> exits. Lines 116-157 show the SetupPixelFormat() function. Line 119 creates
>> a new PIXELFORMATDESCRIPTOR structure and lines 120-147 fills the structure
>> with appropriate data. See the SDK docs for more info about this structure.
>> Lines 148-151 calls the ChoosePixelFormat() function passing the handle to
>> the DC and the PIXELFORMATDESCRIPTOR structure. This function chooses the
>> best matching pixel format for the DC from the data specified in the
>> PIXELFORMATDESCRIPTOR structure. The function returns 0 if not pixel format
>> can be found. Lines 152-155 set the pixel format of the DC to the format
>> returned from the ChoosePixelFormat() function and returns 0 if it fails.
>> The sub returns 1 to show that it succeeded.  Line 105 creates an OpenGL
>> rendering context from the specified DC using the wglCreateContext()
>> function. The function is passed the handle to the main window DC and
>> returns the handle to a rendering context. Line 106 selects the rendering
>> context into the device context using the wglMakeCurrent() function. This
>> functions is passed the handle to the main window DC and the handle to the
>> rendering context created with wglCreateContext(). Passing 0 as the
>> rendering context causes the rendering context to be deselected, such as in
>> the -onTerminate event handler above. The wglDeleteContext() function is
>> used to delete a rendering context and should be used after the rendering
>> context has been deselected. The deselection and deletion of a rendering
>> context should be performed when a window is destroyed, which is why this is
>> done in the -onTerminate event handler above. Lines 101-106 could be thought
>> of as equivalent to the WM_CREATE message (you could even use the Hook()
>> method to implement this).
>>
>> Lines 107-111 show some basic setup of OpenGL before any rendering is
>> done. These are OpenGL specific, so if you are unsure of what these do,
>> refer to the docs.
>>
>> Lines 113-115 setup the main message loop. Win32::GUI::Dialog() can't be
>> used here because the Render() function has to be called every frame. This
>> loop is essentially the same, but a few differences are present which may
>> affect applications with multiple windows, since the Win32::GUI::Dialog()
>> functions does more behind the scenes. It would be nice if the
>> Win32::GUI::Dialog() function accepted a sub ref which could be called every
>> frame, but I'm not sure how easy that would be to create. Anyway, this does
>> the job fine, but there are probably better methods.
>>
>> Lines 158-172 and 173-188 are the DrawCube() and Render() functions,
>> respectively. These are used to draw the cube every frame and are OpenGL
>> specific. Refer to the docs about what the OpenGL functions do if you are
>> unsure.
>>
>> Line 189-193 creates a Handle() method in the Win32::GUI::DC package. This
>> method returns the handle of the object passed in. Putting it in the DC
>> package allows both windows and DCs to access it. This method is used when
>> the OpenGL/Win32API function requires a handle. Since the objects store in
>> handle internally, it makes it really easy to pass this value to the
>> functions that need it.
>>
>> Here is my code example:
>>
>>
>> ################################################################################
>> #
>> # Win32::GUI + OpenGL example
>> #
>> # This program demonstrates a basic example of using the Perl Win32::GUI
>> #  module in conjunction with the Perl OpenGL module to render a spinning
>> #  cube of points in the window.
>> #
>> # Requirements:
>> #  Perl,
>> #  Win32::GUI,
>> #  Win32::GUI::Carp,
>> #  Win32::API, and
>> #  OpenGL
>> #
>> # This program was written using ActiveState Perl 5.8.8 Build 820 running
>> on
>> #  Windows XP and using Win32::GUI v1.06, Win32::GUI::Carp v1.01,
>> #  Win32::API v0.46, and OpenGL v0.56
>> #
>> # Parts of this program are based on example code from the book OpenGL
>> Game
>> #  Programming (Premier Press, 2004) from the Premier Press Game
>> #  Development Series. I recommend this book for anyone interested in
>> using
>> #  OpenGL for developing games on Windows. The book is written for the
>> #  development of games written in C/C++ and assumes an advanced knowledge
>> #  of the language but provides an in-depth look at OpenGL programming on
>> #  Windows platforms, as well as a look at using DirectInput and
>> #  DirectX Audio.
>> #
>>
>> ################################################################################
>>
>> 1: use strict;
>> 2: use warnings;
>> #these constants are needed for SetPixelFormat() but aren't defined in
>> Win32::GUI
>> 3: use constant {
>> 4:  PFD_TYPE_RGBA => 0,
>> 5:  PFD_DOUBLEBUFFER => 0x00000001,
>> 6:  PFD_DRAW_TO_WINDOW => 0x00000004,
>> 7:  PFD_SUPPORT_OPENGL => 0x00000020,
>> 8:  PFD_MAIN_PLANE => 0,
>> 9: };
>>
>> 10: use OpenGL qw(:glfunctions :glconstants :glufunctions);
>> 11: use Win32::API;
>> 12: use Win32::GUI qw();
>> 13: use Win32::GUI::Carp qw(warningsToDialog fatalsToDialog
>> immediateWarnings winwarn windie);
>> 14: use Win32::GUI::Constants qw(IDI_APPLICATION WS_CLIPCHILDREN
>> WS_CLIPSIBLINGS
>> 15:  WM_CREATE WM_SIZE WM_CLOSE VK_ESCAPE CW_USEDEFAULT MB_OK
>> MB_ICONEXCLAMATION);
>>
>> 16: my $g_HDC;  #global handle to device context
>> 17: my $hRC;  #handle to rendering context
>>
>> #keep track of rotation of cube
>> 18: my $objectXRot = 0.0;
>> 19: my $objectYRot = 0.0;
>> 20: my $objectZRot = 0.0;
>>
>> #define PIXELFORMATDESCRIPTOR struct used for the SetPixelFormat function
>> #refer to the Windows SDK documentation for more info about this structure
>> 21: Win32::API::Struct->typedef(
>> 22:  PIXELFORMATDESCRIPTOR => qw(
>> 23:   WORD nSize;
>> 24:   WORD nVersion;
>> 25:   DWORD dwFlags;
>> 26:   BYTE iPixelType;
>> 27:   BYTE cColorBits;
>> 28:   BYTE cRedBits;
>> 29:   BYTE cRedShift;
>> 30:   BYTE cGreenBits;
>> 31:   BYTE cGreenShift;
>> 32:   BYTE cBlueBits;
>> 33:   BYTE cBlueShift;
>> 34:   BYTE cAlphaBits;
>> 35:   BYTE cAlphaShift;
>> 36:   BYTE cAccumBits;
>> 37:   BYTE cAccumRedBits;
>> 38:   BYTE cAccumGreenBits;
>> 39:   BYTE cAccumBlueBits;
>> 40:   BYTE cAccumAlphaBits;
>> 41:   BYTE cDepthBits;
>> 42:   BYTE cStencilBits;
>> 43:   BYTE cAuxBuffers;
>> 44:   BYTE iLayerType;
>> 45:   BYTE bReserved;
>> 46:   DWORD dwLayerMask;
>> 47:   DWORD dwVisibleMask;
>> 48:   DWORD dwDamageMask;
>> 49:  )
>> 50: );
>>
>> #needed for the wglMakeCurrent functions
>> 51: Win32::API::Type->typedef('HGLRC', 'HANDLE');
>>
>> #import some extra functions
>> #more info can be found in the Windows SDK documentation
>>
>> #exchanges the front and back buffers of the current pixel format
>> 52: Win32::API->Import('gdi32', 'BOOL SwapBuffers(HDC hdc);')
>> 53:  or windie "Win32::API->Import(SwapBuffers): $^E";
>>
>> #attempts to match an appropriate pixel format supported by a device
>> context to
>> # a given pixel format specification.
>> 54: Win32::API->Import('gdi32', 'int ChoosePixelFormat(HDC hdc,
>> PIXELFORMATDESCRIPTOR * ppfd);')
>> 55:  or windie "Win32::API->Import(ChoosePixelFormat): $^E";
>>
>> #sets the pixel format of the specified device context to the format
>> specified
>> # by the iPixelFormat index returned from ChoosePixelFormat().
>> 56: Win32::API->Import('gdi32', 'BOOL SetPixelFormat(HDC hdc, int
>> iPixelFormat, PIXELFORMATDESCRIPTOR * ppfd);')
>> 57:  or windie "Win32::API->Import(SetPixelFormat): $^E";
>>
>> #creates a new OpenGL rendering context, which is suitable for drawing on
>> the
>> # device referenced by hdc.
>> 58: Win32::API->Import('opengl32', 'HGLRC wglCreateContext(HDC hdc);')
>> 59:  or windie "Win32::API->Import(wglCreateContext): $^E";
>>
>> #makes a specified OpenGL rendering context the calling thread's current
>> # rendering context.
>> 60: Win32::API->Import('opengl32', 'BOOL wglMakeCurrent(HDC hdc, HGLRC
>> hglrc);')
>> 61:  or windie "Win32::API->Import(wglMakeCurrent): $^E";
>>
>> #deletes a specified OpenGL rendering context.
>> 62: Win32::API->Import('opengl32', 'BOOL wglDeleteContext(HGLRC hglrc);')
>> 63:  or windie "Win32::API->Import(wglDeleteContext): $^E";
>>
>> #create main window
>> 64: my $main = Win32::GUI::Window->new(
>> 65:  -name => "main",
>> 66:  -text => "OpenGL Example: Colour Cube",
>> 67:  -size => [640,480],
>> 68:  -left => CW_USEDEFAULT,      #let system position window
>> 69:  -pushstyle =>
>>   #Excludes the area occupied by child windows when drawing occurs
>>   # within the parent window.
>> 70:   WS_CLIPCHILDREN |
>>   #When a particular child window needs to be painted, all other
>> overlapping
>>   # child windows are clipped out of the region of the child window to be
>> updated.
>> 71:   WS_CLIPSIBLINGS,
>> 72:  -onTerminate => sub {      #WM_CLOSE
>> 73:   wglMakeCurrent($g_HDC->Handle(), 0); #deselect rendering context
>> from $hDC
>> 74:   wglDeleteContext($hRC);     #delete rendering context $hRC
>> 75:   return -1;        #exit main loop
>> 76:  },
>> 77:  -onResize => sub {       #WM_SIZE
>> 78:   my $self = shift;
>> 79:   return 0 unless $self;
>> 80:   my $height = $self->Height();   #get height and width
>> 81:   my $width = $self->Width();
>> 82:   $height = 1 if $height == 0;   #don't divide by 0
>> 83:   glViewport(0,0,$width,$height);   #set viewport to new dimensions
>> 84:   glMatrixMode(GL_PROJECTION);   #set matrix mode to projection matrix
>> 85:   glLoadIdentity();      #reset projection matrix
>> 86:   gluPerspective(54.0, $width / $height, 1.0, 1000.0); #calculate
>> aspect ratio of window
>> 87:   glMatrixMode(GL_MODELVIEW);    #set modelview matrix
>> 88:   glLoadIdentity();      #reset modelview matrix
>> 89:   return 1;
>> 90:  },
>> 91:  -onKeyDown => sub {       #WM_KEYDOWN
>> 92:   my ($self, $flags, $key) = @_;
>> 93:   return -1 if $key == VK_ESCAPE;  #exit if escape key pressed
>> 94:   return 1;
>> 95:  },
>> 96: );
>> 97: unless($main){
>> 98:  windie("Cannot create window: $^E");
>> 99: }
>> 100: $main->SetIcon(Win32::GUI::Icon->new(IDI_APPLICATION)); #set window
>> icon
>>
>> #WM_CREATE
>> 101: $g_HDC = $main->GetDC();      #set global device context to device
>> context of main window
>> 102: unless(SetupPixelFormat($g_HDC->Handle())){ #setup pixel format for
>> device context
>> 103:  exit 1;          #exit if setup fails
>> 104: }
>> 105: $hRC = wglCreateContext($g_HDC->Handle());  #create rendering context
>> used by OpenGL to draw
>> 106: wglMakeCurrent($g_HDC->Handle(), $hRC);   #select rendering context
>> $hRC into $g_HDC
>>
>> #Initialize OpenGL
>> 107: glShadeModel(GL_SMOOTH);      #set shading to smooth
>> 108: glEnable(GL_DEPTH_TEST);      #do depth comparisons and update the
>> depth buffer
>> 109: glEnable(GL_CULL_FACE);       #cull polygons based on their winding
>> in window coordinates
>> 110: glFrontFace(GL_CCW);       #The orientation of front-facing polygons
>> 111: glClearColor(0.0, 0.0, 0.0, 0.0);    #values that glClear uses to
>> clear the colour buffers
>>
>> 112: $main->Show();         #show window
>>
>> #message event
>> #This is necessary because Render() needs to be called every frame.
>> #This can produce interesting results in more complex applications (with
>> more
>> # than one window) since the Win32::GUI::Dialog() function does more than
>> just
>> # check if a sub has returned -1 (perhaps the ability to call a code block
>> every
>> # iteration of Win32::GUI::Dialog() would be useful)
>> 113: while(Win32::GUI::DoEvents() != -1){
>> 114:  Render();
>> 115: }
>>
>> #This function is used to set the pixel format for the device context.
>> # Accepts a handle to the device context of the window and returns true if
>> succeeds
>> # or false if fails.
>> #Adapted from code from OpenGL Game Programming (Premier Press, 2004)
>> 116: sub SetupPixelFormat {
>> 117:  my $hDC = shift;       #is a handle to DC
>> 118:  my $nPixelFormat;
>> 119:  my $pfd = Win32::API::Struct->new('PIXELFORMATDESCRIPTOR'); #create
>> new structure
>> 120:  $pfd->{nSize} = $pfd->sizeof();    #return sizeof structure
>> 121:  $pfd->{nVersion} = 1;      #default version
>> 122:  $pfd->{dwFlags} = PFD_DRAW_TO_WINDOW |  #window drawing support
>> 123:   PFD_SUPPORT_OPENGL |      #OpenGL support
>> 124:   PFD_DOUBLEBUFFER;      #double buffering support
>> 125:  $pfd->{iPixelType} = PFD_TYPE_RGBA;   #rgba colour mode
>> 126:  $pfd->{cColorBits} = 32;     #32 bit colour mode
>> 127:  $pfd->{cRedBits} = 0;      #ignore colour bits
>> 128:  $pfd->{cRedShift} = 0;      #
>> 129:  $pfd->{cGreenBits} = 0;      #
>> 130:  $pfd->{cGreenShift} = 0;     #
>> 131:  $pfd->{cBlueBits} = 0;      #
>> 132:  $pfd->{cBlueShift} = 0;      #
>> 133:  $pfd->{cAlphaBits} = 0;      #not alpha buffer
>> 134:  $pfd->{cAlphaShift} = 0;     #ignore alpha shift bit
>> 135:  $pfd->{cAccumBits} = 0;      #no accumulation buffer
>> 136:  $pfd->{cAccumRedBits} = 0;     #ignore accumulation bits
>> 137:  $pfd->{cAccumGreenBits} = 0;    #
>> 138:  $pfd->{cAccumBlueBits} = 0;     #
>> 139:  $pfd->{cAccumAlphaBits} = 0;    #
>> 140:  $pfd->{cDepthBits} = 16;     #16 bit z-buffer size
>> 141:  $pfd->{cStencilBits} = 0;     #no stencil buffer
>> 142:  $pfd->{cAuxBuffers} = 0;     #no auxiliary buffer
>> 143:  $pfd->{iLayerType} = PFD_MAIN_PLANE;  #main drawing plane
>> 144:  $pfd->{bReserved} = 0;      #reserved
>> 145:  $pfd->{dwLayerMask} = 0;     #layer masks ignored
>> 146:  $pfd->{dwVisibleMask} = 0;     #
>> 147:  $pfd->{dwDamageMask} = 0;     #
>>  # choose best matching pixel format
>> 148:  unless( $nPixelFormat = ChoosePixelFormat($hDC, $pfd) ){
>> 149:   winwarn("Can't find an appropriate pixel format");
>> 150:   return 0;
>> 151:  }
>>  # set pixel format to device context
>> 152:  unless( SetPixelFormat($hDC, $nPixelFormat, $pfd) ){
>> 153:   winwarn("Unable to set pixel format");
>> 154:   return 0;
>> 155:  }
>> 156:  return 1;
>> 157: }
>>
>> #This function draws the cube of points. The colour of each point is based
>> on its position
>> #Adapted from code from OpenGL Game Programming (Premier Press, 2004)
>> 158: sub DrawCube {
>> 159:  glPointSize(2.0); #set size of points drawn
>> 160:  glPushMatrix();
>> 161:   glBegin(GL_POINTS);
>> 162:    for(my $x = 0.0; $x <= 1.0; $x += 0.1){
>> 163:     for(my $y = 0.0; $y <= 1.0; $y += 0.1){
>> 164:      for(my $z = 0.0; $z <= 1.0; $z += 0.1){
>> 165:       glColor3f($x,$y,$z);
>>       #move and scale vertexes so that cube rotates about centre
>> 166:       glVertex3f($x*50-25,$y*50-25,$z*50-25);
>> 167:      }
>> 168:     }
>> 169:    }
>> 170:   glEnd();
>> 171:  glPopMatrix();
>> 172: }
>>
>> #This function is used to draw the cube and is called every frame
>> #Adapted from code from OpenGL Game Programming (Premier Press, 2004)
>> 173: sub Render {
>> 174:  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); #clear color and
>> depth buffer
>> 175:  glLoadIdentity();         #replaces the current matrix with the
>> identity matrix.
>> 176:  glTranslatef(0.0, 0.0, -150.0);      #move to 0,0,-150
>> 177:  glPushMatrix();          #save current matrix
>> 178:   glRotatef($objectXRot, 1.0, 0.0, 0.0);   #rotate around x axis
>> 179:   glRotatef($objectYRot, 0.0, 1.0, 0.0);   #rotate around y axis
>> 180:   glRotatef($objectZRot, 0.0, 0.0, 1.0);   #rotate around z axis
>> 181:   DrawCube();          #draw cube
>> 182:  glPopMatrix();          #restore matrix
>> 183:  glFlush();           #clear buffers
>> 184:  SwapBuffers($g_HDC->Handle());      #exchange front and back buffers
>> of device context
>> 185:  $objectXRot += 0.01;        #increment rotation
>> 186:  $objectYRot += 0.02;
>> 187:  $objectZRot += 0.01;
>> 188: }
>>
>> #Conveniently, the Windows specific functions for setup of OpenGL accept
>> and return
>> # handles to windows or contexts, which are just numbers, and the handles
>> to
>> # these are stored in the Window and DC objects created by Win32::GUI.
>> This method
>> # provides an easy access to this value. Placing the method in the
>> Win32::GUI::DC
>> # package allows both Windows and DCs to use it.
>> 189: package Win32::GUI::DC;
>> 190: sub Handle {
>> 191:  return shift->{-handle};
>> 192: }
>> 193: __END__
>>
>> Here are some tips and tricks regarding using Win32::GUI module and the
>> OpenGL module that I have come across on my travels:
>>
>> Win32::GUI:
>>
>> It is possible to create child windows that are rendered to using OpenGL
>> instead of rendering to the parent window, but requires a lot more setup.
>> One of the tricks needed is to specify the right styles for the window. I
>> have yet to perfect this technique, but perhaps when I get it working
>> correctly I'll post an example.
>>
>>
>> OpenGL:
>>
>> try to use the *_p variants of functions, if they exist. The function has
>> been tweaked to behave more like a regular Perl function, such as the
>> ability to accept and return arrays. This is a lot more convenient than
>> having to pack() and unpack() your a arguments. Some functions don't have a
>> *_p variant, so the next best thing is to use the *_c variant, which
>> accept OpenGL::Array objects. The use of OpenGL::Array is not documented in
>> the module, but docs can be found on the website for the module (just search
>> the web for POGL). I haven't included an example of this here, since it
>> requires more knowledge of OpenGL, but experienced OpenGL programmers should
>> have no problems using them.
>>
>>
>> As an alternative to creating windows using Win32::GUI, windows can be
>> created using the GLUT(OpenGL Utility Toolkit) functions supplied with
>> OpenGL. These can create windows that a platform-independent, as well as a
>> lot of other stuff. A lot of the examples supplied for the OpenGL module use
>> the GLUT, making them more portable, but OpenGL needs to be compiled with
>> support for GLUT, requiring the GLUT libraries. Since I can't seem to get
>> XS-implemented modules to compile properly on my machine (I use PPM
>> instead), I just stick with Win32::GUI. Its all about personal preference.
>>
>> Well, that's it for my Win32::GUI+OpenGL example. I hope someone finds it
>> useful. I'm no expert at OpenGL or the Win32 API, so there is probably a
>> better way of doing this. So far this model has worked for basic
>> implementations but don't expect to be able to make anything to big, such as
>> games, but you never know. I'd love to hear any questions or comments about
>> this example, as well as any examples of anything anyone else has done.
>>
>> As a side note, I'm new to posting messages on the mailing lists. I was
>> wondering whether I can send pictures attached (I was hoping to show a
>> screen shot of my program). Also, how do I post a reply to an existing
>> thread. Any help would be much appreciated.
>>
>> Sorry about any typos in advance. Contact me if you find any errors with
>> this post (such as with the sample program).
>>
>> Thanks.
>>
>> Kevin Marshall
>>
>> (kejohm88 AT hotmail DOT com)
>>
>>
>>
>> ________________________________
>> Click Here View photos of singles in your area
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals.
>> Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> _______________________________________________
>> Perl-Win32-GUI-Users mailing list
>> Per...@li...
>> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
>> http://perl-win32-gui.sourceforge.net/
>
>
>
> --
> Maximus*
> WarheadsSE
> MaxSource
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>

Re: [perl-win32-gui-users] Win32::GUI + OpenGL

[Jason P. <ma...@wa...>]

May I be lucky enough to pick my ass up and put it back onto my chair, then
also say thanks for the well documented and detailed example!

I myself have toyed with OpenGL via perl before, but have never thought of
combining it with Win32::GUI myself. Seeing as I'm a  maintainer for a game,
and some people have asked for updated tools with animations from said
game.. I may someday put this example to a very literal use.

Thanks again,

Jason P

On Thu, May 21, 2009 at 11:18 PM, Kevin Marshall <kej...@ho...>wrote:

>  Hey,
>
> This lengthy post is about how to use the Win32::GUI module together with
> the Perl OpenGL module (POGL).
>
> I would first like to thank the developers of Perl-Win32-GUI module. I have
> been using this module for a while now, and prefer using this module than
> coding the whole thing in C/C++. Thanks. I have decided to give back to the
> Win32::GUI community by way of sharing a solution for using OpenGL in
> conjunction with the Win32::GUI module. I hope that someone out there will
> find this useful.
>
> After reading the book OpenGL Game Programming (Premier Press), I decided
> to port some of the code examples to Perl. Since the Win32::GUI module makes
> the creation of windows easy, it was simply a matter of converting the
> relevant C/C++ code into Perl. A basic knowledge of OpenGL is needed in
> order to understand the example that I have provided. The example contains
> comments that should explain what each section does, but I'll provide a
> brief overview of the process. I'll only be discussing the Windows+OpenGL
> specific code, so if you don't have a good grasp of OpenGL, I recommend
> finding a good book or website about OpenGL programming before going any
> further. Detailed information regarding Windows API functions, and OpenGL
> functions can be found in the Windows Software Development Kit
> Documentation.
>
> OpenGL is a powerful, low-level rendering and modelling software library.
> OpenGL does not provide higher functionality, such as windowing, in order to
> remain platform independent. OpenGL uses a rendering context to store OpenGL
> commands and settings. This means that each platform must provide
> functionality to specify a rendering context for OpenGL. For UNIX systems,
> this is provided by GLX. For Windows this is provided by a set of functions
> affectionately known as 'wiggle' functions, since most of these start with
> 'wgl'. There are a number of other Win32 API functions that are also needed.
> These 'wiggle' and Win32 API functions relate Windows Device Contexts with
> the OpenGL rendering contexts. The Win32::API module is needed to import
> these functions for use in the program.
>
> Example Program Description:
>
> Lines 21-51 show some setup required for the functions that are to be
> imported. This includes creating the structure PIXELFORMATDESCRIPTOR used
> by the SetPixelFormat() function and creating a typedef for the
> wglMakeCurrent() function. Lines 52-63 show the functions that need to be
> imported. Info on these functions can be found in the SDK docs.
>
> Lines 64-100 creates the main window and sets its icon. This should be
> fairly basic for anyone experienced with the Win32::GUI module, so I'll just
> cover the important parts. Line 68 sets the -left of the window to
> CW_USEDEFAULT. This specifies that the system should position the window.
> Lines 69-71 add the window styles WS_CLIPCHILDREN  and WS_CLIPSIBLINGS.
> These affect how the window will be painted. For more info about these
> styles, see the SDK docs. Lines 72-76 setup an -onTerminate event handler.
> This will be called when the window is destroyed. At this point the
> rendering context is deselected from the main window Device Context and is
> then deleted. More on these functions later. Just know that each takes a
> handle to a device or rendering context. The sub returns -1 to exit the main
> loop. For those of you familiar with C/C++ Windows programming, this
> function roughly corresponds to the WM_CLOSE message. Lines 77-90 setup an
> -onResize event handler. This is called whenever the window is resized and
> corresponds to the WM_SIZE message. The functions in the sub are OpenGL
> specific and basically just reset the viewport to the new dimensions and
> resets the perspective. Refer to the SDK docs or a good OpenGL resource for
> info about these functions. Lines 91-95 setup a -onKeyDown event handler
> which exits the program when the ESC key is pressed.
>
> Lines 101-106 are where the device and rendering contexts are setup. Line
> 101 gets the device context of the main window and stores it in a global
> variable. Lines 102-104 calls the SetupPixelFormat() function, passing it
> the handle to the main window device context. If this sub fails the program
> exits. Lines 116-157 show the SetupPixelFormat() function. Line 119 creates
> a new PIXELFORMATDESCRIPTOR structure and lines 120-147 fills the structure
> with appropriate data. See the SDK docs for more info about this structure.
> Lines 148-151 calls the ChoosePixelFormat() function passing the handle to
> the DC and the PIXELFORMATDESCRIPTOR structure. This function chooses the
> best matching pixel format for the DC from the data specified in the
> PIXELFORMATDESCRIPTOR structure. The function returns 0 if not pixel format
> can be found. Lines 152-155 set the pixel format of the DC to the format
> returned from the ChoosePixelFormat() function and returns 0 if it fails.
> The sub returns 1 to show that it succeeded.  Line 105 creates an OpenGL
> rendering context from the specified DC using the wglCreateContext()
> function. The function is passed the handle to the main window DC and
> returns the handle to a rendering context. Line 106 selects the rendering
> context into the device context using the wglMakeCurrent() function. This
> functions is passed the handle to the main window DC and the handle to the
> rendering context created with wglCreateContext(). Passing 0 as the
> rendering context causes the rendering context to be deselected, such as in
> the -onTerminate event handler above. The wglDeleteContext() function is
> used to delete a rendering context and should be used after the rendering
> context has been deselected. The deselection and deletion of a rendering
> context should be performed when a window is destroyed, which is why this is
> done in the -onTerminate event handler above. Lines 101-106 could be thought
> of as equivalent to the WM_CREATE message (you could even use the Hook()
> method to implement this).
>
> Lines 107-111 show some basic setup of OpenGL before any rendering is done.
> These are OpenGL specific, so if you are unsure of what these do, refer to
> the docs.
>
> Lines 113-115 setup the main message loop. Win32::GUI::Dialog() can't be
> used here because the Render() function has to be called every frame. This
> loop is essentially the same, but a few differences are present which may
> affect applications with multiple windows, since the Win32::GUI::Dialog()
> functions does more behind the scenes. It would be nice if the
> Win32::GUI::Dialog() function accepted a sub ref which could be called every
> frame, but I'm not sure how easy that would be to create. Anyway, this does
> the job fine, but there are probably better methods.
>
> Lines 158-172 and 173-188 are the DrawCube() and Render() functions,
> respectively. These are used to draw the cube every frame and are OpenGL
> specific. Refer to the docs about what the OpenGL functions do if you are
> unsure.
>
> Line 189-193 creates a Handle() method in the Win32::GUI::DC package. This
> method returns the handle of the object passed in. Putting it in the DC
> package allows both windows and DCs to access it. This method is used when
> the OpenGL/Win32API function requires a handle. Since the objects store in
> handle internally, it makes it really easy to pass this value to the
> functions that need it.
>
> Here is my code example:
>
>
> ################################################################################
> #
> # Win32::GUI + OpenGL example
> #
> # This program demonstrates a basic example of using the Perl Win32::GUI
> #  module in conjunction with the Perl OpenGL module to render a spinning
> #  cube of points in the window.
> #
> # Requirements:
> #  Perl,
> #  Win32::GUI,
> #  Win32::GUI::Carp,
> #  Win32::API, and
> #  OpenGL
> #
> # This program was written using ActiveState Perl 5.8.8 Build 820 running
> on
> #  Windows XP and using Win32::GUI v1.06, Win32::GUI::Carp v1.01,
> #  Win32::API v0.46, and OpenGL v0.56
> #
> # Parts of this program are based on example code from the book OpenGL Game
> #  Programming (Premier Press, 2004) from the Premier Press Game
> #  Development Series. I recommend this book for anyone interested in using
> #  OpenGL for developing games on Windows. The book is written for the
> #  development of games written in C/C++ and assumes an advanced knowledge
> #  of the language but provides an in-depth look at OpenGL programming on
> #  Windows platforms, as well as a look at using DirectInput and
> #  DirectX Audio.
> #
>
> ################################################################################
>
> 1: use strict;
> 2: use warnings;
> #these constants are needed for SetPixelFormat() but aren't defined in
> Win32::GUI
> 3: use constant {
> 4:  PFD_TYPE_RGBA => 0,
> 5:  PFD_DOUBLEBUFFER => 0x00000001,
> 6:  PFD_DRAW_TO_WINDOW => 0x00000004,
> 7:  PFD_SUPPORT_OPENGL => 0x00000020,
> 8:  PFD_MAIN_PLANE => 0,
> 9: };
>
> 10: use OpenGL qw(:glfunctions :glconstants :glufunctions);
> 11: use Win32::API;
> 12: use Win32::GUI qw();
> 13: use Win32::GUI::Carp qw(warningsToDialog fatalsToDialog
> immediateWarnings winwarn windie);
> 14: use Win32::GUI::Constants qw(IDI_APPLICATION WS_CLIPCHILDREN
> WS_CLIPSIBLINGS
> 15:  WM_CREATE WM_SIZE WM_CLOSE VK_ESCAPE CW_USEDEFAULT MB_OK
> MB_ICONEXCLAMATION);
>
> 16: my $g_HDC;  #global handle to device context
> 17: my $hRC;  #handle to rendering context
>
> #keep track of rotation of cube
> 18: my $objectXRot = 0.0;
> 19: my $objectYRot = 0.0;
> 20: my $objectZRot = 0.0;
>
> #define PIXELFORMATDESCRIPTOR struct used for the SetPixelFormat function
> #refer to the Windows SDK documentation for more info about this structure
> 21: Win32::API::Struct->typedef(
> 22:  PIXELFORMATDESCRIPTOR => qw(
> 23:   WORD nSize;
> 24:   WORD nVersion;
> 25:   DWORD dwFlags;
> 26:   BYTE iPixelType;
> 27:   BYTE cColorBits;
> 28:   BYTE cRedBits;
> 29:   BYTE cRedShift;
> 30:   BYTE cGreenBits;
> 31:   BYTE cGreenShift;
> 32:   BYTE cBlueBits;
> 33:   BYTE cBlueShift;
> 34:   BYTE cAlphaBits;
> 35:   BYTE cAlphaShift;
> 36:   BYTE cAccumBits;
> 37:   BYTE cAccumRedBits;
> 38:   BYTE cAccumGreenBits;
> 39:   BYTE cAccumBlueBits;
> 40:   BYTE cAccumAlphaBits;
> 41:   BYTE cDepthBits;
> 42:   BYTE cStencilBits;
> 43:   BYTE cAuxBuffers;
> 44:   BYTE iLayerType;
> 45:   BYTE bReserved;
> 46:   DWORD dwLayerMask;
> 47:   DWORD dwVisibleMask;
> 48:   DWORD dwDamageMask;
> 49:  )
> 50: );
>
> #needed for the wglMakeCurrent functions
> 51: Win32::API::Type->typedef('HGLRC', 'HANDLE');
>
> #import some extra functions
> #more info can be found in the Windows SDK documentation
>
> #exchanges the front and back buffers of the current pixel format
> 52: Win32::API->Import('gdi32', 'BOOL SwapBuffers(HDC hdc);')
> 53:  or windie "Win32::API->Import(SwapBuffers): $^E";
>
> #attempts to match an appropriate pixel format supported by a device
> context to
> # a given pixel format specification.
> 54: Win32::API->Import('gdi32', 'int ChoosePixelFormat(HDC hdc,
> PIXELFORMATDESCRIPTOR * ppfd);')
> 55:  or windie "Win32::API->Import(ChoosePixelFormat): $^E";
>
> #sets the pixel format of the specified device context to the format
> specified
> # by the iPixelFormat index returned from ChoosePixelFormat().
> 56: Win32::API->Import('gdi32', 'BOOL SetPixelFormat(HDC hdc, int
> iPixelFormat, PIXELFORMATDESCRIPTOR * ppfd);')
> 57:  or windie "Win32::API->Import(SetPixelFormat): $^E";
>
> #creates a new OpenGL rendering context, which is suitable for drawing on
> the
> # device referenced by hdc.
> 58: Win32::API->Import('opengl32', 'HGLRC wglCreateContext(HDC hdc);')
> 59:  or windie "Win32::API->Import(wglCreateContext): $^E";
>
> #makes a specified OpenGL rendering context the calling thread's current
> # rendering context.
> 60: Win32::API->Import('opengl32', 'BOOL wglMakeCurrent(HDC hdc, HGLRC
> hglrc);')
> 61:  or windie "Win32::API->Import(wglMakeCurrent): $^E";
>
> #deletes a specified OpenGL rendering context.
> 62: Win32::API->Import('opengl32', 'BOOL wglDeleteContext(HGLRC hglrc);')
> 63:  or windie "Win32::API->Import(wglDeleteContext): $^E";
>
> #create main window
> 64: my $main = Win32::GUI::Window->new(
> 65:  -name => "main",
> 66:  -text => "OpenGL Example: Colour Cube",
> 67:  -size => [640,480],
> 68:  -left => CW_USEDEFAULT,      #let system position window
> 69:  -pushstyle =>
>   #Excludes the area occupied by child windows when drawing occurs
>   # within the parent window.
> 70:   WS_CLIPCHILDREN |
>   #When a particular child window needs to be painted, all other
> overlapping
>   # child windows are clipped out of the region of the child window to be
> updated.
> 71:   WS_CLIPSIBLINGS,
> 72:  -onTerminate => sub {      #WM_CLOSE
> 73:   wglMakeCurrent($g_HDC->Handle(), 0); #deselect rendering context from
> $hDC
> 74:   wglDeleteContext($hRC);     #delete rendering context $hRC
> 75:   return -1;        #exit main loop
> 76:  },
> 77:  -onResize => sub {       #WM_SIZE
> 78:   my $self = shift;
> 79:   return 0 unless $self;
> 80:   my $height = $self->Height();   #get height and width
> 81:   my $width = $self->Width();
> 82:   $height = 1 if $height == 0;   #don't divide by 0
> 83:   glViewport(0,0,$width,$height);   #set viewport to new dimensions
> 84:   glMatrixMode(GL_PROJECTION);   #set matrix mode to projection matrix
> 85:   glLoadIdentity();      #reset projection matrix
> 86:   gluPerspective(54.0, $width / $height, 1.0, 1000.0); #calculate
> aspect ratio of window
> 87:   glMatrixMode(GL_MODELVIEW);    #set modelview matrix
> 88:   glLoadIdentity();      #reset modelview matrix
> 89:   return 1;
> 90:  },
> 91:  -onKeyDown => sub {       #WM_KEYDOWN
> 92:   my ($self, $flags, $key) = @_;
> 93:   return -1 if $key == VK_ESCAPE;  #exit if escape key pressed
> 94:   return 1;
> 95:  },
> 96: );
> 97: unless($main){
> 98:  windie("Cannot create window: $^E");
> 99: }
> 100: $main->SetIcon(Win32::GUI::Icon->new(IDI_APPLICATION)); #set window
> icon
>
> #WM_CREATE
> 101: $g_HDC = $main->GetDC();      #set global device context to device
> context of main window
> 102: unless(SetupPixelFormat($g_HDC->Handle())){ #setup pixel format for
> device context
> 103:  exit 1;          #exit if setup fails
> 104: }
> 105: $hRC = wglCreateContext($g_HDC->Handle());  #create rendering context
> used by OpenGL to draw
> 106: wglMakeCurrent($g_HDC->Handle(), $hRC);   #select rendering context
> $hRC into $g_HDC
>
> #Initialize OpenGL
> 107: glShadeModel(GL_SMOOTH);      #set shading to smooth
> 108: glEnable(GL_DEPTH_TEST);      #do depth comparisons and update the
> depth buffer
> 109: glEnable(GL_CULL_FACE);       #cull polygons based on their winding in
> window coordinates
> 110: glFrontFace(GL_CCW);       #The orientation of front-facing polygons
> 111: glClearColor(0.0, 0.0, 0.0, 0.0);    #values that glClear uses to
> clear the colour buffers
>
> 112: $main->Show();         #show window
>
> #message event
> #This is necessary because Render() needs to be called every frame.
> #This can produce interesting results in more complex applications (with
> more
> # than one window) since the Win32::GUI::Dialog() function does more than
> just
> # check if a sub has returned -1 (perhaps the ability to call a code block
> every
> # iteration of Win32::GUI::Dialog() would be useful)
> 113: while(Win32::GUI::DoEvents() != -1){
> 114:  Render();
> 115: }
>
> #This function is used to set the pixel format for the device context.
> # Accepts a handle to the device context of the window and returns true if
> succeeds
> # or false if fails.
> #Adapted from code from OpenGL Game Programming (Premier Press, 2004)
> 116: sub SetupPixelFormat {
> 117:  my $hDC = shift;       #is a handle to DC
> 118:  my $nPixelFormat;
> 119:  my $pfd = Win32::API::Struct->new('PIXELFORMATDESCRIPTOR'); #create
> new structure
> 120:  $pfd->{nSize} = $pfd->sizeof();    #return sizeof structure
> 121:  $pfd->{nVersion} = 1;      #default version
> 122:  $pfd->{dwFlags} = PFD_DRAW_TO_WINDOW |  #window drawing support
> 123:   PFD_SUPPORT_OPENGL |      #OpenGL support
> 124:   PFD_DOUBLEBUFFER;      #double buffering support
> 125:  $pfd->{iPixelType} = PFD_TYPE_RGBA;   #rgba colour mode
> 126:  $pfd->{cColorBits} = 32;     #32 bit colour mode
> 127:  $pfd->{cRedBits} = 0;      #ignore colour bits
> 128:  $pfd->{cRedShift} = 0;      #
> 129:  $pfd->{cGreenBits} = 0;      #
> 130:  $pfd->{cGreenShift} = 0;     #
> 131:  $pfd->{cBlueBits} = 0;      #
> 132:  $pfd->{cBlueShift} = 0;      #
> 133:  $pfd->{cAlphaBits} = 0;      #not alpha buffer
> 134:  $pfd->{cAlphaShift} = 0;     #ignore alpha shift bit
> 135:  $pfd->{cAccumBits} = 0;      #no accumulation buffer
> 136:  $pfd->{cAccumRedBits} = 0;     #ignore accumulation bits
> 137:  $pfd->{cAccumGreenBits} = 0;    #
> 138:  $pfd->{cAccumBlueBits} = 0;     #
> 139:  $pfd->{cAccumAlphaBits} = 0;    #
> 140:  $pfd->{cDepthBits} = 16;     #16 bit z-buffer size
> 141:  $pfd->{cStencilBits} = 0;     #no stencil buffer
> 142:  $pfd->{cAuxBuffers} = 0;     #no auxiliary buffer
> 143:  $pfd->{iLayerType} = PFD_MAIN_PLANE;  #main drawing plane
> 144:  $pfd->{bReserved} = 0;      #reserved
> 145:  $pfd->{dwLayerMask} = 0;     #layer masks ignored
> 146:  $pfd->{dwVisibleMask} = 0;     #
> 147:  $pfd->{dwDamageMask} = 0;     #
>  # choose best matching pixel format
> 148:  unless( $nPixelFormat = ChoosePixelFormat($hDC, $pfd) ){
> 149:   winwarn("Can't find an appropriate pixel format");
> 150:   return 0;
> 151:  }
>  # set pixel format to device context
> 152:  unless( SetPixelFormat($hDC, $nPixelFormat, $pfd) ){
> 153:   winwarn("Unable to set pixel format");
> 154:   return 0;
> 155:  }
> 156:  return 1;
> 157: }
>
> #This function draws the cube of points. The colour of each point is based
> on its position
> #Adapted from code from OpenGL Game Programming (Premier Press, 2004)
> 158: sub DrawCube {
> 159:  glPointSize(2.0); #set size of points drawn
> 160:  glPushMatrix();
> 161:   glBegin(GL_POINTS);
> 162:    for(my $x = 0.0; $x <= 1.0; $x += 0.1){
> 163:     for(my $y = 0.0; $y <= 1.0; $y += 0.1){
> 164:      for(my $z = 0.0; $z <= 1.0; $z += 0.1){
> 165:       glColor3f($x,$y,$z);
>       #move and scale vertexes so that cube rotates about centre
> 166:       glVertex3f($x*50-25,$y*50-25,$z*50-25);
> 167:      }
> 168:     }
> 169:    }
> 170:   glEnd();
> 171:  glPopMatrix();
> 172: }
>
> #This function is used to draw the cube and is called every frame
> #Adapted from code from OpenGL Game Programming (Premier Press, 2004)
> 173: sub Render {
> 174:  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); #clear color and
> depth buffer
> 175:  glLoadIdentity();         #replaces the current matrix with the
> identity matrix.
> 176:  glTranslatef(0.0, 0.0, -150.0);      #move to 0,0,-150
> 177:  glPushMatrix();          #save current matrix
> 178:   glRotatef($objectXRot, 1.0, 0.0, 0.0);   #rotate around x axis
> 179:   glRotatef($objectYRot, 0.0, 1.0, 0.0);   #rotate around y axis
> 180:   glRotatef($objectZRot, 0.0, 0.0, 1.0);   #rotate around z axis
> 181:   DrawCube();          #draw cube
> 182:  glPopMatrix();          #restore matrix
> 183:  glFlush();           #clear buffers
> 184:  SwapBuffers($g_HDC->Handle());      #exchange front and back buffers
> of device context
> 185:  $objectXRot += 0.01;        #increment rotation
> 186:  $objectYRot += 0.02;
> 187:  $objectZRot += 0.01;
> 188: }
>
> #Conveniently, the Windows specific functions for setup of OpenGL accept
> and return
> # handles to windows or contexts, which are just numbers, and the handles
> to
> # these are stored in the Window and DC objects created by Win32::GUI. This
> method
> # provides an easy access to this value. Placing the method in the
> Win32::GUI::DC
> # package allows both Windows and DCs to use it.
> 189: package Win32::GUI::DC;
> 190: sub Handle {
> 191:  return shift->{-handle};
> 192: }
> 193: __END__
>
> Here are some tips and tricks regarding using Win32::GUI module and the
> OpenGL module that I have come across on my travels:
>
> Win32::GUI:
>
>
>    - It is possible to create child windows that are rendered to using
>    OpenGL instead of rendering to the parent window, but requires a lot more
>    setup. One of the tricks needed is to specify the right styles for the
>    window. I have yet to perfect this technique, but perhaps when I get it
>    working correctly I'll post an example.
>
>
> OpenGL:
>
>    - try to use the *_p variants of functions, if they exist. The function
>    has been tweaked to behave more like a regular Perl function, such as the
>    ability to accept and return arrays. This is a lot more convenient than
>    having to pack() and unpack() your a arguments. Some functions don't have a
>    *_p variant, so the next best thing is to use the *_c variant, which
>    accept OpenGL::Array objects. The use of OpenGL::Array is not documented in
>    the module, but docs can be found on the website for the module (just search
>    the web for POGL). I haven't included an example of this here, since it
>    requires more knowledge of OpenGL, but experienced OpenGL programmers should
>    have no problems using them.
>
>
> As an alternative to creating windows using Win32::GUI, windows can be
> created using the GLUT(OpenGL Utility Toolkit) functions supplied with
> OpenGL. These can create windows that a platform-independent, as well as a
> lot of other stuff. A lot of the examples supplied for the OpenGL module use
> the GLUT, making them more portable, but OpenGL needs to be compiled with
> support for GLUT, requiring the GLUT libraries. Since I can't seem to get
> XS-implemented modules to compile properly on my machine (I use PPM
> instead), I just stick with Win32::GUI. Its all about personal preference.
>
> Well, that's it for my Win32::GUI+OpenGL example. I hope someone finds it
> useful. I'm no expert at OpenGL or the Win32 API, so there is probably a
> better way of doing this. So far this model has worked for basic
> implementations but don't expect to be able to make anything to big, such as
> games, but you never know. I'd love to hear any questions or comments about
> this example, as well as any examples of anything anyone else has done.
>
> As a side note, I'm new to posting messages on the mailing lists. I was
> wondering whether I can send pictures attached (I was hoping to show a
> screen shot of my program). Also, how do I post a reply to an existing
> thread. Any help would be much appreciated.
>
> Sorry about any typos in advance. Contact me if you find any errors with
> this post (such as with the sample program).
>
> Thanks.
>
> Kevin Marshall
>
> (kejohm88 AT hotmail DOT com)
>
>
>
> ------------------------------
> Click Here View photos of singles in your area<http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fsearch%2Fsearch%2Easpx%3Fexec%3Dgo%26tp%3Dq%26gc%3D2%26tr%3D1%26lage%3D18%26uage%3D55%26cl%3D14%26sl%3D0%26dist%3D50%26po%3D1%26do%3D2%26trackingid%3D1046138%26r2s%3D1&_t=773166090&_r=Hotmail_Endtext&_m=EXT>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>



-- 
Maximus*
WarheadsSE
MaxSource

[perl-win32-gui-users] Win32::GUI + OpenGL

[Kevin M. <kej...@ho...>]

Hey,
 
This lengthy post is about how to use the Win32::GUI module together with the Perl OpenGL module (POGL).
 
I would first like to thank the developers of Perl-Win32-GUI module. I have been using this module for a while now, and prefer using this module than coding the whole thing in C/C++. Thanks. I have decided to give back to the Win32::GUI community by way of sharing a solution for using OpenGL in conjunction with the Win32::GUI module. I hope that someone out there will find this useful.
 
After reading the book OpenGL Game Programming (Premier Press), I decided to port some of the code examples to Perl. Since the Win32::GUI module makes the creation of windows easy, it was simply a matter of converting the relevant C/C++ code into Perl. A basic knowledge of OpenGL is needed in order to understand the example that I have provided. The example contains comments that should explain what each section does, but I'll provide a brief overview of the process. I'll only be discussing the Windows+OpenGL specific code, so if you don't have a good grasp of OpenGL, I recommend finding a good book or website about OpenGL programming before going any further. Detailed information regarding Windows API functions, and OpenGL functions can be found in the Windows Software Development Kit Documentation. 
 
OpenGL is a powerful, low-level rendering and modelling software library. OpenGL does not provide higher functionality, such as windowing, in order to remain platform independent. OpenGL uses a rendering context to store OpenGL commands and settings. This means that each platform must provide functionality to specify a rendering context for OpenGL. For UNIX systems, this is provided by GLX. For Windows this is provided by a set of functions affectionately known as 'wiggle' functions, since most of these start with 'wgl'. There are a number of other Win32 API functions that are also needed. These 'wiggle' and Win32 API functions relate Windows Device Contexts with the OpenGL rendering contexts. The Win32::API module is needed to import these functions for use in the program.

 

Example Program Description: 
 
Lines 21-51 show some setup required for the functions that are to be imported. This includes creating the structure PIXELFORMATDESCRIPTOR used by the SetPixelFormat() function and creating a typedef for the wglMakeCurrent() function. Lines 52-63 show the functions that need to be imported. Info on these functions can be found in the SDK docs.
 
Lines 64-100 creates the main window and sets its icon. This should be fairly basic for anyone experienced with the Win32::GUI module, so I'll just cover the important parts. Line 68 sets the -left of the window to CW_USEDEFAULT. This specifies that the system should position the window. Lines 69-71 add the window styles WS_CLIPCHILDREN  and WS_CLIPSIBLINGS. These affect how the window will be painted. For more info about these styles, see the SDK docs. Lines 72-76 setup an -onTerminate event handler. This will be called when the window is destroyed. At this point the rendering context is deselected from the main window Device Context and is then deleted. More on these functions later. Just know that each takes a handle to a device or rendering context. The sub returns -1 to exit the main loop. For those of you familiar with C/C++ Windows programming, this function roughly corresponds to the WM_CLOSE message. Lines 77-90 setup an -onResize event handler. This is called whenever the window is resized and corresponds to the WM_SIZE message. The functions in the sub are OpenGL specific and basically just reset the viewport to the new dimensions and resets the perspective. Refer to the SDK docs or a good OpenGL resource for info about these functions. Lines 91-95 setup a -onKeyDown event handler which exits the program when the ESC key is pressed.
 
Lines 101-106 are where the device and rendering contexts are setup. Line 101 gets the device context of the main window and stores it in a global variable. Lines 102-104 calls the SetupPixelFormat() function, passing it the handle to the main window device context. If this sub fails the program exits. Lines 116-157 show the SetupPixelFormat() function. Line 119 creates a new PIXELFORMATDESCRIPTOR structure and lines 120-147 fills the structure with appropriate data. See the SDK docs for more info about this structure. Lines 148-151 calls the ChoosePixelFormat() function passing the handle to the DC and the PIXELFORMATDESCRIPTOR structure. This function chooses the best matching pixel format for the DC from the data specified in the PIXELFORMATDESCRIPTOR structure. The function returns 0 if not pixel format can be found. Lines 152-155 set the pixel format of the DC to the format returned from the ChoosePixelFormat() function and returns 0 if it fails. The sub returns 1 to show that it succeeded.  Line 105 creates an OpenGL rendering context from the specified DC using the wglCreateContext() function. The function is passed the handle to the main window DC and returns the handle to a rendering context. Line 106 selects the rendering context into the device context using the wglMakeCurrent() function. This functions is passed the handle to the main window DC and the handle to the rendering context created with wglCreateContext(). Passing 0 as the rendering context causes the rendering context to be deselected, such as in the -onTerminate event handler above. The wglDeleteContext() function is used to delete a rendering context and should be used after the rendering context has been deselected. The deselection and deletion of a rendering context should be performed when a window is destroyed, which is why this is done in the -onTerminate event handler above. Lines 101-106 could be thought of as equivalent to the WM_CREATE message (you could even use the Hook() method to implement this).
 
Lines 107-111 show some basic setup of OpenGL before any rendering is done. These are OpenGL specific, so if you are unsure of what these do, refer to the docs.
 
Lines 113-115 setup the main message loop. Win32::GUI::Dialog() can't be used here because the Render() function has to be called every frame. This loop is essentially the same, but a few differences are present which may affect applications with multiple windows, since the Win32::GUI::Dialog() functions does more behind the scenes. It would be nice if the Win32::GUI::Dialog() function accepted a sub ref which could be called every frame, but I'm not sure how easy that would be to create. Anyway, this does the job fine, but there are probably better methods.
 
Lines 158-172 and 173-188 are the DrawCube() and Render() functions, respectively. These are used to draw the cube every frame and are OpenGL specific. Refer to the docs about what the OpenGL functions do if you are unsure.
 
Line 189-193 creates a Handle() method in the Win32::GUI::DC package. This method returns the handle of the object passed in. Putting it in the DC package allows both windows and DCs to access it. This method is used when the OpenGL/Win32API function requires a handle. Since the objects store in handle internally, it makes it really easy to pass this value to the functions that need it.
 
Here is my code example:
 
################################################################################
#
# Win32::GUI + OpenGL example
#
# This program demonstrates a basic example of using the Perl Win32::GUI
#  module in conjunction with the Perl OpenGL module to render a spinning
#  cube of points in the window.
#
# Requirements:
#  Perl,
#  Win32::GUI,
#  Win32::GUI::Carp,
#  Win32::API, and
#  OpenGL
#
# This program was written using ActiveState Perl 5.8.8 Build 820 running on 
#  Windows XP and using Win32::GUI v1.06, Win32::GUI::Carp v1.01, 
#  Win32::API v0.46, and OpenGL v0.56
#
# Parts of this program are based on example code from the book OpenGL Game
#  Programming (Premier Press, 2004) from the Premier Press Game
#  Development Series. I recommend this book for anyone interested in using
#  OpenGL for developing games on Windows. The book is written for the
#  development of games written in C/C++ and assumes an advanced knowledge
#  of the language but provides an in-depth look at OpenGL programming on
#  Windows platforms, as well as a look at using DirectInput and 
#  DirectX Audio.
#
################################################################################
 
1: use strict;
2: use warnings;
#these constants are needed for SetPixelFormat() but aren't defined in Win32::GUI
3: use constant {
4:  PFD_TYPE_RGBA => 0,
5:  PFD_DOUBLEBUFFER => 0x00000001,
6:  PFD_DRAW_TO_WINDOW => 0x00000004,
7:  PFD_SUPPORT_OPENGL => 0x00000020,
8:  PFD_MAIN_PLANE => 0,
9: };
 
10: use OpenGL qw(:glfunctions :glconstants :glufunctions);
11: use Win32::API;
12: use Win32::GUI qw();
13: use Win32::GUI::Carp qw(warningsToDialog fatalsToDialog immediateWarnings winwarn windie);
14: use Win32::GUI::Constants qw(IDI_APPLICATION WS_CLIPCHILDREN WS_CLIPSIBLINGS
15:  WM_CREATE WM_SIZE WM_CLOSE VK_ESCAPE CW_USEDEFAULT MB_OK MB_ICONEXCLAMATION);
 
16: my $g_HDC;  #global handle to device context
17: my $hRC;  #handle to rendering context
 
#keep track of rotation of cube
18: my $objectXRot = 0.0;
19: my $objectYRot = 0.0;
20: my $objectZRot = 0.0;
 
#define PIXELFORMATDESCRIPTOR struct used for the SetPixelFormat function
#refer to the Windows SDK documentation for more info about this structure
21: Win32::API::Struct->typedef(
22:  PIXELFORMATDESCRIPTOR => qw(
23:   WORD nSize;
24:   WORD nVersion;
25:   DWORD dwFlags;
26:   BYTE iPixelType;
27:   BYTE cColorBits;
28:   BYTE cRedBits;
29:   BYTE cRedShift;
30:   BYTE cGreenBits;
31:   BYTE cGreenShift;
32:   BYTE cBlueBits;
33:   BYTE cBlueShift;
34:   BYTE cAlphaBits;
35:   BYTE cAlphaShift;
36:   BYTE cAccumBits;
37:   BYTE cAccumRedBits;
38:   BYTE cAccumGreenBits;
39:   BYTE cAccumBlueBits;
40:   BYTE cAccumAlphaBits;
41:   BYTE cDepthBits;
42:   BYTE cStencilBits;
43:   BYTE cAuxBuffers;
44:   BYTE iLayerType;
45:   BYTE bReserved;
46:   DWORD dwLayerMask;
47:   DWORD dwVisibleMask;
48:   DWORD dwDamageMask;
49:  )
50: );
 
#needed for the wglMakeCurrent functions
51: Win32::API::Type->typedef('HGLRC', 'HANDLE');
 
#import some extra functions
#more info can be found in the Windows SDK documentation
 
#exchanges the front and back buffers of the current pixel format
52: Win32::API->Import('gdi32', 'BOOL SwapBuffers(HDC hdc);')
53:  or windie "Win32::API->Import(SwapBuffers): $^E";
 
#attempts to match an appropriate pixel format supported by a device context to
# a given pixel format specification.
54: Win32::API->Import('gdi32', 'int ChoosePixelFormat(HDC hdc, PIXELFORMATDESCRIPTOR * ppfd);')
55:  or windie "Win32::API->Import(ChoosePixelFormat): $^E";
 
#sets the pixel format of the specified device context to the format specified
# by the iPixelFormat index returned from ChoosePixelFormat().
56: Win32::API->Import('gdi32', 'BOOL SetPixelFormat(HDC hdc, int iPixelFormat, PIXELFORMATDESCRIPTOR * ppfd);')
57:  or windie "Win32::API->Import(SetPixelFormat): $^E";
 
#creates a new OpenGL rendering context, which is suitable for drawing on the
# device referenced by hdc.
58: Win32::API->Import('opengl32', 'HGLRC wglCreateContext(HDC hdc);')
59:  or windie "Win32::API->Import(wglCreateContext): $^E";
 
#makes a specified OpenGL rendering context the calling thread's current
# rendering context.
60: Win32::API->Import('opengl32', 'BOOL wglMakeCurrent(HDC hdc, HGLRC hglrc);')
61:  or windie "Win32::API->Import(wglMakeCurrent): $^E";
 
#deletes a specified OpenGL rendering context.
62: Win32::API->Import('opengl32', 'BOOL wglDeleteContext(HGLRC hglrc);')
63:  or windie "Win32::API->Import(wglDeleteContext): $^E";

#create main window
64: my $main = Win32::GUI::Window->new(
65:  -name => "main",
66:  -text => "OpenGL Example: Colour Cube",
67:  -size => [640,480],
68:  -left => CW_USEDEFAULT,      #let system position window
69:  -pushstyle =>
  #Excludes the area occupied by child windows when drawing occurs
  # within the parent window.
70:   WS_CLIPCHILDREN |
  #When a particular child window needs to be painted, all other overlapping
  # child windows are clipped out of the region of the child window to be updated.
71:   WS_CLIPSIBLINGS,
72:  -onTerminate => sub {      #WM_CLOSE
73:   wglMakeCurrent($g_HDC->Handle(), 0); #deselect rendering context from $hDC
74:   wglDeleteContext($hRC);     #delete rendering context $hRC
75:   return -1;        #exit main loop
76:  },
77:  -onResize => sub {       #WM_SIZE
78:   my $self = shift;
79:   return 0 unless $self;
80:   my $height = $self->Height();   #get height and width
81:   my $width = $self->Width();
82:   $height = 1 if $height == 0;   #don't divide by 0
83:   glViewport(0,0,$width,$height);   #set viewport to new dimensions
84:   glMatrixMode(GL_PROJECTION);   #set matrix mode to projection matrix
85:   glLoadIdentity();      #reset projection matrix
86:   gluPerspective(54.0, $width / $height, 1.0, 1000.0); #calculate aspect ratio of window
87:   glMatrixMode(GL_MODELVIEW);    #set modelview matrix
88:   glLoadIdentity();      #reset modelview matrix
89:   return 1;
90:  },
91:  -onKeyDown => sub {       #WM_KEYDOWN
92:   my ($self, $flags, $key) = @_;
93:   return -1 if $key == VK_ESCAPE;  #exit if escape key pressed
94:   return 1;
95:  },
96: );
97: unless($main){
98:  windie("Cannot create window: $^E");
99: }
100: $main->SetIcon(Win32::GUI::Icon->new(IDI_APPLICATION)); #set window icon
 
#WM_CREATE
101: $g_HDC = $main->GetDC();      #set global device context to device context of main window
102: unless(SetupPixelFormat($g_HDC->Handle())){ #setup pixel format for device context
103:  exit 1;          #exit if setup fails
104: }
105: $hRC = wglCreateContext($g_HDC->Handle());  #create rendering context used by OpenGL to draw
106: wglMakeCurrent($g_HDC->Handle(), $hRC);   #select rendering context $hRC into $g_HDC
 
#Initialize OpenGL
107: glShadeModel(GL_SMOOTH);      #set shading to smooth
108: glEnable(GL_DEPTH_TEST);      #do depth comparisons and update the depth buffer
109: glEnable(GL_CULL_FACE);       #cull polygons based on their winding in window coordinates
110: glFrontFace(GL_CCW);       #The orientation of front-facing polygons
111: glClearColor(0.0, 0.0, 0.0, 0.0);    #values that glClear uses to clear the colour buffers
 
112: $main->Show();         #show window
 
#message event
#This is necessary because Render() needs to be called every frame.
#This can produce interesting results in more complex applications (with more
# than one window) since the Win32::GUI::Dialog() function does more than just
# check if a sub has returned -1 (perhaps the ability to call a code block every
# iteration of Win32::GUI::Dialog() would be useful)
113: while(Win32::GUI::DoEvents() != -1){
114:  Render();
115: }
 
#This function is used to set the pixel format for the device context.
# Accepts a handle to the device context of the window and returns true if succeeds
# or false if fails.
#Adapted from code from OpenGL Game Programming (Premier Press, 2004)
116: sub SetupPixelFormat {
117:  my $hDC = shift;       #is a handle to DC
118:  my $nPixelFormat;
119:  my $pfd = Win32::API::Struct->new('PIXELFORMATDESCRIPTOR'); #create new structure
120:  $pfd->{nSize} = $pfd->sizeof();    #return sizeof structure
121:  $pfd->{nVersion} = 1;      #default version
122:  $pfd->{dwFlags} = PFD_DRAW_TO_WINDOW |  #window drawing support
123:   PFD_SUPPORT_OPENGL |      #OpenGL support
124:   PFD_DOUBLEBUFFER;      #double buffering support
125:  $pfd->{iPixelType} = PFD_TYPE_RGBA;   #rgba colour mode
126:  $pfd->{cColorBits} = 32;     #32 bit colour mode
127:  $pfd->{cRedBits} = 0;      #ignore colour bits
128:  $pfd->{cRedShift} = 0;      #
129:  $pfd->{cGreenBits} = 0;      #
130:  $pfd->{cGreenShift} = 0;     #
131:  $pfd->{cBlueBits} = 0;      #
132:  $pfd->{cBlueShift} = 0;      #
133:  $pfd->{cAlphaBits} = 0;      #not alpha buffer
134:  $pfd->{cAlphaShift} = 0;     #ignore alpha shift bit
135:  $pfd->{cAccumBits} = 0;      #no accumulation buffer
136:  $pfd->{cAccumRedBits} = 0;     #ignore accumulation bits
137:  $pfd->{cAccumGreenBits} = 0;    #
138:  $pfd->{cAccumBlueBits} = 0;     #
139:  $pfd->{cAccumAlphaBits} = 0;    #
140:  $pfd->{cDepthBits} = 16;     #16 bit z-buffer size
141:  $pfd->{cStencilBits} = 0;     #no stencil buffer
142:  $pfd->{cAuxBuffers} = 0;     #no auxiliary buffer
143:  $pfd->{iLayerType} = PFD_MAIN_PLANE;  #main drawing plane
144:  $pfd->{bReserved} = 0;      #reserved
145:  $pfd->{dwLayerMask} = 0;     #layer masks ignored
146:  $pfd->{dwVisibleMask} = 0;     #
147:  $pfd->{dwDamageMask} = 0;     #
 # choose best matching pixel format
148:  unless( $nPixelFormat = ChoosePixelFormat($hDC, $pfd) ){
149:   winwarn("Can't find an appropriate pixel format");
150:   return 0;
151:  }
 # set pixel format to device context
152:  unless( SetPixelFormat($hDC, $nPixelFormat, $pfd) ){
153:   winwarn("Unable to set pixel format");
154:   return 0;
155:  }
156:  return 1;
157: }
 
#This function draws the cube of points. The colour of each point is based on its position
#Adapted from code from OpenGL Game Programming (Premier Press, 2004)
158: sub DrawCube {
159:  glPointSize(2.0); #set size of points drawn
160:  glPushMatrix();
161:   glBegin(GL_POINTS);
162:    for(my $x = 0.0; $x <= 1.0; $x += 0.1){
163:     for(my $y = 0.0; $y <= 1.0; $y += 0.1){
164:      for(my $z = 0.0; $z <= 1.0; $z += 0.1){
165:       glColor3f($x,$y,$z);
      #move and scale vertexes so that cube rotates about centre
166:       glVertex3f($x*50-25,$y*50-25,$z*50-25);
167:      }
168:     }
169:    }
170:   glEnd();
171:  glPopMatrix();
172: }
 
#This function is used to draw the cube and is called every frame
#Adapted from code from OpenGL Game Programming (Premier Press, 2004)
173: sub Render {
174:  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); #clear color and depth buffer
175:  glLoadIdentity();         #replaces the current matrix with the identity matrix.
176:  glTranslatef(0.0, 0.0, -150.0);      #move to 0,0,-150
177:  glPushMatrix();          #save current matrix
178:   glRotatef($objectXRot, 1.0, 0.0, 0.0);   #rotate around x axis
179:   glRotatef($objectYRot, 0.0, 1.0, 0.0);   #rotate around y axis
180:   glRotatef($objectZRot, 0.0, 0.0, 1.0);   #rotate around z axis
181:   DrawCube();          #draw cube
182:  glPopMatrix();          #restore matrix
183:  glFlush();           #clear buffers
184:  SwapBuffers($g_HDC->Handle());      #exchange front and back buffers of device context
185:  $objectXRot += 0.01;        #increment rotation
186:  $objectYRot += 0.02;
187:  $objectZRot += 0.01;
188: }
 
#Conveniently, the Windows specific functions for setup of OpenGL accept and return
# handles to windows or contexts, which are just numbers, and the handles to
# these are stored in the Window and DC objects created by Win32::GUI. This method
# provides an easy access to this value. Placing the method in the Win32::GUI::DC
# package allows both Windows and DCs to use it.
189: package Win32::GUI::DC;
190: sub Handle {
191:  return shift->{-handle};
192: }
193: __END__
 
Here are some tips and tricks regarding using Win32::GUI module and the OpenGL module that I have come across on my travels:
 
Win32::GUI:



It is possible to create child windows that are rendered to using OpenGL instead of rendering to the parent window, but requires a lot more setup. One of the tricks needed is to specify the right styles for the window. I have yet to perfect this technique, but perhaps when I get it working correctly I'll post an example. 
OpenGL:


try to use the *_p variants of functions, if they exist. The function has been tweaked to behave more like a regular Perl function, such as the ability to accept and return arrays. This is a lot more convenient than having to pack() and unpack() your a arguments. Some functions don't have a *_p variant, so the next best thing is to use the *_c variant, which accept OpenGL::Array objects. The use of OpenGL::Array is not documented in the module, but docs can be found on the website for the module (just search the web for POGL). I haven't included an example of this here, since it requires more knowledge of OpenGL, but experienced OpenGL programmers should have no problems using them.
 
As an alternative to creating windows using Win32::GUI, windows can be created using the GLUT(OpenGL Utility Toolkit) functions supplied with OpenGL. These can create windows that a platform-independent, as well as a lot of other stuff. A lot of the examples supplied for the OpenGL module use the GLUT, making them more portable, but OpenGL needs to be compiled with support for GLUT, requiring the GLUT libraries. Since I can't seem to get XS-implemented modules to compile properly on my machine (I use PPM instead), I just stick with Win32::GUI. Its all about personal preference.
 
Well, that's it for my Win32::GUI+OpenGL example. I hope someone finds it useful. I'm no expert at OpenGL or the Win32 API, so there is probably a better way of doing this. So far this model has worked for basic implementations but don't expect to be able to make anything to big, such as games, but you never know. I'd love to hear any questions or comments about this example, as well as any examples of anything anyone else has done.

 

As a side note, I'm new to posting messages on the mailing lists. I was wondering whether I can send pictures attached (I was hoping to show a screen shot of my program). Also, how do I post a reply to an existing thread. Any help would be much appreciated.

 

Sorry about any typos in advance. Contact me if you find any errors with this post (such as with the sample program).
 
Thanks.
 
Kevin Marshall
 
(kejohm88 AT hotmail DOT com)
 


_________________________________________________________________
View photos of singles in your area Click Here
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fsearch%2Fsearch%2Easpx%3Fexec%3Dgo%26tp%3Dq%26gc%3D2%26tr%3D1%26lage%3D18%26uage%3D55%26cl%3D14%26sl%3D0%26dist%3D50%26po%3D1%26do%3D2%26trackingid%3D1046138%26r2s%3D1&_t=773166090&_r=Hotmail_Endtext&_m=EXT

[perl-win32-gui-users] Win32::GUI Thanks

[Simon B. <si...@na...>]

Just a quick mail to thank the developers for your excellent Win32::GUI
module(s) which I have just used to create a Windows application for a
client using, using LWP, OpenSSL and mcrypt::rijndael,  along with the
Cava packager and Inno Setup to create a standalone win32 executable
plus a setup.exe.

Initially faced with having to do it in C on an unfamiliar development
platform(windows) was giving me nightmares!


Cheers,

Simon Britton

Senior Developer
Namesco Limited
Acton House, Perdiswell Park, Worcester, WR3 7GD

Re: [perl-win32-gui-users] XP styles support -- when?

[Jan D. <ja...@ac...>]

On Tue, 05 May 2009, Rob May wrote:
> 2009/5/4 Jan Dubois <ja...@ac...>:
> Thanks - According to the "spec"
> (http://msdn.microsoft.com/en-us/library/aa374191(VS.85).aspx) the
> processorArchitecture attribute is optional. If omitted I think it
> would mean all architectures. I'm pretty sure I've also seen
> processorArchitecture="*" - but can't find any examples/documentation
> immediately.
>
> I'll work out a suitable course of action and modify the manifest/ add
> _manifest.PL as appropriate.

If processorArchitecture="*" works, then that would be the preferred solution,
as it would even work in corner cases like building 32-bit modules on 64-bit
Windows.

> Many thanks for the feedback. Might this be a candidate for inclusion
> in libwin32 (or whatever that's become)?

libwin32 doesn't exist anymore as a distribution; all modules are
individually packaged on CPAN now. We do have a lib...@pe...
mailing list, and the http://libwin32.googlecode.com repository though.
The Win32API::File and Win32API::Registry modules are maintained
elsewhere though, and Win32::API (which was not part of libwin32 before)
is now included in the libwin32 project.

You are welcome to add your Win32::VisualStyles module to the project
as well; just send me a Google recognized email address (Gmail, Gtalk,
Google docs etc) and I'll add you to the project to give you write
access to the subversion repository.

Cheers,
-Jan

Re: [perl-win32-gui-users] XP styles support -- when?

[Rob M. <ro...@th...>]

2009/5/5 Rob May <ro...@th...>:
> 2009/5/4 Jan Dubois <ja...@ac...>:
>> * The manifest file contains a hardcoded X86 architecture.  The file should
>>  be generated dynamically and contain AMD64 as the architecture for 64-bit
>>  Windows on x86_64.  Something like this:

Manifest is now generated.

>> * The SYNOPSIS uses IsThemeActive() and IsAppThemed() without importing them.

Synopsis updated to show importing of IsThemeActive and IsAppThemed.

>> * I would normally just copy the required Windows SDK definitions into the
>>  *.xs file so that the code can be compiled with just VC6/MinGW and doesn't
>>  need a Windows SDK installation.

I reverted WINVER and _WIN32_WINNT down to 0x)400 to aviod generating
wwarnings from the VC6 headers, and then added the extra stuff needed
into VisualStyles.xs.  This allowed me to get rid of the extra mingw.h
file too.   Seems to build fine for me with VC6 (SP2), VC2 (SP2) with
Feb 2003 PSDK R2, mingw (gcc version 3.4.5 (mingw-vista special r3)).

>> * Why are you calling LoadLibraryW() instead of LoadLibraryA()?

LoadLibraryW replaced with LoadLibraryA.

New source (V0.00_02) at:
http://rob.themayfamily.me.uk/win32-gui/win32-visualstyles


Regards,
Rob.

Re: [perl-win32-gui-users] XP styles support -- when?

[Rob M. <ro...@th...>]

2009/5/4 Jan Dubois <ja...@ac...>:
> The fact that you can programmatically request v6 controls without
> having to add a manifest is enough reason to prevent adding this
> part of the manifest for at least Perl 5.10.x, especially if you
> cannot programmatically switch back to *not* require v6.

In general I agree - from the point of view of the Win32::GUI package
I'm indifferent.

> As to using v5 controls from a process that has v6 in its manifest
> I would try something like this:
>
> * Add a second manifest resource to your extension DLL that doesn't
>  specify v6 controls.  Use any user defined resource name you want.
>
> * Call CreateActCtx() with an ACTATC structure that has includes
>  the resource name for this alternate manifest.
>
> * Activate this manifest.

I've tried this (at least on XP). (and in the process worked out most
of the undocumented/badly documented parts of the ACTCTX structure).

I've tried several ways (I can let you have my test code if you're
interested).  Under XP I can't find any way to get back from a V6
activation context to a V5 activation context. (A manifest with no
dependancy on any Comctrl32 doesn't seem to do the trick; A manifest
with an explicit 5.80/1/2 dependence fails to create an activation
context).  I haven't tried under Vista, where it might be possible to
explicitly request a v5.8 comctl32.dll, as I notice that v5 comctrl32
entries in the WinSxS directory - which doesn't happen in XP.

I'll try to find some time for a little further investigation, as I'm
sure it should be possible - but I haven't found a way yet.

>> I've written a small module that can turn on visual styles
>> (Win32::VisualStyles).

> I haven't tried it yet, but it looks like a good idea.  +1 on separating
> it out from Win32::GUI.  Random comments just from looking at the source:
>
> * The manifest file contains a hardcoded X86 architecture.  The file should
>  be generated dynamically and contain AMD64 as the architecture for 64-bit
>  Windows on x86_64.  Something like this:
>
>  http://github.com/jandubois/perl/blob/45b29eb26a4450f83f586c2fc2e47964713cc910/win32/perlexe_manifest.PL

Thanks - According to the "spec"
(http://msdn.microsoft.com/en-us/library/aa374191(VS.85).aspx) the
processorArchitecture attribute is optional.  If omitted I think it
would mean all architectures.  I'm pretty sure I've also seen
processorArchitecture="*" - but can't find any examples/documentation
immediately.

I'll work out a suitable course of action and modify the manifest/ add
_manifest.PL as appropriate.

> * The SYNOPSIS uses IsThemeActive() and IsAppThemed() without importing them.

Thanks - I'll modify.

> * I would normally just copy the required Windows SDK definitions into the
>  *.xs file so that the code can be compiled with just VC6/MinGW and doesn't
>  need a Windows SDK installation.

I'll look at this.  I always find it difficult to find suitable
defines to use as guards around structure definitions, so that it also
works with an SDK installation, but that's not insurmountable.

> * Why are you calling LoadLibraryW() instead of LoadLibraryA()?

Mainly because I 'borrowed' the code.  The reality is that once we're
at that point in the code we know that we've got LoadLibraryW ... and
calling LoadLibraryW will be marginally faster than LoadLibraryA,
which AFAICT will be a wrapper around LoadLibraryW, with a
MultiByteToWideChar call.   I don't think it really matters, and for
the sake of not breaking a non-delay-loading build I'll change it to
LoadLibraryA.

> Most of the feedback above is probably just personal taste, except for the
> architecture string in the manifest on 64-bit Windows.
>
> I hope I'll get some time soon to actually play with it a little (e.g. see
> if it otherwise works on 64-bit).

Many thanks for the feedback.  Might this be a candidate for inclusion
in libwin32 (or whatever that's become)?

Rob.

Re: [perl-win32-gui-users] XP styles support -- when?

[Jan D. <ja...@ac...>]

On Sat, 02 May 2009, Rob May wrote:
> 2009/4/22 Jan Dubois <ja...@ac...>:
> I've had a chance to play further, and at least on XP once the
> perl.exe manifest required V6 of the common controls I can find no way
> to get back to using the V5 controls in an extension. Theoretically is
> should be possible to build perl with ISOLATION_AWARE_ENABLED defined,
> but then all extension DLL will use V5 of the common controls,
> somewhat defeating the purpose of asking for them in manifest in the
> first place.
>
> I don't think this is a reason not to have the perl.exe manifest
> request v6 common controls, but thought I should mention this as a
> potential problem.

The fact that you can programmatically request v6 controls without
having to add a manifest is enough reason to prevent adding this
part of the manifest for at least Perl 5.10.x, especially if you
cannot programmatically switch back to *not* require v6.

As to using v5 controls from a process that has v6 in its manifest
I would try something like this:

* Add a second manifest resource to your extension DLL that doesn't
  specify v6 controls.  Use any user defined resource name you want.

* Call CreateActCtx() with an ACTATC structure that has includes
  the resource name for this alternate manifest.

* Activate this manifest.


> As I was getting fed up with adding/removing a manifest file from the
> perl bin directory to test apps with and without manifests, I've
> written a small module that can turn on visual styles
> (Win32::VisualStyles). Code can be download from
> http://rob.themayfamily.me.uk/win32-gui/win32-visualstyles - I'd
> appreciate feedback on the interface and whether it works for you. If
> I get positive feedback I'll finish tidying up the documentation and
> release it as a CPAN module. I've not put it in the Win32::GUI
> namespace, as I think it has wider applicability.

I haven't tried it yet, but it looks like a good idea.  +1 on separating
it out from Win32::GUI.  Random comments just from looking at the source:

* The manifest file contains a hardcoded X86 architecture.  The file should
  be generated dynamically and contain AMD64 as the architecture for 64-bit
  Windows on x86_64.  Something like this:

  http://github.com/jandubois/perl/blob/45b29eb26a4450f83f586c2fc2e47964713cc910/win32/perlexe_manifest.PL

* The SYNOPSIS uses IsThemeActive() and IsAppThemed() without importing them.

* I would normally just copy the required Windows SDK definitions into the
  *.xs file so that the code can be compiled with just VC6/MinGW and doesn't
  need a Windows SDK installation.

* Why are you calling LoadLibraryW() instead of LoadLibraryA()?

Most of the feedback above is probably just personal taste, except for the
architecture string in the manifest on 64-bit Windows.

I hope I'll get some time soon to actually play with it a little (e.g. see
if it otherwise works on 64-bit).

Cheers,
-Jan

Re: [perl-win32-gui-users] XP styles support -- when?

[Rob M. <ro...@th...>]

2009/4/22 Jan Dubois <ja...@ac...>:
> On Wed, 22 Apr 2009, Rob May wrote:
>> I think I vote for it too, although I suspect that it'll cause some
>> (minor) layout problems for some people, as I'm not sure that all the
>> control decorations are the same on styled/non-styled controls.
>
> There are some layout differences, so it will be visible in some apps.

I've had a chance to play further, and at least on XP once the
perl.exe manifest required V6 of the common controls I can find no way
to get back to using the V5 controls in an extension.  Theoretically
is should be possible to build perl with ISOLATION_AWARE_ENABLED
defined, but then all extension DLL will use V5 of the common
controls, somewhat defeating the purpose of asking for them in
manifest in the first place.

I don't think this is a reason not to have the perl.exe manifest
request v6 common controls, but thought I should mention this as a
potential problem.

>> Last time I had some time to play (sadly I don't get much of that
>> these days) I was looking at adding a manifest to GUI.dll - it's
>> possible to add a manifest to a DLL and get the version 6 controls for
>> any windows created by that DLL, even if the main APP doesn't have a
>> manifest; however this depends on some stuff that's in the MS headers,
>> and doesn't work with the mingw headers (and hence won't work with
>> cygwin). I have a patch somewhere (but not with me at the moment).

The change required here is very simple.  Define the C Pre-processor
symbol ISOLATION_AWARE_ENABLED for the whole project, and add a v6
manifest to the resource section with resource id 2
(ISOLATION_AWARE_MANIFEST_ID);  build with Visual C and the
headers/system do eveything else for you.  As stated above this
doesn't work with mingw/gcc.

As I was getting fed up with adding/removing a manifest file from the
perl bin directory to test apps with and without manifests, I've
written a small module that can turn on visual styles
(Win32::VisualStyles).  Code can be download from
http://rob.themayfamily.me.uk/win32-gui/win32-visualstyles - I'd
appreciate feedback on the interface and whether it works for you.  If
I get positive feedback I'll finish tidying up the documentation and
release it as a CPAN module.  I've not put it in the Win32::GUI
namespace, as I think it has wider applicability.

The code creates a V6 activation context (what a manifest gets turned
into) and activates it.  It also provides access to the Win32 API
calls S/GetThemeAppProperties, IsThemeActive, IsAppThemed, and also
provides a control_styles_active() API (as the Win32 API calls don't
do exactly what their names suggest they might).

It should work back to perl 5.6, and should have no detrimental
effects on platforms that don't support styles (pre-XP);  If your perl
already has a V6 manifest it spots this and doesn't change the
activation context.

Comments, as always, welcome.

Regards,
Rob.


>
> Interesting.  I don't quite understand how this would work though, as
> the names of the controls are registered globally, so I don't see how
> you could mix old and new style controls inside a single process.
>
>> There are also some API calls that can be used to turn styling on and
>> off on a per-app and per-window basis, once you've got the v6 controls
>> loaded ..... I haven't yet come up with a suitable strategy for
>> introducing this thought; perhaps adding a v6 manifest to perl.exe
>> will force me to find time to investigate further?
>
> Could you find a link to some documentation about this so I can understand
> how this is supposed to work?
>
> Note that we'll also have to check with e.g. the wxPerl community, and
> probably others to hear what they think about this.
>
> Cheers,
> -Jan
>
>

[perl-win32-gui-users] How can I fully disable Win32::GUI::Grid scrollbars?

[Steven P. <sp...@ms...>]

Hi,
I wish to fully disable scrollbars in a Win32::GUI::Grid.
Even with AddGrid() options -hscroll=>0 and -vscroll=>0, scrollbars appear whenever the "virtual" spreadsheet is larger than the Grid's "viewing" area.
- Does an option exist to banish scrollbars forever?
- If not, can someone point me to build/install instructions for my modified GridCtrl source? I've bought Microsoft Visual C++ 6.0 (thanks, ebay), and have successfully built DLLs and  "Inline C" sections, but I can't get past 
    c:\gridctrl\memdc.h(27) : error C2504: 'CDC' : base class undefined
and subsequent errors. (I think it'd meet my goal to insert
    return;
immediately after GridCtrl.cpp line 3021):
    3020: void CGridCtrl::EnableScrollBars(int nBar, BOOL bEnable /*=TRUE*/)
    3021: {
    3022:     if (bEnable)
    3023:     {
    3024:         if (!IsVisibleHScroll() && (nBar == SB_HORZ || nBar == SB_BOTH))
    3025:         {
    3026:             m_nBarState |= GVL_HORZ;
    3027:             CWnd::EnableScrollBarCtrl(SB_HORZ, bEnable);
    3028:         }
    3029:         
    3030:         if (!IsVisibleVScroll() && (nBar == SB_VERT || nBar == SB_BOTH))
    3031:         {
    3032:             m_nBarState |= GVL_VERT;
    3033:             CWnd::EnableScrollBarCtrl(SB_VERT, bEnable);
    3034:         }
    3035:     }
    3036:     else
    3037:     {
    3038:         if ( IsVisibleHScroll() && (nBar == SB_HORZ || nBar == SB_BOTH))
    3039:         {
    3040:             m_nBarState &= ~GVL_HORZ; 
    3041:             CWnd::EnableScrollBarCtrl(SB_HORZ, bEnable);
    3042:         }
    3043:         
    3044:         if ( IsVisibleVScroll() && (nBar == SB_VERT || nBar == SB_BOTH))
    3045:         {
    3046:             m_nBarState &= ~GVL_VERT;
    3047:             CWnd::EnableScrollBarCtrl(SB_VERT, bEnable);
    3047:         }
    3049:     }
    3050: }
- Or is there a better approach?
(If I /can/ get this to build, is more "installation" involved than merely overwriting "c:/perl/site/lib/auto/Win32/GUI/Grid/Grid.dll"?)
- Or, can someone (only if easily and quickly) build and post a modified Grid.dll?
(FWIW, I've built test DLLs to identify the (four bytes or so) opcodes necessary to patch Grid.dll, but it's also getting time-consuming to find its GridCtrl.dll location.)
Thanks in advance,
Steven

Re: [perl-win32-gui-users] Using HTTP::Daemon within Win32::GUI

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

Hi,
Not sure if I understand what you are wanting to do, but you can have a webserver (via HTTP::Daemon) running on one thread, while the main GUI is running in another. Each thread would block as you would expect: Win32::GUI until an event is fired and  HTTP::Daemon until a time out or HTTP request.
Is your problem in communicating between threads?
Cheers,
jez.

> Date: Tue, 28 Apr 2009 23:34:36 -0700
> From: rp...@ib...
> To: per...@li...
> Subject: [perl-win32-gui-users]  Using HTTP::Daemon within Win32::GUI
> 
> 
> Group;
> 
> I have an application i wrote to read data from various scanners (search
> socket scan). I currently use the keyboard to send the data to my target
> application ( a web page running in IE). This is now a problem because the
> data passed causes a few utilities used to control video drivers to freak
> out. 
> 
> My idea is to embed HTTP::Daemon in my application and use an AJAX call to
> see if any data is available. So my question is how bet to intergrate
> HTTP::Daemon with Thread utilities. my basic workflow will be:
> 
> 1) Main Application will get data from the scanner
> 2) Main Application will pass scanner data to child thread 
> 3) child thread waits until an AJAX call is placed and then returns the data
> 
> Am I barking up the wrong direction or what?
> 
> -- 
> View this message in context: http://www.nabble.com/Using-HTTP%3A%3ADaemon-within-Win32%3A%3AGUI-tp23291337p23291337.html
> Sent from the perl-win32-gui-users mailing list archive at Nabble.com.
> 
> 
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/

_________________________________________________________________
Share your photos with Windows Live Photos – Free.
http://clk.atdmt.com/UKM/go/134665338/direct/01/

[perl-win32-gui-users] Using HTTP::Daemon within Win32::GUI

[rpnoble <rp...@ib...>]

Group;

I have an application i wrote to read data from various scanners (search
socket scan). I currently use the keyboard to send the data to my target
application ( a web page running in IE). This is now a problem because the
data passed causes a few utilities used to control video drivers to freak
out. 

My idea is to embed HTTP::Daemon in my application and use an AJAX call to
see if any data is available. So my question is how bet to intergrate
HTTP::Daemon with Thread utilities. my basic workflow will be:

1) Main Application will get data from the scanner
2) Main Application will pass scanner data to child thread 
3) child thread waits until an AJAX call is placed and then returns the data

Am I barking up the wrong direction or what?

-- 
View this message in context: http://www.nabble.com/Using-HTTP%3A%3ADaemon-within-Win32%3A%3AGUI-tp23291337p23291337.html
Sent from the perl-win32-gui-users mailing list archive at Nabble.com.

Re: [perl-win32-gui-users] XP styles support -- when?

[Jan D. <ja...@ac...>]

On Thu, 23 Apr 2009, Rob May wrote:
> 2009/4/23 Jan Dubois <ja...@ac...>:
>> Interesting.  I don't quite understand how this would work though, as
>> the names of the controls are registered globally, so I don't see how
>> you could mix old and new style controls inside a single process.
>
> I'm not going to pretend that I understand it all either, but it's
> certainly possible for a process to load both v5 and v6 controls and
> use both - I suspect that if one was to understand activation contexts
> in detail it's possible to have both sorts of contro; within the same
> window - not that I can think of a reason for doing that!
>
> My starting point was this documentation:
> http://msdn.microsoft.com/en-us/library/ms997646.aspx
>
>> Could you find a link to some documentation about this so I can
>> understand how this is supposed to work?
>
> Per application: SetThemeAppProperties -
> http://msdn.microsoft.com/en-us/library/bb759825(VS.85).aspx Per
> window: SetWindowTheme -
> http://msdn.microsoft.com/en-us/library/bb759827(VS.85).aspx

Ok, I see.  You would not be missing v5 and v6 style controls; all
controls will be from v6, but you would disable the styling, so they
would still look like the old style.  But any changes in the message
handling of the controls would still be there.  But I think this
should be good enough.

So I think perl.exe should change the manifest to always request
v6 style controls, and then the Win32 module could add a function
to call SetThemeAppProperties() to switch off theming if an
application wants to do this.  This way the function would be
generally available for all users, even if the specific GUI
toolkit (e.g. Perl/Tk, or gTk, or wxPerl or Tkx or whatever
doesn't provide access to it).

Since you said you wanted to provide access to the theming APIs
in Win32-GUI in the future: these APIs are all in the uxtheme.dll,
which only exists on Windows XP and later.  Therefore you must not
link against uxtheme.lib if you want the module to continue to work
on Windows 2000; instead you need to do the LoadLibrary/GetProcAddress
dance, or put the calls into a separate XS file that is only loaded
on XP and later.

Cheers,
-Jan

Re: [perl-win32-gui-users] XP styles support -- when?

[Rob M. <ro...@th...>]

2009/4/23 Jan Dubois <ja...@ac...>:
> On Wed, 22 Apr 2009, Rob May wrote:
>> I think I vote for it too, although I suspect that it'll cause some
>> (minor) layout problems for some people, as I'm not sure that all the
>> control decorations are the same on styled/non-styled controls.
>
> There are some layout differences, so it will be visible in some apps.

Despite this I think it is the way forwards - perhaps we can find an
easy way to disable it for those that don't want it?

>> Last time I had some time to play (sadly I don't get much of that
>> these days) I was looking at adding a manifest to GUI.dll - it's
>> possible to add a manifest to a DLL and get the version 6 controls for
>> any windows created by that DLL, even if the main APP doesn't have a
>> manifest; however this depends on some stuff that's in the MS headers,
>> and doesn't work with the mingw headers (and hence won't work with
>> cygwin). I have a patch somewhere (but not with me at the moment).
>
> Interesting.  I don't quite understand how this would work though, as
> the names of the controls are registered globally, so I don't see how
> you could mix old and new style controls inside a single process.

I'm not going to pretend that I understand it all either, but it's
certainly possible for a process to load both v5 and v6 controls and
use both - I suspect that if one was to understand activation contexts
in detail it's possible to have both sorts of contro; within the same
window - not that I can think of a reason for doing that!

My starting point was this documentation:
http://msdn.microsoft.com/en-us/library/ms997646.aspx

>> There are also some API calls that can be used to turn styling on and
>> off on a per-app and per-window basis, once you've got the v6 controls
>> loaded ..... I haven't yet come up with a suitable strategy for
>> introducing this thought; perhaps adding a v6 manifest to perl.exe
>> will force me to find time to investigate further?
>
> Could you find a link to some documentation about this so I can understand
> how this is supposed to work?

Per application: SetThemeAppProperties -
http://msdn.microsoft.com/en-us/library/bb759825(VS.85).aspx
Per window: SetWindowTheme -
http://msdn.microsoft.com/en-us/library/bb759827(VS.85).aspx

> Note that we'll also have to check with e.g. the wxPerl community, and
> probably others to hear what they think about this.

Of course.  Perhaps the opposite of  what I suggested above: use a v6
manifest, but turn off themes by default and provide an easy way to
turn them on for those that want them?

Regards,
Rob.

Re: [perl-win32-gui-users] XP styles support -- when?

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

> On Wed, 22 Apr 2009, Rob May wrote:
>> 2009/4/22 Jeremy White <jez...@ho...>:
>>> I vote for adding the XP style request directly to perl.exe - in
>>> almost all cases it's the "correct" thing to do and is easy enough
>>> to remove (and indeed from PerlApp) should you need to. It's also
>>> backward compatible so it wont harm Win 2000 users etc.
>> What exactly is the "easy" way to remove the new style common controls
> from an app that requests them in an embedded MANIFEST?  On XP itself
> you can provide an external perl.exe.manifest that would override the
> embedded one, but on 2003, Vista, 2008 the embedded one always takes
> precedence.  So you'll need to actually remove the embedded manifest
> with a tool like mt.exe, but that is only available as part of the
> Windows Platform SDK, so I would not really call it "trivial".

As part of my build process I use reshacker (a free utility with a command line interface) to replace the manifest that is added with PerlApp:
http://angusj.com/resourcehacker/

I think the perl module below can also replace/delete the manifest (although I haven't tried - on my todo list)
http://search.cpan.org/~smueller/Win32-Exe-0.11/lib/Win32/Exe.pm
As a side reshacker can also be used to add other resources to exe's (such as icons, bitmaps and string tables) and Win32::GUI automatically picks them up.
Cheers,
jez.
_________________________________________________________________
Share your photos with Windows Live Photos – Free.
http://clk.atdmt.com/UKM/go/134665338/direct/01/

Re: [perl-win32-gui-users] XP styles support -- when?

[Jan D. <ja...@ac...>]

On Wed, 22 Apr 2009, Rob May wrote:
> 2009/4/22 Jeremy White <jez...@ho...>:
> > I vote for adding the XP style request directly to perl.exe - in
> > almost all cases it's the "correct" thing to do and is easy enough
> > to remove (and indeed from PerlApp) should you need to. It's also
> > backward compatible so it wont harm Win 2000 users etc.

What exactly is the "easy" way to remove the new style common controls
from an app that requests them in an embedded MANIFEST?  On XP itself
you can provide an external perl.exe.manifest that would override the
embedded one, but on 2003, Vista, 2008 the embedded one always takes
precedence.  So you'll need to actually remove the embedded manifest
with a tool like mt.exe, but that is only available as part of the
Windows Platform SDK, so I would not really call it "trivial".

> I think I vote for it too, although I suspect that it'll cause some
> (minor) layout problems for some people, as I'm not sure that all the
> control decorations are the same on styled/non-styled controls.

There are some layout differences, so it will be visible in some apps.

> Last time I had some time to play (sadly I don't get much of that
> these days) I was looking at adding a manifest to GUI.dll - it's
> possible to add a manifest to a DLL and get the version 6 controls for
> any windows created by that DLL, even if the main APP doesn't have a
> manifest; however this depends on some stuff that's in the MS headers,
> and doesn't work with the mingw headers (and hence won't work with
> cygwin). I have a patch somewhere (but not with me at the moment).

Interesting.  I don't quite understand how this would work though, as
the names of the controls are registered globally, so I don't see how
you could mix old and new style controls inside a single process.

> There are also some API calls that can be used to turn styling on and
> off on a per-app and per-window basis, once you've got the v6 controls
> loaded ..... I haven't yet come up with a suitable strategy for
> introducing this thought; perhaps adding a v6 manifest to perl.exe
> will force me to find time to investigate further?

Could you find a link to some documentation about this so I can understand
how this is supposed to work?

Note that we'll also have to check with e.g. the wxPerl community, and
probably others to hear what they think about this.

Cheers,
-Jan

Re: [perl-win32-gui-users] XP styles support -- when?

[Rob M. <ro...@th...>]

2009/4/22 Jeremy White <jez...@ho...>:
> I vote for adding the XP style request directly to perl.exe - in almost all
> cases it's the "correct" thing to do and is easy enough to remove (and
> indeed from PerlApp) should you need to. It's also backward compatible so it
> wont harm Win 2000 users etc.

I think I vote for it too, although I suspect that it'll cause some
(minor) layout problems for some people, as I'm not sure that all the
control decorations are the same on styled/non-styled controls.

Last time I had some time to play (sadly I don't get much of that
these days) I was looking at adding a manifest to GUI.dll - it's
possible to add a manifest to a DLL and get the version 6 controls for
any windows created by that DLL, even if the main APP doesn't have a
manifest;  however this depends on some stuff that's in the MS
headers, and doesn't work with the mingw headers (and hence won't work
with cygwin).  I have a patch somewhere (but not with me at the
moment).

There are also some API calls that can be used to turn styling on and
off on a per-app and per-window basis, once you've got the v6 controls
loaded .....  I haven't yet come up with a suitable strategy for
introducing this thought; perhaps adding a v6 manifest to perl.exe
will force me to find time to investigate further?

I hope to find some time to get back to Win32::GUI development over the summer.

Rob.

Re: [perl-win32-gui-users] XP styles support -- when?

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

I vote for adding the XP style request directly to perl.exe - in almost all cases it's the "correct" thing to do and is easy enough to remove (and indeed from PerlApp) should you need to. It's also backward compatible so it wont harm Win 2000 users etc.
Cheers,
Jeremy.
From: ja...@ac...
To: jez...@ho...; ily...@so...; per...@li...
Subject: RE: [perl-win32-gui-users] XP styles support -- when?
Date: Tue, 21 Apr 2009 15:16:37 -0700



















Do you guys (users of Win32-GUI) have an opinion of perl.exe
always requesting XP style controls?

 

I think perl.exe needs an embedded manifest to properly specify
the requested elevation level on Windows Vista and later.  Once that happens it
will no longer be possible to request XP style controls simply by putting a
manifest into perl.exe.manifest because the mebedded manifest will take
precedence.

 

So what do you think, should perl.exe in that case request the
XP style controls or not?

 

Cheers,

-Jan

 







From: Jeremy White
[mailto:jez...@ho...] 

Sent: Tuesday, April 21, 2009 9:50 AM

To: ily...@so...; per...@li...

Subject: Re: [perl-win32-gui-users] XP styles support -- when?





 

Hi,



 





XP
styles (as I understand it) is a separate "thing" from
Win32::GUI and is controlled by a manifest file. This manifest file
is included inside the exe by PerlApp. If you have a manifest file for Perl
itself you'll get XP styles when you run your app via perl. Have a search on
this list on how to do that (its simple - but I dont have the details to hand).





 





As
for the tabstrip, I have seen this in the past and I've never found a solution
to it (again, I dont think it's a Win32::GUI thing). The way I have got around
this is to have a grey child window covering the while background, and add the
controls to the child window. Works well...





 





Cheers,





 





Jeremy.





 







Date: Tue, 21 Apr 2009 19:28:57 +0400

From: Ily...@so...

To: per...@li...

Subject: [perl-win32-gui-users] XP styles support -- when?



Hello
to everybody!

 

I'm
just interested if dear developers have any plans to introduce XP styles
support to Win32::GUI?

Being
compiled with ActiveState's PerlApp the application runs with XP styles but
tabstrip control drives me crazy because all other controls being placed on the
tabstrip still have gray background while the tabstrip's background is
different (white). Are there any _correct_ way to determine if XP styles
are active and draw controls correctly?

 

Thank
you in advance!

 

 

Regards,


Ilya

 



========================================================= Ce message et toutes les pieces jointes (ci-apres le "message")sont confidentiels et susceptibles de contenir des informationscouvertes par le secret professionnel. Ce message est etablia l'intention exclusive de ses destinataires. Toute utilisationou diffusion non autorisee interdite.Tout message electronique est susceptible d'alteration. La SOCIETE GENERALEet ses filiales declinent toute responsabilite au titre de ce messages'il a ete altere, deforme falsifie. ========================================================= This message and any attachments (the "message") are confidential,intended solely for the addressees, and may contain legally privilegedinformation. Any unauthorised use or dissemination is prohibited.E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor anyof its subsidiaries or affiliates shall be liable for the messageif altered, changed or falsified. =========================================================

 







Surfing
the web just got more rewarding. Download the New Internet Explorer 8




_________________________________________________________________
View your Twitter and Flickr updates from one place – Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/

Re: [perl-win32-gui-users] XP styles support -- when?

[Glenn L. <pe...@Ne...>]

On approximately 4/21/2009 3:16 PM, came the following characters from 
the keyboard of Jan Dubois:
> Do you guys (users of Win32-GUI) have an opinion of perl.exe always 
> requesting XP style controls?
> 
>  
> 
> I think perl.exe needs an embedded manifest to properly specify the 
> requested elevation level on Windows Vista and later.  Once that happens 
> it will no longer be possible to request XP style controls simply by 
> putting a manifest into perl.exe.manifest because the mebedded manifest 
> will take precedence.
> 
>  
> 
> So what do you think, should perl.exe in that case request the XP style 
> controls or not?


Well, what happens on WinNt sp4 or Win2k?  If they totally ignore the 
manifest, and things still work, then I have no problem with programs on 
XP looking different...

But my understanding is that some of the controls work different, and so 
things might not work? (I know there are several Open dialogs that have 
different parameters and results, for example.)  If that is the case, 
then it would seem that requesting XP style controls should only be done 
when the programmer says that is a good idea, and can handle both cases.

As far as Vista is concerned, if it needs separate malarky to operate, 
then there ought to be a way to obtain that malarky separately, even if 
it means a separate version of Perl to access the Vista-specific 
features.  Everything I've read about this "assembly" stuff sounds like 
sophisticated nonsense to me, and has given me more desire to keep 
running XP, and keep recommending XP to my clients.  When the day comes 
that XP-developed programs won't work in Windows-Assimilation version, 
I'll start recommending Linux.

-- 
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking

Re: [perl-win32-gui-users] XP styles support -- when?

[Jan D. <ja...@ac...>]

Do you guys (users of Win32-GUI) have an opinion of perl.exe always requesting XP style controls?

 

I think perl.exe needs an embedded manifest to properly specify the requested elevation level on Windows Vista and later.  Once that
happens it will no longer be possible to request XP style controls simply by putting a manifest into perl.exe.manifest because the
mebedded manifest will take precedence.

 

So what do you think, should perl.exe in that case request the XP style controls or not?

 

Cheers,

-Jan

 

From: Jeremy White [mailto:jez...@ho...] 
Sent: Tuesday, April 21, 2009 9:50 AM
To: ily...@so...; per...@li...
Subject: Re: [perl-win32-gui-users] XP styles support -- when?

 

Hi,

 

XP styles (as I understand it) is a separate "thing" from Win32::GUI and is controlled by a manifest file. This manifest file is
included inside the exe by PerlApp. If you have a manifest file for Perl itself you'll get XP styles when you run your app via perl.
Have a search on this list on how to do that (its simple - but I dont have the details to hand).

 

As for the tabstrip, I have seen this in the past and I've never found a solution to it (again, I dont think it's a Win32::GUI
thing). The way I have got around this is to have a grey child window covering the while background, and add the controls to the
child window. Works well...

 

Cheers,

 

Jeremy.

 

  _____  

Date: Tue, 21 Apr 2009 19:28:57 +0400
From: Ily...@so...
To: per...@li...
Subject: [perl-win32-gui-users] XP styles support -- when?

Hello to everybody!

 

I'm just interested if dear developers have any plans to introduce XP styles support to Win32::GUI?

Being compiled with ActiveState's PerlApp the application runs with XP styles but tabstrip control drives me crazy because all other
controls being placed on the tabstrip still have gray background while the tabstrip's background is different (white). Are there any
_correct_ way to determine if XP styles are active and draw controls correctly?

 

Thank you in advance!

 

 

Regards, 

Ilya

 

=========================================================
 
Ce message et toutes les pieces jointes (ci-apres le "message")
sont confidentiels et susceptibles de contenir des informations
couvertes par le secret professionnel. Ce message est etabli
a l'intention exclusive de ses destinataires. Toute utilisation
ou diffusion non autorisee interdite.
Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE
et ses filiales declinent toute responsabilite au titre de ce message
s'il a ete altere, deforme falsifie.
 
=========================================================
 
This message and any attachments (the "message") are confidential,
intended solely for the addressees, and may contain legally privileged
information. Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any
of its subsidiaries or affiliates shall be liable for the message
if altered, changed or falsified.
 
=========================================================

 

  _____  

Surfing the web just got more rewarding. Download the New Internet Explorer 8
<http://extras.uk.msn.com/internet-explorer-8/?ocid=T010MSN07A0716U> 

Re: [perl-win32-gui-users] XP styles support -- when?

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

Hi,
XP styles (as I understand it) is a separate "thing" from Win32::GUI and is controlled by a manifest file. This manifest file is included inside the exe by PerlApp. If you have a manifest file for Perl itself you'll get XP styles when you run your app via perl. Have a search on this list on how to do that (its simple - but I dont have the details to hand).
As for the tabstrip, I have seen this in the past and I've never found a solution to it (again, I dont think it's a Win32::GUI thing). The way I have got around this is to have a grey child window covering the while background, and add the controls to the child window. Works well...
Cheers,
Jeremy.
Date: Tue, 21 Apr 2009 19:28:57 +0400
From: Ily...@so...
To: per...@li...
Subject: [perl-win32-gui-users] XP styles support -- when?
















Hello to everybody!

 

I'm just interested if dear developers have
any plans to introduce XP styles support to Win32::GUI?

Being compiled with ActiveState's PerlApp
the application runs with XP styles but tabstrip control drives me crazy because
all other controls being placed on the tabstrip still have gray background
while the tabstrip's background is different (white). Are there any _correct_
way to determine if XP styles are active and draw controls correctly?

 

Thank you in advance!

 

 

Regards, 

Ilya





 



=========================================================

Ce message et toutes les pieces jointes (ci-apres le "message")
sont confidentiels et susceptibles de contenir des informations
couvertes par le secret professionnel. Ce message est etabli
a l'intention exclusive de ses destinataires. Toute utilisation
ou diffusion non autorisee interdite.
Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE
et ses filiales declinent toute responsabilite au titre de ce message
s'il a ete altere, deforme falsifie.

=========================================================

This message and any attachments (the "message") are confidential,
intended solely for the addressees, and may contain legally privileged
information. Any unauthorised use or dissemination is prohibited.
E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any
of its subsidiaries or affiliates shall be liable for the message
if altered, changed or falsified.

=========================================================

_________________________________________________________________
View your Twitter and Flickr updates from one place – Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/

Re: [perl-win32-gui-users] XP styles support -- when?

[Jason P. <ma...@wa...>]

If you a search the lest you should find reference to the small file that
needs to be added so that the programs via perl will all use default XP
styles, search for "XP" and "manifest"

2009/4/21 Ilya BANDORIN <Ily...@so...>

>  Hello to everybody!
>
>
>
> I'm just interested if dear developers have any plans to introduce XP
> styles support to Win32::GUI?
>
> Being compiled with ActiveState's PerlApp the application runs with XP
> styles but tabstrip control drives me crazy because all other controls being
> placed on the tabstrip still have gray background while the tabstrip's
> background is different (white). Are there any _*correct*_ way to
> determine if XP styles are active and draw controls correctly?
>
>
>
> Thank you in advance!
>
>
>
>
>
> Regards,
>
> Ilya
>
>
>
> =========================================================
>
> Ce message et toutes les pieces jointes (ci-apres le "message")
> sont confidentiels et susceptibles de contenir des informations
> couvertes par le secret professionnel. Ce message est etabli
> a l'intention exclusive de ses destinataires. Toute utilisation
> ou diffusion non autorisee interdite.
> Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE
> et ses filiales declinent toute responsabilite au titre de ce message
> s'il a ete altere, deforme falsifie.
>
> =========================================================
>
> This message and any attachments (the "message") are confidential,
> intended solely for the addressees, and may contain legally privileged
> information. Any unauthorised use or dissemination is prohibited.
> E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any
> of its subsidiaries or affiliates shall be liable for the message
> if altered, changed or falsified.
>
> =========================================================
>
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>



-- 
Maximus*
WarheadsSE
MaxSource

[perl-win32-gui-users] XP styles support -- when?

[Ilya B. <Ily...@so...>]

Hello to everybody!

 

I'm just interested if dear developers have any plans to introduce XP styles support to Win32::GUI?

Being compiled with ActiveState's PerlApp the application runs with XP styles but tabstrip control drives me crazy because all other controls being placed on the tabstrip still have gray background while the tabstrip's background is different (white). Are there any _correct_ way to determine if XP styles are active and draw controls correctly?

 

Thank you in advance!

 

 

Regards, 

Ilya



 

Re: [perl-win32-gui-users] GUI Builder (gb109)

[Zuhair K. <zi...@gm...>]

Hi, there is an error talking about an undefined subroutine at line 623 of gb
file, if you try to save, i've fix it.
The error was: $file = GUI::GetOpenFileName [...], instead of
Win32::GUI::GetOpenFileName.
Regards

-- 
View this message in context: http://www.nabble.com/GUI-Builder-%28gb109%29-tp15762632p23100882.html
Sent from the perl-win32-gui-users mailing list archive at Nabble.com.