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

Re: [win32gui] Re: [perl-win32-gui-hackers] Missing SW_* constants

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

My 2 cents.

>>SW_* constants are not defined in GUI_constants.cpp (nor exported in 
>>GUI.pm).  In general there are many constants missing.

Constant handling is, and will be a pain to get right. Personally, I don't 
like the way Win32::GUI exports all it's constants by default - it's a huge 
waste of memory. I create separate packages for each window, and I used to 
have "use Win32::GUI" at the top of each package to get access to the 
constants. From memory, this added around 100K per package where Win32::GUI 
was used. When using constants I now use the full name, i.e., 
Win32::GUI::WS_CLIPCHILDREN.

Using autoload to bring in the constants dynamically, is an alternative 
solution but all the constant strings will have to be in the dll - and if 
we're talking about adding *all* the constants, the dll could become quite 
large...

I'm not sure what the best solution is. Personally, I would prefer if no 
more constants where exported as a default (unless they are commonly used), 
but adding them to GUI_constants.cpp is fine by me.

I also like the idea of generating GUI_constants.cpp automatically from 
(say) a flat file of constants - it would certainly make adding constants 
easier! Even if we end up having thousands of autoloaded constants, I don't 
think we would need to change the current algorithm (even though it's far 
from optimal) as autoloader only needs to do the look up once for each 
constant used.

Cheers,

jez.

Re: [win32gui] Re: [perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

>>There are two main reasons to use SetEvent:
>>
>>1) To add NEM events to windows/controls after they have been created - 
>>perhaps by a 3rd party tool (such as Loft) which isn't NEM aware.
>>2) To change the event handlers during runtime.
>>
>>In both cases, the expectation should be that the control is now running 
>>under NEM only - just as if the control was created with NEM event 
>>handlers in the first place.
>
>I don't follow this logical step.  If a tool that is not NEM aware 
>generates code, that presumably relies on OEM events being fired, and then 
>I add so code that uses SetEvent(), your proposal would stop any existing 
>OEM event handlers from being fired, even if for a different event.

My poor explanation. The tool wouldn't be responsible for generating the 
event handlers, just creating the window. For example, if you wanted to use 
Loft (or any GUI builder) and NEM, then you would use Loft to create the 
window and add the events later. Basically, I would have thought it would be 
valid to separate the step of creating a window, and associating events to 
it?

>>If these assumptions are correct - and I could be wrong - shouldn't the 
>>approach be to simply turn off the OEM for a control that uses SetEvent?
>
>I can't see that that is the right approach.  If the object is created to 
>use OEM, then SetEvent can have no idea whether there are actually OEM 
>event handlers that need to be called.  It does, however, know that after 
>it is called there is at least one NEM handler to call.  So all it can do 
>is turn on the NEM flag.  If you don't want OEM events fired, then ensure 
>they are turned off when the object is created by setting at least one NEM 
>handle, or by using the -eventmodel option.

Ok - if this is correct, then adding an event with SetEvent, shouldn't first 
call the NEM handler and still call the OEM handler for a single event. This 
is a bug. Returning 1 from the added NEM handler to stop this happening 
would be none standard.

>I guess I'm arguing that what's there is correct.  Comments?

I can understand your point of view - and to some extent I agree with it. 
The issue is how to control the event model of a object post it's creation - 
there is no way to do this at the moment.  I would have thought that using 
SetEvent would have explicitly changed event modes. As a compromise how 
about this:

* SetEvent logic stays the same
* The bug where 2 events are called for the same event when using SetEvent 
is fixed
* A new method is added, which when called forces the object into NEM mode

Cheers,

jez.

Re: [win32gui] RE: [perl-win32-gui-hackers] T_HANDLE in the typemap

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

>Jeremy White wrote:
>>Just done some performance testing with this type map:
>>
>>    if(SvROK($arg)) {
>>        SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0);
>>        if(out != NULL)
>>            $var = ($type) SvIV(*out);
>>        else
>>            $var = NULL;
>>    } else
>>        $var = ($type) SvIV($arg);
>>
>>Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap...
>>NewTypeMap: 29 wallclock secs (29.64 usr +  0.06 sys = 29.70 CPU) @ 
>>33666.63/s (
>>n=1000000)
>>OldTypeMap: 38 wallclock secs (38.22 usr +  0.02 sys = 38.23 CPU) @ 
>>26154.05/s (
>>n=1000000)
>>
>>Thoughts?
>
>I'm no typemap expert, but don't see anything wrong with that.  Indeed, 
>only doing the hv_fetch once seems like an obvious improvement.  If you can 
>hold onto the code until after the next release, then we can get it into 
>CVS for the following release?

