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

Re: [perl-win32-gui-hackers] StatusBar

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

On 26/09/2007, Glenn Linderman <pe...@ne...> wrote:
> The following script can count, but nothing appears in the StatusBar
> itself...

I can't immediately work out how to put anything into the status bar
when it's in simple mode.  I'm sure I've done it before, but can't
find anything right now.

> In looking at StatusBar.xs, I find that StatusBar_onParseOption seems to
> have mismatched } ... like there might be a missing { after the if.  In
> fact, it looks like there might be missing () around the if clause too.
>   Makes me wonder if this code actually is included in GUI.

I see you've discoveded the macro-hell that expands this code to compile OK!

Here's a version that works:

#!perl
use strict;
use warnings;

use Win32::GUI();

my $foo = 0;

my $mw = Win32::GUI::Window->new(
    -size         => [200, 200],
);

my $sb = $mw->AddStatusBar(
    -text    => "Initial Text",
    -onClick => sub { $_[0]->Text('Foo: ' . $foo++); 0; },
);

$mw->Show();
Win32::GUI::Dialog();
__END__

Regards,
Rob.

[perl-win32-gui-hackers] Revised - Re: CustomDraw patch for 1.05

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

But I forgot the main module, sorry.
This time with CustomDraw.pm added.

2007/9/27, Reini Urban <ru...@x-...>:
> I found time to cleanup and re-apply my old CustomDraw patch to 1.05.


-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[perl-win32-gui-hackers] CustomDraw patch for 1.05

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

I found time to cleanup and re-apply my old CustomDraw patch to 1.05.

-- 
Reini Urban
http://phpwiki.org/              http://murbreak.at/
http://spacemovie.mur.at/   http://helsinki.at/

[perl-win32-gui-hackers] 5.9.5 carp patch

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

Attached is a Carp patch for 5.9.5.

t/01_load............................NOK 2/3#   at t/01_load.t line 38.
#     Tried to use 'Win32::GUI::Constants'.
#     Error:  syntax error at 
/cygdrive/r/PERL/Win32-GUI/Win32-GUI-Constants/../
blib/lib/Win32/GUI/Constants.pm line 274, near "Carp::croak qq(Can't 
continue after import errors)"

and so on.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

Re: [perl-win32-gui-hackers] cygwin patches for 1.05

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

Reini Urban schrieb:
> Robert May schrieb:
>> I haven't forgotten it, just don't have enough tuits.   There's more
>> than just the CustomDraw stuff that I'm sitting on from you (including
>> a promise to change the way the samples get copied so that make
>> doesn't spew lots of warnings)
> 
> Ah yes almost forgot that. Just tried a new cvs up and make ended again 
> at copying the samples.