No problem - there may be one issue. This code was compiled via Mingw, and 
as I'm declaring SV** out within a block of code, VC will complain. This may 
have been the reason that two hash reads were needed. I've a copy of VC now, 
so once the current build is out of the way, I'll do more testing.

Cheers,

jez.

Re: [win32gui] [perl-win32-gui-hackers] Textfield WantReturn Works in Window not in DialogBox?

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

Eric Hansen wrote:
> I am experiencing something strange in 1.02 release with textfields not
> Exhibiting the WANTRETURN behavior in DialogBoxes, but the do in Windows.
> The RichEdit control WANTRETURN works with DialogBoxes as shown in the
> Code below.   I have to change to a Window to allow the textfield to exhibit
> The WANTRETURN behavior.  The textfield code below was mostly borrowed
>  From the NotePad.pl   DEMO script.

[code snipped]

Eric,

When posting code, please post short, complete examples that we can run 
to see the problems that you are describing.

The ES_WANTRETURN style is only useful for multi-line edit controls that 
are in a Win32::GUI::DialogBox (or Win32::GUI::Window with the -dialogui 
option set).  What is does is stop the 'return' key firing the default 
action (usually the 'OK' button on the dialog), instead allowing the 
edit control to see the return key.

The following works as expected for me. Commenting out the -addstyle 
line stops the Textfield seeing the return key.

#!perl -w
use strict;
use warnings;

use Win32::GUI;

my $mw = Win32::GUI::DialogBox->new(
	-title => "Want Return",
	-pos => [100,100],
	-size => [400,300],
);

$mw->AddTextfield(
	-size => [200,200],
	-multiline => 1,
	-addstyle => ES_WANTRETURN,
);

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

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

Re: [win32gui] RE: [perl-win32-gui-hackers] T_HANDLE in the typemap

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

Jeremy White wrote:
> Just done some performance testing with this type map:
> 
>    if(SvROK($arg)) {
>        SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0);
>        if(out != NULL)
>            $var = ($type) SvIV(*out);
>        else
>            $var = NULL;
>    } else
>        $var = ($type) SvIV($arg);
> 
> Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap...
> NewTypeMap: 29 wallclock secs (29.64 usr +  0.06 sys = 29.70 CPU) @ 
> 33666.63/s (
> n=1000000)
> OldTypeMap: 38 wallclock secs (38.22 usr +  0.02 sys = 38.23 CPU) @ 
> 26154.05/s (
> n=1000000)
> 
> Thoughts?

I'm no typemap expert, but don't see anything wrong with that.  Indeed, 
only doing the hv_fetch once seems like an obvious improvement.  If you 
can hold onto the code until after the next release, then we can get it 
into CVS for the following release?

Rob.

Re: [win32gui] Re: [perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

Jeremy White wrote:
>> So in my last analysis I missed the 3rd way not to get the OEM event 
>> fired: returning 1 from the NEM handler.
>>
>> I personally don't see anything wrong with this logic, so long as you 
>> believe that returning 1 from an event handler means 'pass the event 
>> to the next handler', regardless of whether this is another event 
>> handler, or defwindowproc.  Although I note that DoHook doesn't 
>> implement such logic if you have multiple hooks for the same event.
> 
> I see your point. The problem is that most handlers don't explicitly 
> return anything, which means we would always return 1. This in turn 
> forces OEM logic to be run for any NEM event created by SetEvent.

But only if the object was created expecting to use OEM, so that the OEM 
flag is set, and as I have pointed out there are a number of way to 
ensure the OEM flag is not set at object creation time; if you do this, 
then OEM events are never looked for.

>> So, we come back to whether the SetEvent logic is right.  Currently 
>> SetEvent replaces any NEM coderef for the event passed, or creates one 
>> if there wasn't one there before, and ensures that the NEM flag is 
>> set.  As in my previous email, the only alternative I see is to get 
>> SetEvent to choke if the NEM flag is not set.
> 
> I would argue that the logic in SetEvent is wrong. My rational is as 
> follows:
> 
> There are two main reasons to use SetEvent:
> 
> 1) To add NEM events to windows/controls after they have been created - 
> perhaps by a 3rd party tool (such as Loft) which isn't NEM aware.
> 2) To change the event handlers during runtime.
> 
> In both cases, the expectation should be that the control is now running 
> under NEM only - just as if the control was created with NEM event 
> handlers in the first place.

I don't follow this logical step.  If a tool that is not NEM aware 
generates code, that presumably relies on OEM events being fired, and 
then I add so code that uses SetEvent(), your proposal would stop any 
existing OEM event handlers from being fired, even if for a different event.

> If these assumptions are correct - and I could be wrong - shouldn't the 
> approach be to simply turn off the OEM for a control that uses SetEvent?

I can't see that that is the right approach.  If the object is created 
to use OEM, then SetEvent can have no idea whether there are actually 
OEM event handlers that need to be called.  It does, however, know that 
after it is called there is at least one NEM handler to call.  So all it 
can do is turn on the NEM flag.  If you don't want OEM events fired, 
then ensure they are turned off when the object is created by setting at 
least one NEM handle, or by using the -eventmodel option.

I guess I'm arguing that what's there is correct.  Comments?

Regards,
Rob.

Re: [win32gui] Re: [perl-win32-gui-hackers] Missing SW_* constants

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

SW_* constants are not defined in GUI_constants.cpp (nor exported in 
GUI.pm).  In general there are many constants missing.

There are 2 issues to address here:
(1) How should we deal with constants?  I, personally, don't like the 
way that Win32::GUI by default exports all it's constants into the 
calling namespace, and so have made a conscious decision not to extend 
the list at the moment:  IMHO we should not export anything by default, 
and have suitable groups of constants that can be exported on request. 
I also feel that separating the constants into their own module 
(Win32::GUI::Constants?) would be a useful thing to do.

(2) Wherever possible we should be removing the need for the use of 
constants, so in your example of BrowseForFolder we should extend the 
options available to keep up with the enhancements made by microsoft. 
If you can raise a RFE, then I'll look at the for the next release.

Comments?

Rob.

Glenn Linderman wrote:
> On approximately 10/21/2005 9:57 PM, came the following characters from
> the keyboard of Glenn Linderman:
> 
>> Tried out the ShellExecute API tonight.  Works.  Can't use the SW_* 
>> constants that are documented, though, because they aren't defined.
>>
>> Should they be?  Looks like they would also be usable with the Show
>> API.
> 
> 
> Hmm.  BIF_* options are also not exposed (for BrowseForFolder).  On the
> other hand, a small selection of BIF_* constants are implicitly used
> based on user options to the GUI BrowseForFolder command.  However, GUI
> hasn't kept pace with BrowseForFolder enhancements (see
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/structures/browseinfo.asp) 
> 
> 
> So the question is, should additional options be added to GUI's
> BrowseForFolder to correspond with all the new options in the above
> link?  I'm particularly interested in the BIF_NEWDIALOGSTYLE.
> 
>> BIF_NEWDIALOGSTYLE
>> Version 5.0. Use the new user interface. Setting this flag provides
>> the user with a larger dialog box that can be resized. The dialog box
>> has several new capabilities including: drag-and-drop capability
>> within the dialog box, reordering, shortcut menus, new folders,
>> delete, and other shortcut menu commands. To use this flag, you must
>> call OleInitialize or CoInitialize before calling SHBrowseForFolder.
> 
> 
> Does GUI already call OleInitialize and/or CoInitialize?  I couldn't 
> find them, but they seem to be a prerequisite for this option.  I see 
> that these functions set the thread's "concurrency model", which I have 
> no idea what that is, or if it would adversely affect GUI.
> 

[perl-win32-gui-hackers] Textfield WantReturn Works in Window not in DialogBox?

[Eric H. <eh...@co...>]

I am experiencing something strange in 1.02 release with textfields not=20

Exhibiting the WANTRETURN behavior in DialogBoxes, but the do in
Windows.=20

The RichEdit control WANTRETURN works with DialogBoxes as shown in the

Code below.   I have to change to a Window to allow the textfield to
exhibit