My patch fixed that, for CVS only:
$ cvs up
$ make
...
Creating per package POD for Win32::GUI v1.05_02 on 31 Jul 2007
/bin/perl.exe "-MExtUtils::Command" -e mkpath blib/lib/Win32/GUI/demos
cp samples/* blib/lib/Win32/GUI/demos
cp: omitting directory `samples/CVS'
make: [demos] Error 1 (ignored)

Re: [perl-win32-gui-hackers] cygwin patches for 1.05

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

On 30/07/07, Robert May <rob...@us...> wrote:
>
> Changes are in my local copy, and will make it to CVS shortly.

Quicker than I expected!  In CVS now.

Regards,
Rob.

Re: [perl-win32-gui-hackers] cygwin patches for 1.05

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

Robert May schrieb:
> On 28/07/07, Reini Urban <ru...@x-...> wrote:
>> Attached is simple patch which fixes two issues:
>>
>> * GUI.rc is readonly in the downloaded archive, and therefore
>>    build_tools/updateRC.pl fails to write it.
> 
> Thanks.  Applied with additional tweaks to updateRC.pl and Makefile,
> so that GUI.rc does not get re-written if it does not change.
> 
>> * gcc-3.4 issues a warning if -Wdeclaration-after-statement is used
>>    with .cpp files (c++ mode).
> 
> Thanks, applied.  I assume it is a later version of MakeMaker than I
> have (6.17) that adds the -Wdeclaration-after-statement flag, as I
> don't see any warnings when building under cygwin with gcc 3.4.4.
> 
>> And I also waiting for my big CustomDraw patch.
> 
> I haven't forgotten it, just don't have enough tuits.   There's more
> than just the CustomDraw stuff that I'm sitting on from you (including
> a promise to change the way the samples get copied so that make
> doesn't spew lots of warnings)

Ah yes almost forgot that. Just tried a new cvs up and make ended again 
at copying the samples.

> Changes are in my local copy, and will make it to CVS shortly.

Thanks. I use it daily.

Re: [perl-win32-gui-hackers] cygwin patches for 1.05

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

On 28/07/07, Reini Urban <ru...@x-...> wrote:
> Attached is simple patch which fixes two issues:
>
> * GUI.rc is readonly in the downloaded archive, and therefore
>    build_tools/updateRC.pl fails to write it.

Thanks.  Applied with additional tweaks to updateRC.pl and Makefile,
so that GUI.rc does not get re-written if it does not change.

> * gcc-3.4 issues a warning if -Wdeclaration-after-statement is used
>    with .cpp files (c++ mode).

Thanks, applied.  I assume it is a later version of MakeMaker than I
have (6.17) that adds the -Wdeclaration-after-statement flag, as I
don't see any warnings when building under cygwin with gcc 3.4.4.

> And I also waiting for my big CustomDraw patch.

I haven't forgotten it, just don't have enough tuits.   There's more
than just the CustomDraw stuff that I'm sitting on from you (including
a promise to change the way the samples get copied so that make
doesn't spew lots of warnings)

Changes are in my local copy, and will make it to CVS shortly.

Regards,
Rob.

[perl-win32-gui-hackers] cygwin patches for 1.05

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

Attached is simple patch which fixes two issues:

* GUI.rc is readonly in the downloaded archive, and therefore
   build_tools/updateRC.pl fails to write it.

* gcc-3.4 issues a warning if -Wdeclaration-after-statement is used
   with .cpp files (c++ mode).

And I also waiting for my big CustomDraw patch.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/
http://helsinki.at/  http://spacemovie.mur.at/

[perl-win32-gui-hackers] More commits

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

All,

Some more commits, bring the CVS repository up to date with my local copy.

For this set of changes I'm particularly interested in whether I've
broken the '-prompt' option to Textfield, or indeed anything else in
the Textfield constructor.  So, so if you have any scripts that use
Textfields, please run them up and let me know how you get on (and
whether you use the -prompt option or not).

Regards,
Rob.

+ [Robert May] : 16 July 2007 -  Bug Fixes
    - GUI.pm - fix Win32::GUI::Imagelist::AddMasked (Tracker: 1734697)
    - GUI.pm - fix -prompt option to Textfield (Tracker: 1734697)
    - GUI.pm - remove constants from AcceptFiles() [Joseph Cordero]
    - Treeview.xs - fix GetParent() method to get the parent window, rather
      than the parent node if called with no arguements. [Salvador Oritz]
    - GUI.xs - modify Dialog() and DoEvents() to allow for dialog navigation
      to work within MDI child windows. [Salvador Oritz]
    --- Win32::GUI::ReleaseNotes ---
    - RN_1_06.pod - bring up to date with new changes

[perl-win32-gui-hackers] Today's commits

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

If you monitor the 'commit' mailing list you'll see that I just
committed all the changes I have been holding.  Here's the CHANGELOG
entries:

+ [Robert May] : 15 July 2007 -  Bug Fixes
    - GUI.pm - fix bltr direction in Animate Window [Tim Hansell]
    - Comboxbox.xs, GUI.pm - fix options so use of -simple, -dropdown and
      -dropdownlist together have a more predictable result.
      Update docs. [Glenn Linderman]
    - DC.xs - Fix Polygon(), PolyBezier(), PolyBezierTo(), PolyLine(),
      PolyLineTo(). [George]
    - DC.xs - Fix DrawText() documentation
    - DC.xs - Rework DrawFrameControl() to allow DFCS_ADJUSTRECT to modify
      input parameters
    - GUI_Events.cpp, GUI_MessageLoops.cpp - handle window being destroyed in
      callback by checking validity with IsWindow(hwnd) in many places
    - Listview.xs - Correct second arg to OnBeginLabelEdit
      [Glenn Munroe: Tracker 1706901]
    - RichEdit.xs - add alias LimitText() to correct spelling of LimiteText()
    - TYPEMAP - correct UINT to be T_UV
    - Toolbar.xs - LoadImages() correct typo in docs
    - GUI.xs - tidy up the implementation of the Scroll() function, make it
      really return UNDEF on failure, and improve documentation.
    --- Win32::GUI::Constants ---
    - Constants.PL, Tags.pm, 52_tags.t - add a whole bunch more
constants (mainly control
      notification codes), and update tests
    --- Win32::GUI::Scintilla ---
    - Scintilla.PL - fix line count in SaveFile(). Fix buffer sizes in various
      places.

I think that everything here has been discussed on the list at some
point in the last 6 months, so nothing too surprising I hope.

I'm still holding onto a few changes, but hope to get them into CVS in
the next week or so, after which I think it'll be time for a release.

I'd appreciate reports of any problems, especially build problems I've
introduced.  If you do sync a copy from CVS and build, please report
back, even if you don't see any problems, so I can gauge how we're
doing.

Regards,
Rob.

-- 
Please update your address book with my new email address:
ro...@th...

Re: [perl-win32-gui-hackers] MDI apps and keyboard navigation (dialogui)

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

On 15/07/07, Salvador Ortiz Garc=EDa <so...@ms...> wrote:
> Right now when using the MDI TAB navigation just doesn't works, as a
> test just change the MDI.pl sample by adding a second Textfield control,
> make them singleline (to keep it simple), add the proper tabstop =3D> 1
> and try adding a dialogui=3D>1 either to the MDIChild or to the MDIFrame.
>
> (Complete test case at request)
>
> The first case (dialogui=3D>1 in MDIChild) simply doesn't works because i=
n
> the main loop of Dialog in GUI.xs, fIsDialog is tested only on the top
> window.
>
> In the second case (dialogui=3D>1 in MDIFrame) a first TAB seems to work,
> but the focus doesn't move past the first control.
>
> Worse, when I try adding a -controlparent =3D> 1 to the MDIChild, a few
> TABs results in all the application freezing.
>
> The attached patch cures that, allowing dialogui=3D>1 in the MDIChild and
> calling IsDialogMessage in the context of that window.
>
> Comments?

Thanks.  I've applied this to my local copy, and will sync it into CVS
once I've had a chance to give it a spin.  MDI windows aren't
something I use much (at all?), so I'll only be making sure it doesn't
break anything else.

Regards,
Rob.

Re: [perl-win32-gui-hackers] TreeView::GetParent and proper subclassing

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

On 26/06/07, Robert May <rob...@us...> wrote:
> On 22/06/07, Salvador Ortiz Garc=EDa <so...@ms...> wrote:
> > Hi all,
> >
> > This is my first post to the list, so forgive me if this was discussed
> > before.
>
> I don't think it has been discussed before,  but I have noticed it
> myself.  I didn't find it enough of an issue to want to deal with it.
>
> >
> > Reflecting the Win32 API, Win32::GUI::TreeView has a GetParent method t=
o
> > get the parent node (HTREEITEM) of a node, nothing related with the
> > GetParent common method of Win32::GUI.
> >
> > The common call
> >
> >   my $parentWin =3D $SomeControl->GetParent();
> >
> > simply don't work when $SomeContros isa TreeView, so right now when I
> > need the parent window of the TV control we must use an ugly workaround=
:
> >
> >   my $parentWin =3D Win32::GUI::GetParent($TreeView);
> >
> > The following patch cures that, properly subclassing the TreeView with
> > only minimal semantic changes IMHO:
> >
> > When called without NODE or with NODE equal zero (NULL, an invalid
> > HTREEITEM value anyway) now TreeView::GetParent() returns the parent
> > window, if any, or undef as Win32::GUI::GetParent() does.
> >
> > Any other value for NODE returns the handler of the parent NODE (or NUL=
L
> > at the root NODE) as documented.
> >
> > So the following works as spected:
> >
> >   sub TV_NodeClick {  # Click on a node, OEM form
> >     my($TreeView, $node) =3D @_;
> >     my $parentWin =3D $TreeView->GetParent();
> >     my $parentNode =3D $TreeView->GetParent($node);
> >     ...
> >
> > Comments?
>
> I'm a bit short of time at the moment, but I'd like to give this some
> more though, as one of the things I strive for is backwards
> compatibility and I'm not completely convinced.  I think the idea is
> OK, but I'd like to tinker with the implementation a little ... give
> me a couple of weeks to mull it over.
>
> Many thanks for the contribution.
>
> Regards,
> Rob.

OK, having thought about it I propose the following.  The only
significant change is how I determine the behaviour.  There is
probably code like this in the field:

  my $parent_node =3D $tv->GetParent($node);

where $node is calculated.  It would be surprising if when $node is 0
(or indeed undef) to get back a Win32::GUI::Window object.  So I check
the number of items actually passed, and only fallback to the
GetParent() window method if no arguments are passed:

  my $parent_window_object =3D $tv->GetParent();

Regards,
Rob.

I haven't actually compiled and tested this yet:

    #######################################################################=
####
    # (@)METHOD:GetParent(NODE)
    # Returns the handle of the parent node for the given B<NODE>.
    #
    # NOTE: With no B<NODE> parameter this is the standard
    # L<GetParent()|Win32::GUI::Reference::Methods/GetParent>
    # method, returning the parent window.
HTREEITEM
GetParent(handle,item =3D NULL)
    HWND handle
    HTREEITEM item
CODE:
    if(items =3D=3D 1) { /* NOTE this is the XS defined 'items' var, not 'i=
tem' */
        SV   *SvParent;
        HWND parentHandle =3D GetParent(handle);

        if (parentHandle && (SvParent =3D
SV_SELF_FROM_WINDOW(parentHandle)) && SvROK(SvParent)) {
            XPUSHs(SvParent);
            XSRETURN(1);
        }
        else {
            XSRETURN_UNDEF;
        }
    }
    else {
        RETVAL =3D TreeView_GetParent(handle, item);
    }
OUTPUT:
    RETVAL

[perl-win32-gui-hackers] MDI apps and keyboard navigation (dialogui)

[Salvador O. <so...@ms...>]

Hi all,
        
Right now when using the MDI TAB navigation just doesn't works, as a
test just change the MDI.pl sample by adding a second Textfield control,
make them singleline (to keep it simple), add the proper tabstop => 1
and try adding a dialogui=>1 either to the MDIChild or to the MDIFrame.
        
(Complete test case at request)
        
The first case (dialogui=>1 in MDIChild) simply doesn't works because in
the main loop of Dialog in GUI.xs, fIsDialog is tested only on the top
window.
        
In the second case (dialogui=>1 in MDIFrame) a first TAB seems to work,
but the focus doesn't move past the first control.
        
Worse, when I try adding a -controlparent => 1 to the MDIChild, a few
TABs results in all the application freezing.
        
The attached patch cures that, allowing dialogui=>1 in the MDIChild and
calling IsDialogMessage in the context of that window.
        
Comments?
        
Regards.
        
-- 
Salvador Ortiz <so...@ms...>

Re: [perl-win32-gui-hackers] Win64-GUI

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

On 22/06/07, jez...@ho... <jez...@ho...> wrote:
> With the (slow) rise of 64 bit computing is there a need to consider a 64 bit version of Win32-GUI? Activestate now has a 64 bit version of Perl supported with all their tools (i.e., PerlApp) for windows.
>
> Thoughts on benefits, risks and effort involved?