The WANTRETURN behavior.  The textfield code below was mostly borrowed

From the NotePad.pl   DEMO script.

=20

#   $W2 =3D new Win32::GUI::DialogBox ($W1,

     $W2 =3D new Win32::GUI::Window ($W1,

    -title    =3D> "Second Window",

    -name     =3D> "Window2",

    -menu     =3D> $M,

    -left     =3D> 13,=20

    -top      =3D> 113,=20

    -width    =3D> 980,=20

    -height   =3D> 570,

    -style    =3D> ws_sysmenu,=20

);

=20

$TF_MyText =3D $W2->AddTextfield(

   -name          =3D> "TF_MyText",

   -pos           =3D> [100,128],

   -size          =3D> [300,73],

   -font          =3D> $EditFont,

   -multiline     =3D> 1,

   -hscroll       =3D> 1,

   -vscroll       =3D> 1,

   -autohscroll   =3D> 1,

   -autovscroll   =3D> 1,

   -keepselection =3D> 1,

   -background    =3D> [196,192,153],

);

=20

#   $RE_MyText =3D $W2->AddRichEdit(

#      -name       =3D> "RE_MyText",

#      -top        =3D> 205,

#     -left       =3D> 100,

#     -height     =3D> 96,

#     -width      =3D> 300,

#     -font      =3D> $EditFont,

#     -style      =3D> WS_VISIBLE | WS_VSCROLL | ES_MULTILINE |
ES_WANTRETURN,

#    );=20

#   $RE_Mytext->SetBkgndColor([196,192,153]);

=20

=20

=20

Eric Hansen

=20

Re: [perl-win32-gui-hackers] Crash with Combobox GetLBText

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

>>I'll let you know.
>
>Well, that fix appears to be the likeliest of the fixes that cured my 
>client's problem.  She is delighted.  And therefore, so am I.  And this 
>confirms that the problem shows up more on XP than on Windows 2000, because 
>I could never reproduce it on Windows 2000, but she could always produce it 
>readily on XP, within an hour or so.

Good - touch wood, I've had no issue either.

Now we just need to sort out the strange issues that sometime occur on 
exit:)

Cheers,

jez.

RE: [perl-win32-gui-hackers] T_HANDLE in the typemap

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

Just done some performance testing with this type map:

    if(SvROK($arg)) {
        SV** out=hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0);
        if(out != NULL)
            $var = ($type) SvIV(*out);
        else
            $var = NULL;
    } else
        $var = ($type) SvIV($arg);

Benchmark: timing 1000000 iterations of NewTypeMap, OldTypeMap...
NewTypeMap: 29 wallclock secs (29.64 usr +  0.06 sys = 29.70 CPU) @ 
33666.63/s (
n=1000000)
OldTypeMap: 38 wallclock secs (38.22 usr +  0.02 sys = 38.23 CPU) @ 
26154.05/s (
n=1000000)

Thoughts?

Cheers,

jez.

[perl-win32-gui-hackers] T_HANDLE in the typemap

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

Hi,

The typemap for T_HANDLE is as follows:

    if(SvROK($arg)) {
        if(hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 0) != NULL)
            $var = ($type) SvIV(*(hv_fetch((HV*)SvRV($arg), \"-handle\", 7, 
0)));
        else
            $var = NULL;
    } else
        $var = ($type) SvIV($arg);

which becomes:

    if(SvROK(ST(0))) {
        if(hv_fetch((HV*)SvRV(ST(0)), "-handle", 7, 0) != NULL)
            handle = (HWND) SvIV(*(hv_fetch((HV*)SvRV(ST(0)), "-handle", 7, 
0)));
        else
            handle = NULL;
    } else
        handle = (HWND) SvIV(ST(0));

in the code. If I am understanding this correctly we are doing 2 hash reads 
where we really only need to do one. As this typemap is used in nearly every 
method call we are doing lots of hash reads needlessly.

Thoughts?

Cheers,

jez.