It'd be a nice goal, but for me it sits firmly in the camp of full
unicode support:  I don't think it's worth it on the current code
base.

As you know I've been talking about a comlete re-write, and I hope to
get time in the next few months to put together a proof of concept.
However, I wouldn't want to deter anyone else from investigating, as
it may not be as bad as I am imagining.

Furthermore I don't have a 64-bit environment to start playing with.

Regards,
Rob.

Re: [perl-win32-gui-hackers] TreeView::GetParent and proper subclassing

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

On 22/06/07, Salvador Ortiz Garc=EDa <so...@ms...> wrote:
> Hi all,
>
> This is my first post to the list, so forgive me if this was discussed
> before.

I don't think it has been discussed before,  but I have noticed it
myself.  I didn't find it enough of an issue to want to deal with it.

>
> Reflecting the Win32 API, Win32::GUI::TreeView has a GetParent method to
> get the parent node (HTREEITEM) of a node, nothing related with the
> GetParent common method of Win32::GUI.
>
> The common call
>
>   my $parentWin =3D $SomeControl->GetParent();
>
> simply don't work when $SomeContros isa TreeView, so right now when I
> need the parent window of the TV control we must use an ugly workaround:
>
>   my $parentWin =3D Win32::GUI::GetParent($TreeView);
>
> The following patch cures that, properly subclassing the TreeView with
> only minimal semantic changes IMHO:
>
> When called without NODE or with NODE equal zero (NULL, an invalid
> HTREEITEM value anyway) now TreeView::GetParent() returns the parent
> window, if any, or undef as Win32::GUI::GetParent() does.
>
> Any other value for NODE returns the handler of the parent NODE (or NULL
> at the root NODE) as documented.
>
> So the following works as spected:
>
>   sub TV_NodeClick {  # Click on a node, OEM form
>     my($TreeView, $node) =3D @_;
>     my $parentWin =3D $TreeView->GetParent();
>     my $parentNode =3D $TreeView->GetParent($node);
>     ...
>
> Comments?

I'm a bit short of time at the moment, but I'd like to give this some
more though, as one of the things I strive for is backwards
compatibility and I'm not completely convinced.  I think the idea is
OK, but I'd like to tinker with the implementation a little ... give
me a couple of weeks to mull it over.

Many thanks for the contribution.

Regards,
Rob.

>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D CUT =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- Win32-GUI/TreeView.xs       2006-04-13 17:17:07.000000000 -0500
> +++ /home/sog/dosdir/work/Win32-GUI-1.05_01/TreeView.xs 2007-06-22
> 00:59:20.000000000 -0500
> @@ -583,15 +583,32 @@
>
>
> #########################################################################=
##     # (@)METHOD:GetParent(NODE)
> -    # Returns the handle of the parent node for the given B<NODE>.
> -HTREEITEM
> -GetParent(handle,item)
> +    # Returns the handle of the parent node for the B<NODE>, if given
> +    # or the parent window of the TV control if not.
> +void
> +GetParent(handle,item =3D 0)
>      HWND handle
>      HTREEITEM item
> -CODE:
> -    RETVAL =3D TreeView_GetParent(handle, item);
> -OUTPUT:
> -    RETVAL
> +PREINIT:
> +    HWND parentHandle;
> +    SV* SvParent;
> +PPCODE:
> +    if (item) {
> +       XSRETURN_IV((long) TreeView_GetParent(handle, item));
> +    } else {
> +      parentHandle =3D GetParent(handle);
> +      if (parentHandle !=3D NULL) {
> +        SvParent =3D SV_SELF_FROM_WINDOW(parentHandle);
> +       if (SvParent !=3D NULL && SvROK(SvParent)) {
> +          XPUSHs(SvParent);
> +       } else {
> +          XSRETURN_UNDEF;
> +        }
> +      } else {
> +         XSRETURN_UNDEF;
> +      }
> +    }
> +
>
>
> #########################################################################=
##     # (@)METHOD:GetPrevSibling(NODE)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CUT =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>
>
> Bests Regards.
>
> --
> Salvador Ortiz.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
> http://perl-win32-gui.sourceforge.net/
>


--=20
Please update your address book with my new email address:
ro...@th...

[perl-win32-gui-hackers] Win64-GUI

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

All,

With the (slow) rise of 64 bit computing is there a need to consider a 64 bit version of Win32-GUI? Activestate now has a 64 bit version of Perl supported with all their tools (i.e., PerlApp) for windows.

Thoughts on benefits, risks and effort involved?

Cheers,

Jeremy.

[perl-win32-gui-hackers] TreeView::GetParent and proper subclassing

[Salvador O. <so...@ms...>]

Hi all,

This is my first post to the list, so forgive me if this was discussed
before.

Reflecting the Win32 API, Win32::GUI::TreeView has a GetParent method to
get the parent node (HTREEITEM) of a node, nothing related with the
GetParent common method of Win32::GUI.

The common call

  my $parentWin = $SomeControl->GetParent();

simply don't work when $SomeContros isa TreeView, so right now when I
need the parent window of the TV control we must use an ugly workaround:

  my $parentWin = Win32::GUI::GetParent($TreeView);

The following patch cures that, properly subclassing the TreeView with
only minimal semantic changes IMHO: 

When called without NODE or with NODE equal zero (NULL, an invalid
HTREEITEM value anyway) now TreeView::GetParent() returns the parent
window, if any, or undef as Win32::GUI::GetParent() does. 

Any other value for NODE returns the handler of the parent NODE (or NULL
at the root NODE) as documented.

So the following works as spected:
 
  sub TV_NodeClick {  # Click on a node, OEM form
    my($TreeView, $node) = @_;
    my $parentWin = $TreeView->GetParent();
    my $parentNode = $TreeView->GetParent($node);
    ...

Comments?

========= CUT ==========
--- Win32-GUI/TreeView.xs       2006-04-13 17:17:07.000000000 -0500
+++ /home/sog/dosdir/work/Win32-GUI-1.05_01/TreeView.xs 2007-06-22
00:59:20.000000000 -0500
@@ -583,15 +583,32 @@


###########################################################################     # (@)METHOD:GetParent(NODE)
-    # Returns the handle of the parent node for the given B<NODE>.
-HTREEITEM
-GetParent(handle,item)
+    # Returns the handle of the parent node for the B<NODE>, if given
+    # or the parent window of the TV control if not.
+void
+GetParent(handle,item = 0)
     HWND handle
     HTREEITEM item
-CODE:
-    RETVAL = TreeView_GetParent(handle, item);
-OUTPUT:
-    RETVAL
+PREINIT:
+    HWND parentHandle;
+    SV* SvParent;
+PPCODE:
+    if (item) {
+       XSRETURN_IV((long) TreeView_GetParent(handle, item));
+    } else {
+      parentHandle = GetParent(handle);
+      if (parentHandle != NULL) {
+        SvParent = SV_SELF_FROM_WINDOW(parentHandle);
+       if (SvParent != NULL && SvROK(SvParent)) {
+          XPUSHs(SvParent);
+       } else {
+          XSRETURN_UNDEF;
+        }
+      } else {
+         XSRETURN_UNDEF;
+      }
+    }
+


###########################################################################     # (@)METHOD:GetPrevSibling(NODE)
=========== CUT ==============


Bests Regards.

-- 
Salvador Ortiz.

Re: [perl-win32-gui-hackers] AxWindow compile fails with C2440 error on Visual Studio 2005

[Blair S. <bs...@nu...>]

I have resolved this by disabling STRICT type checking. I.e. remove 
-DNO_STRICT from Makefile.

Blair Sutton wrote:
> Whilst trying to compile AxWindow module from Win32:GUI 1.05 on Visual 
> Studio 2005 I get the following error:-
>
> C:\Program Files\Microsoft Visual Studio 
> 8\VC\ATLMFC\INCLUDE\atlwin.h(3281) : error C2440: 'return' : cannot 
> convert from 'INT_PTR (__stdcall *)(HWND,
> UINT,WPARAM,LPARAM)' to 'DLGPROC'
>        This conversion requires a reinterpret_cast, a C-style cast or 
> function-style cast
>        C:\Program Files\Microsoft Visual Studio 
> 8\VC\ATLMFC\INCLUDE\atlwin.h(3280) : while compiling class template 
> member function 'DLGPROC 
> ATL::CDialogImplBaseT<TBase>::GetDialogProc(void)'
>        with
>        [
>            TBase=ATL::CWindow
>        ]
>        C:\Program Files\Microsoft Visual Studio 
> 8\VC\ATLMFC\INCLUDE\atlwin.h(3819) : see reference to class template 
> instantiation 'ATL::CDialogImplBaseT<TBase>' being compiled
>        with
>        [
>            TBase=ATL::CWindow
>        ]
>        C:\Program Files\Microsoft Visual Studio 
> 8\VC\ATLMFC\INCLUDE\atlwin.h(3851) : see reference to class template 
> instantiation 'ATL::CSimpleDialog<t_wDlgTemplateID,t_bCenter>' being 
> compiled
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
> 8\VC\BIN\cl.EXE"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
> 8\VC\BIN\nmake.exe"' : return code '0x2'
> Stop.
>
> I have tried to search for the cause of the problem but to no avail. 
> Although my C++ is pretty good I cannot easily get my head around 
> where template is being instantiated in the XS code.
>
> Any ideas?
>
> Blair
>
>

[perl-win32-gui-hackers] AxWindow compile fails with C2440 error on Visual Studio 2005

[Blair S. <bs...@nu...>]

Whilst trying to compile AxWindow module from Win32:GUI 1.05 on Visual 
Studio 2005 I get the following error:-

C:\Program Files\Microsoft Visual Studio 
8\VC\ATLMFC\INCLUDE\atlwin.h(3281) : error C2440: 'return' : cannot 
convert from 'INT_PTR (__stdcall *)(HWND,
UINT,WPARAM,LPARAM)' to 'DLGPROC'
        This conversion requires a reinterpret_cast, a C-style cast or 
function-style cast
        C:\Program Files\Microsoft Visual Studio 
8\VC\ATLMFC\INCLUDE\atlwin.h(3280) : while compiling class template 
member function 'DLGPROC ATL::CDialogImplBaseT<TBase>::GetDialogProc(void)'
        with
        [
            TBase=ATL::CWindow
        ]
        C:\Program Files\Microsoft Visual Studio 
8\VC\ATLMFC\INCLUDE\atlwin.h(3819) : see reference to class template 
instantiation 'ATL::CDialogImplBaseT<TBase>' being compiled
        with
        [
            TBase=ATL::CWindow
        ]
        C:\Program Files\Microsoft Visual Studio 
8\VC\ATLMFC\INCLUDE\atlwin.h(3851) : see reference to class template 
instantiation 'ATL::CSimpleDialog<t_wDlgTemplateID,t_bCenter>' being 
compiled
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\cl.EXE"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.

I have tried to search for the cause of the problem but to no avail. 
Although my C++ is pretty good I cannot easily get my head around where 
template is being instantiated in the XS code.

Any ideas?

Blair

Re: [perl-win32-gui-hackers] User32 error in script

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

Robert May wrote:
> I can see the problem clearly.  It's because you're 
> destroying a window while in the middle of processing an event sent to 
> it, and the code isn't expecting that, and so ends up trying to access 
> some of the window's properties after they have been freed.  I've got a 
> solution to most of it, but there are a couple of areas where I'm not 
> sure how to resolve it ... some more thought required, but I'll try to 
> get a fix into the next release.
> 
> For the record, here's the shortest example I can come up with that 
> exhibits the problem:
> 
> #!perl -w
> use strict;
> use warnings;
> 
> use Win32::GUI();
> 
> my $mw;
> 
> $mw = Win32::GUI::Window->new(
>      -onKeyDown => sub { undef $mw; return -1; },
> );
> 
> $mw->Show();
> Win32::GUI::Dialog();
> __END__