Re: [perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

>So in my last analysis I missed the 3rd way not to get the OEM event fired: 
>returning 1 from the NEM handler.
>
>I personally don't see anything wrong with this logic, so long as you 
>believe that returning 1 from an event handler means 'pass the event to the 
>next handler', regardless of whether this is another event handler, or 
>defwindowproc.  Although I note that DoHook doesn't implement such logic if 
>you have multiple hooks for the same event.

I see your point. The problem is that most handlers don't explicitly return 
anything, which means we would always return 1. This in turn forces OEM 
logic to be run for any NEM event created by SetEvent.

>So, we come back to whether the SetEvent logic is right.  Currently 
>SetEvent replaces any NEM coderef for the event passed, or creates one if 
>there wasn't one there before, and ensures that the NEM flag is set.  As in 
>my previous email, the only alternative I see is to get SetEvent to choke 
>if the NEM flag is not set.

>I take back my position on not wanting to change this: having looked at my 
>code I use hooks rather than SetEvent, in order not to interfer with what 
>the user of my sub-classes intends.  I am, thus, indifferent on making such 
>a change, although I might argue that if you only want NEM, then you need 
>to indicate that when you create the object.  Do you have an alternative on 
>what you think would be correct behaviour?

I would argue that the logic in SetEvent is wrong. My rational is as 
follows:

There are two main reasons to use SetEvent:

1) To add NEM events to windows/controls after they have been created - 
perhaps by a 3rd party tool (such as Loft) which isn't NEM aware.
2) To change the event handlers during runtime.

In both cases, the expectation should be that the control is now running 
under NEM only - just as if the control was created with NEM event handlers 
in the first place.

If these assumptions are correct - and I could be wrong - shouldn't the 
approach be to simply turn off the OEM for a control that uses SetEvent?

Instead of (in SetEvent):

    perlud->hvEvents = perlcs.hvEvents;
    perlud->dwEventMask = perlcs.dwEventMask;
    SwitchBit(perlud->dwPlStyle, PERLWIN32GUI_NEM, (perlud->dwEventMask != 
0));
    XSRETURN_YES;

we have:

    perlud->hvEvents = perlcs.hvEvents;
    perlud->dwEventMask = perlcs.dwEventMask;
    SwitchBit(perlud->dwPlStyle, PERLWIN32GUI_NEM, (perlud->dwEventMask != 
0));
    SwitchBit(perlud->dwPlStyle, PERLWIN32GUI_OEM, 0);
    XSRETURN_YES;

The control would now operate fully under NEM.

Thoughts?

Cheers,

jez.

Re: [perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

Jeremy White wrote:
>> Question: is this a bug?  The only alternate behaviour I can come up 
>> with is that SetEvent(), rather than setting the NEM flag, should 
>> check it and bail out if it is not set (with a warning?).  [The 
>> current behaviour is useful if you are sub-classing a control, and do 
>> not know which method a user of the control will want to use.]
> 
> Surely running both NEM and OEM code for the same event is a bug? In 
> other words, a successful NEM call still causes the OEM logic to be run. 
> If you happen to have an sub that matches, then you get two events being 
> processed for a single event. See the code below for a better explanation:)

Well, you could certainly argue that it is a bug, but I don't really 
know what the thinking was when this was originally written.  There's 
certainly an option -eventmodel => 'both',  which explicitly allows this 
(i.e. sets both the OEM and NEM flag).

As I see the logic in DoEvents (psudeo-code):

PerlResult = 1;
// NEM event
if((perlud->dwPlStyle & PERLWIN32GUI_NEM) && (perlud->dwEventMask & 
iEventId)) {
     PerlResult = 0;
     PerlResult = NEM_CALLBACK;
	.....
}

// OEM Event
if (PerlResult == 1 && (perlud->dwPlStyle & PERLWIN32GUI_OEM) && 
perlud->szWindowName != NULL) {
     PerlResult = 0;
     if there is a function called main::perlud->szWindowName_EventName {
         PerlResult = OEM_CALLBACK;
	......
    }
}

This says do the NEM event if the NEM flag is set and there's a coderef 
set for the event.  Then do the OEM Event if:
- Either there was no NEM event, or the NEM event returned 1
- And the OEM flag is set
- And the window has a name
- And the correctly name callback function exists

So in my last analysis I missed the 3rd way not to get the OEM event 
fired: returning 1 from the NEM handler.

I personally don't see anything wrong with this logic, so long as you 
believe that returning 1 from an event handler means 'pass the event to 
the next handler', regardless of whether this is another event handler, 
or defwindowproc.  Although I note that DoHook doesn't implement such 
logic if you have multiple hooks for the same event.