Hackers,

Would you expect the above sample to exit cleanly?

The problem is that if we destroy a window during a callback, perlud 
gets freed before the callback returns;  the code then has a non-NULL 
perlud pointer, that points into freed memory.  The fact that this only 
exhibits a crash on Win98 is, I think, just luck.

I've now got checks in place in all the places that I can see that we 
attempt to access perlud after a callback, and the crash appears to be 
fixed, but I'm left with one issue:

return -1 results in us trying to exit the Dialog() loop using
   PostMessage(hwnd, WM_EXITLOOP, (WPARAM) -1, 0);

but hwnd has already been destroyed, so the message never gets 
delivered.  In the above example pressing a key causes the window to 
disappear, but leaves Dialog() spinning, and the script never finishes.

I can change the PostMessage(..) to
   PostThreadMessage(GetCurrentThreadId(), WM_EXITLOOOP, (WPARAM) -1, 0);

and all tests pass, and I haven't (yet) found a problem with it, but it 
feels like quite a fundamental change to me.  Can anyone see a problem 
with it, or propose a better solution?  Or should I not worry?

Regards,
Rob.

Re: [perl-win32-gui-hackers] Global destruction error and UserData problem

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

Glenn W Munroe wrote:
> Still, for now, I will keep plugging away using UserData, and will get back
> to you if I can describe something that makes more sense than this!

Please do.

Rob.

Re: [perl-win32-gui-hackers] Global destruction error and UserData problem

[Glenn W M. <gwm...@gm...>]

Thanks, Rob. I really appreciate the work you've put into this module
recently, and I'm sure everyone on the list would agree.

As I was adding my comments below, I decided to have a go at producing a
minimal example demonstrating the problem. At some point, I realised that
the original program was working! Doubting my own sanity, I ran last night's
backup and it, too was working. It is quite possible that I *am* cracking
up, but there may just be a pointer problem somewhere.

Still, for now, I will keep plugging away using UserData, and will get back
to you if I can describe something that makes more sense than this!

Cheers,
Glenn

> -----Original Message-----
> From: Robert May [mailto:rm...@po...]
> Sent: 08 February 2007 19:32
> To: Glenn W Munroe
> Cc: per...@li...
> Subject: Re: [perl-win32-gui-hackers] Global destruction error and
> UserData problem
> 
> Glenn W Munroe wrote:
> > I've been working on an old project and am seeing an old problem and a
> new
> > one. The old problem is the:
> >
> > "(in cleanup) Can't call method "FETCH" on an undefined value..."
> >
> > message on program exit. Rob thought he had this one pinned down, but it
> > seems there's still a problem somewhere.
> 
> You say later that you're using v1.05.  The fix for this isn't in 1.05,
> it's only in CVS.
> 

[Glenn W Munroe] 
Doh! Note to self: RTFM

> > The new problem is with the new UserData method. I tried saving a hash
> > reference, but am getting this error:
> >
> > Can't use string ("1") as a HASH ref while "strict refs" in use...
> >
> > on use of the expression
> >
> > $mw->tbTab->UserData()->{key}
> 
> Can you split this into 2:
>    my $somescalar = $mw->tbTab->UserData();
>    my $value = $hashref->{key};
> 
> and have a look at what $somescalar has in it - the error suggests that
> you're not getting a hashref back from the user data, and if not, then
> we'll need to have a look at where you set it ...
> 

[Glenn W Munroe] 
OK... $somescalar gets the value 1.

I actually set the value right after the tabstrip is created with these
lines:

my $rhTab = { ambiguous => 0, change => 0 };
$mw->tbTab->UserData($rhTab);

> > I also saw the message:
> >
> > "userData ref count not 1 during destruction - please report this..."
> 
> If you can reproduce this, I'd like to hear about it, as there shouldn't
> be any way this can happen!
> 

[Glenn W Munroe] 

I will have a shot at stripping the code down as much as possible. If I can
recreate this, I'll let you know.

> > I am using version 1.05 of the module. I know the next request will be
> to
> > provide a minimal example demonstrating the problems, but this program
> is a
> > labour of love and is almost 4000 lines long! I can work around both
> > problems and am only reporting them for the record as it was requested.
> Then
> > again, I don't mind sending a copy of the program if anybody wants to
> look
> > into it.
> 
> Let's see if we can get there without having to share 4000 lines of code
> :-)
> 
> Thanks for taking the time to report these problems.
> 
> Regards,
> Rob.