So, we come back to whether the SetEvent logic is right.  Currently 
SetEvent replaces any NEM coderef for the event passed, or creates one 
if there wasn't one there before, and ensures that the NEM flag is set. 
  As in my previous email, the only alternative I see is to get SetEvent 
to choke if the NEM flag is not set.

I take back my position on not wanting to change this: having looked at 
my code I use hooks rather than SetEvent, in order not to interfer with 
what the user of my sub-classes intends.  I am, thus, indifferent on 
making such a change, although I might argue that if you only want NEM, 
then you need to indicate that when you create the object.  Do you have 
an alternative on what you think would be correct behaviour?

Regards,
Rob.

Re: [perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

>Question: is this a bug?  The only alternate behaviour I can come up with 
>is that SetEvent(), rather than setting the NEM flag, should check it and 
>bail out if it is not set (with a warning?).  [The current behaviour is 
>useful if you are sub-classing a control, and do not know which method a 
>user of the control will want to use.]

Surely running both NEM and OEM code for the same event is a bug? In other 
words, a successful NEM call still causes the OEM logic to be run. If you 
happen to have an sub that matches, then you get two events being processed 
for a single event. See the code below for a better explanation:)

I've just tried to follow the logic in DoEvent and the if statement that 
checks to see if we need to run OEM seems suspect (well, in the context of a 
NEM/SetEvent)?

$|=1;
use strict;
use Win32::GUI;

my $W = new Win32::GUI::Window(
    -name => "TestWindow",
    -pos  => [  0,   0],
    -size => [210, 200],
    -text => "TestWindow",
);

$W->AddButton (
    -name    => "Start",
    -pos     => [65,5],
    -text    => "&Start",
    -tabstop => 1,
    #-onClick => sub {print 'clicked'},
);

#add the events to the button

$W->Start->SetEvent('Click',sub {print 'clicked'});

$W->Show;

Win32::GUI::Dialog();

sub Start_Click {
  print 'start click';
}

Re: [perl-win32-gui-hackers] Crash with Combobox GetLBText

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

Jeremy White wrote:
> 
> If we spend time on reworking some of the internals for Unicode is it 
> worth us considering the implications of 64bit further down the road?

I'd be very interested in starting to try to understand what 64bit 
support would entail.  I'm starting to put together a list of things 
that don't work well with the current code-base, so that I can start to 
evaluate which bits of it might need significant re-work.  Any pointer 
to what implications 64bit might have would be appreciated.

Regards,
Rob.

Re: [perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

Jeremy White wrote:
>> I haven't tried this yet, but it seems wrong.  Can you raise a bug 
>> report and I'll dig further into this one.
> 
> http://sourceforge.net/tracker/?func=detail&atid=116572&aid=1333060&group_id=16572 
> 
> Ok - it seems this is only an issue when SetEvent is used (see example 
> below, also on tracker).

Ah.  I'd expect this.  When you create the control, as you don't have 
any NEM handlers set Win32::GUI chooses to use OEM.  When you use 
$control->SetEvent() it sets the NEM flag, so you end up with both 
happening.

You can work round this by:
(1) using -eventmodel => 'byref' in the constructor.  This explicitly 
forces NEM only.
(2) by setting any -onEvent => $someref option in the constructor. 
Again this will force NEM only.  (e.g. for your example -onClick => sub 
   { return; } would be suitable)

Question: is this a bug?  The only alternate behaviour I can come up 
with is that SetEvent(), rather than setting the NEM flag, should check 
it and bail out if it is not set (with a warning?).  [The current 
behaviour is useful if you are sub-classing a control, and do not know 
which method a user of the control will want to use.]

My vote is to leave it as is.

Regards,
Rob.

Re: [win32gui] [perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

>I haven't tried this yet, but it seems wrong.  Can you raise a bug report 
>and I'll dig further into this one.

http://sourceforge.net/tracker/?func=detail&atid=116572&aid=1333060&group_id=16572

Ok - it seems this is only an issue when SetEvent is used (see example 
below, also on tracker).

What seems to happen is that the NEM event is called, and then it looks for 
an OEM event - if found that is ran too.

Cheers,

jez.
---------------------------------------------



$|=1;
use strict;
use Win32::GUI;

my $W = new Win32::GUI::Window(
    -name => "TestWindow",
    -pos  => [  0,   0],
    -size => [210, 200],
    -text => "TestWindow",
);

$W->AddButton (
    -name    => "Start",
    -pos     => [65,5],
    -text    => "&Start",
    -tabstop => 1,
    #-onClick => sub {print 'clicked'},
);

#add the events to the button

$W->Start->SetEvent('Click',sub {print 'clicked'});

$W->Show;

Win32::GUI::Dialog();

Re: [win32gui] RE: [perl-win32-gui-hackers] Crash in CommonMsgLoop

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

>If you have some code that exhibits this, then I'd be interested to try to 
>reproduce it.  I though I could explain it, but then couldn't get an 
>example together that validated my explanation.

Not really - as when you reduce the size of the application, the issue 
disappears. I'll keep an eye on it and as soon as I have something solid 
I'll raise a bug.

Cheers,

jez.

Re: [perl-win32-gui-hackers] Crash with Combobox GetLBText

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

>This would lead to a more complex macro/function, but would, I think be 
>worth it.

[snip]

It would be a more complicated macro/function - but I agree with you, it 
would be worth it.

>This works nicely for the ANSI versions of the call, which return th ANSI 
>encoded string of bytes that is suitable for directly inserting into the 
>PV, but this doesn't address the Unicode issue at all, where the string 
>copied by CB_GETLBTEXT would have to be converted from UCS-2 to utf-8 and 
>then copied into the SV, setting the SVf_utf8 flag appropriately.

If we spend time on reworking some of the internals for Unicode is it worth 
us considering the implications of 64bit further down the road?

Cheers,

jez.

Re: [win32gui] [perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

Jeremy White wrote:
> I would have through that if a control was using NEM events, the OEM 
> logic wouldn't be called for that control.

That certainly should be the case.  Unless you use the -eventmodel => 
'both' option on the control, only one of PERLWIN32GUI_OEM and 
PERLWIN32GUI_NEN flags should be set for the control in perlud->dwPlstyle.

> For example, a button has a NEM click handler, I wouldn't expect DoEvent 
> to look for OEM events such as MouseMove for the same button - but it 
> does. If this is correct, it would mean that to save doing a perl_get_cv 
> call (which is really inefficient) you would have to define all possible 
> events for all controls?
> 
> Add this line:
> 
>   printf("EventName %s \n",EventName);
> 
> After:
> 
>        // OEM name event
>        char EventName[MAX_EVENT_NAME];
>        strcpy(EventName, "main::");
>        strcat(EventName, perlud->szWindowName);
>        strcat(EventName, "_");
>        strcat(EventName, Name);
> 
> To see the amount of needless calls made...

I haven't tried this yet, but it seems wrong.  Can you raise a bug 
report and I'll dig further into this one.

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

Re: [win32gui] RE: [perl-win32-gui-hackers] Crash in CommonMsgLoop

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

Jeremy White wrote:
> Ok - think I've got it - just not sure what the fix should be - or even 
> if a fix is needed. In my app, I catch the terminate event and ask the 
> user if they are sure they wish to exit. If they say yes, I perform 
> logic to save various settings. Once the settings have been saved I 
> return -1, which should exit. During this exit phase (for some reason) 
> various WM_NCHITTEST message are sent, and I assume that the window has 
> already been destroyed(? - or perhaps some kind of timing issue, which 
> explains why adding the print statements and Perl 5.6 don't cause the 
> crash) - the crash happens when the function CallWindowProc is called. 
> The 'fix' in my case is to hide the main window as soon as the user 
> clicks on the yes button...

If you have some code that exhibits this, then I'd be interested to try 
to reproduce it.  I though I could explain it, but then couldn't get an 
example together that validated my explanation.

Rob.

Re: [perl-win32-gui-hackers] Crash with Combobox GetLBText

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

Jeremy White wrote:
>> Seems like that should suffice, assuming that MSDN's definition of 
>> "character" is a 32-bit UCS-2 character.  I have no clue if MS 
>> supports UCS-2 characters that use multiple 32-bit numbers to 
>> represent a single character, but I believe such are legal.  And if 
>> they do support them, I don't know if they call them one character or 
>> two, or if they are even consistent about their counts, or their 
>> definition of "character" ("That depends on what you mean by 'is'.")
> 
> That's a good point - more research would be needed. At least with one 
> function doing all the string memory allocation we've only got one place 
> to change.

I haven't really checked this out fully, but looked into some of the 
quite recently (I'm still thinking in the background about what we would 
need to do to get a Unicode version of Win32::GUI).

The return value is the number of TCHARs required, where a TCHAR is one 
byte (char) or 2 bytes (w_char?) depending on the setting of the 
_UNICODE pre-processor symbol at compile time, so the right way to do 
this is:
safemalloc((num_bytes_required + 1) * sizeof(TCHAR));

I don't believe that we need to worry about the 4-byte representations 
(surrogate pairs), as these are accounted for in the return value.

I think, that there's a better implementation though; what we seem to 
currenlty have is:
(1) safealloc some bytes
(2) get SendMessage to copy the text into those byte
(3) return a pointer (which is then converted by xsubpp (via typemap) 
into code that creates a mortalised PV, which in turn must do a malloc 
and copy)
(4) free the bytes we safealloc'd

It would save a malloc, copy and free if we created the mortalised PV at 
the right size ourselves, passed the string pointer to SendMessage() and 
returned the PV.

This would lead to a more complex macro/function, but would, I think be 
worth it.

I'm not sure I got all this right, but I think you'll get the idea 
(there may be a better way to create the SV and grow it than I've shown 
here):

void
GetLBText(handle,index)
     HWND handle
     WPARAM index
PREINIT:
     STRLEN cbString;
     SV * text;
CODE:
     cbString = SendMessage(handle, CB_GETLBTEXTLEN, index, 0);
     if(cbString != LB_ERR) {
	text = newSVpvn((char *)NULL, 0);
	
	if(SendMessage(handle, CB_GETLBTEXT,
                        index,
		       (LPARAM) SvGROW(text, cdString+1) ) != LB_ERR) {
	    PUSHs(text);
             XSRETURN(1);
         } else {
             XSRETURN_UNDEF;
         }
     } else {
         XSRETURN_UNDEF;
     }

This works nicely for the ANSI versions of the call, which return th 
ANSI encoded string of bytes that is suitable for directly inserting 
into the PV, but this doesn't address the Unicode issue at all, where 
the string copied by CB_GETLBTEXT would have to be converted from UCS-2 
to utf-8 and then copied into the SV, setting the SVf_utf8 flag 
appropriately.

Regards,
Rob.

Re: [perl-win32-gui-hackers] Crash with Combobox GetLBText

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

>Seems like that should suffice, assuming that MSDN's definition of 
>"character" is a 32-bit UCS-2 character.  I have no clue if MS supports 
>UCS-2 characters that use multiple 32-bit numbers to represent a single 
>character, but I believe such are legal.  And if they do support them, I 
>don't know if they call them one character or two, or if they are even 
>consistent about their counts, or their definition of "character" ("That 
>depends on what you mean by 'is'.")

That's a good point - more research would be needed. At least with one 
function doing all the string memory allocation we've only got one place to 
change.

Cheers,

Jez.

RE: [perl-win32-gui-hackers] Combobox_onEvent crash

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

Hi,

>perl.exe caused an Access Violation at location 7c910f29 in module 
>ntdll.dll Reading from location 00000000.

Apologies this issue was my error. My application was performing an buffer 
overflow which ended up causing this error.

Cheers,

jez.

[perl-win32-gui-hackers] GUI_Events.cpp/DoEvent correct behaviour?

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

While tracking various crashes down I found myself in the DoEvent function 
in GUI_Events.cpp, now I don't think there is a issue here - but I did 
notice something surprising.

I would have through that if a control was using NEM events, the OEM logic 
wouldn't be called for that control.

For example, a button has a NEM click handler, I wouldn't expect DoEvent to 
look for OEM events such as MouseMove for the same button - but it does. If 
this is correct, it would mean that to save doing a perl_get_cv call (which 
is really inefficient) you would have to define all possible events for all 
controls?

Add this line:

   printf("EventName %s \n",EventName);

After:

        // OEM name event
        char EventName[MAX_EVENT_NAME];
        strcpy(EventName, "main::");
        strcat(EventName, perlud->szWindowName);
        strcat(EventName, "_");
        strcat(EventName, Name);

To see the amount of needless calls made...

Cheers,

jez.