Re: [perl-win32-gui-hackers] Global destruction error and UserData problem

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

Glenn W Munroe wrote:
> I've been working on an old project and am seeing an old problem and a new
> one. The old problem is the:
> 
> "(in cleanup) Can't call method "FETCH" on an undefined value..."
> 
> message on program exit. Rob thought he had this one pinned down, but it
> seems there's still a problem somewhere.

You say later that you're using v1.05.  The fix for this isn't in 1.05, 
it's only in CVS.

> The new problem is with the new UserData method. I tried saving a hash
> reference, but am getting this error:
> 
> Can't use string ("1") as a HASH ref while "strict refs" in use...
> 
> on use of the expression
> 
> $mw->tbTab->UserData()->{key}

Can you split this into 2:
   my $somescalar = $mw->tbTab->UserData();
   my $value = $hashref->{key};

and have a look at what $somescalar has in it - the error suggests that 
you're not getting a hashref back from the user data, and if not, then 
we'll need to have a look at where you set it ...

> I also saw the message:
> 
> "userData ref count not 1 during destruction - please report this..."

If you can reproduce this, I'd like to hear about it, as there shouldn't 
be any way this can happen!

> I am using version 1.05 of the module. I know the next request will be to
> provide a minimal example demonstrating the problems, but this program is a
> labour of love and is almost 4000 lines long! I can work around both
> problems and am only reporting them for the record as it was requested. Then
> again, I don't mind sending a copy of the program if anybody wants to look
> into it.

Let's see if we can get there without having to share 4000 lines of code :-)

Thanks for taking the time to report these problems.

Regards,
Rob.

Re: [perl-win32-gui-hackers] [perl-win32-gui-users] User32 error in script [Was: Keyboard events difference on WinXP and 98]

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

Waldemar Biernacki wrote:
> Robert,
> 
> thank you for your efforts and email, I'll try my best to clarify...

Thank you.  I can see the problem clearly.  It's because you're 
destroying a window while in the middle of processing an event sent to 
it, and the code isn't expecting that, and so ends up trying to access 
some of the window's properties after they have been freed.  I've got a 
solution to most of it, but there are a couple of areas where I'm not 
sure how to resolve it ... some more thought required, but I'll try to 
get a fix into the next release.

For the record, here's the shortest example I can come up with that 
exhibits the problem:

#!perl -w
use strict;
use warnings;

use Win32::GUI();

my $mw;

$mw = Win32::GUI::Window->new(
     -onKeyDown => sub { undef $mw; return -1; },
);

$mw->Show();
Win32::GUI::Dialog();
__END__


>>> The point is that in WindowsXP it works fine but in Widows 98 SP2 it 
>>> does not.
>>> Windows' error screen points to USER32.DLL error.

I concur that the problem only manifests itself on Win98, but that's 
just lucky.  With various variations of the script I can get the error 
to appear in either User32.dll or Perl58.dll.

Here's one way around the problem - I think this is pretty close to the 
behaviour of your current script (except for behaviour on clicking the 
'close' button on the windows, which is somewhat unusual here, but I 
didn't know what you were expecting:

#!perl -w
use strict;
use warnings;

use Win32::GUI qw(VK_LEFT VK_RIGHT VK_RETURN);

my @Window;

makewindow();

$Window[0]->AddLabel(
     -pos  => [4,20],
     -size => [150,150],
     -text => "HELP:\n\n".
              " Right=add window\n".
              " Left=close (only top) window\n".
              " Enter=switch windows",
);

while(@Window) {
     Win32::GUI::Dialog();
     pop @Window;
}

exit(1);

sub makewindow {
     return if @Window > 4;

     push @Window, Win32::GUI::Window->new(
         -title    => @Window ? "Item: " . @Window : "Main Window",
         -pos     => [10+(@Window*202), 20],
         -size    => [200, 200],
         -onKeyDown   => \&keydown,
     );

     $Window[-1]->Show();

     return;
}

sub keydown {
     my ( $self, undef, $key ) = @_;

     if($key == VK_RIGHT) {
         makewindow();
     }
     elsif($key == VK_LEFT) {
         return -1;
     }
     elsif($key == VK_RETURN) {
         for my $index (0 .. $#Window) {
             if($self == $Window[$index]) {
                 $Window[++$index % @Window]->SetFocus();
             }
         }
     }

     return 0;
}
__END__

Regards,
Rob.