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

Re: [perl-win32-gui-hackers] Constants and hashing [Was: Win32::GUI::Dialog() failure]

[Arthur I S. <Art...@ra...>]

                                                                           
             "Jeremy White"                                                
             <jez_white@hotmai                                             
             l.com>                                                     To 
                                       pe...@Ne...,                    
             12/19/2005 09:59          Art...@ra...       
             AM                                                         cc 
                                       per...@li...urce 
                                       forge.net,                          
                                       rm...@po...          
                                                                   Subject 
                                       Re: [perl-win32-gui-hackers]        
                                       Constants and hashing [Was:         
                                       Win32::GUI::Dialog() failure]       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           








>>our original discussions until now, I think it may be more worthwhile to
>>   figure out how to make _all_ 18000 constants available to Win32::GUI
>>programs, without paying a huge price in memory.  Those constants that
>>actually get used get cached in the stash anyway...
>>
>>
>>    If speed isn't the issue then a binary search has  ...
>
>It is difficult or impossible to do a binary search of compressed data...
>so if space is the overriding issue, compression is the overriding answer,

>and linear searching becomes the only practical search technique.  To
avoid
>linear searching of the complete set, a

My 2 cents:)

We have 2 issues:

1) Performance.

2) Memory requirements.

...

Now, for some cases, 360k is a drop in the ocean - my app runs at 50 meg
before it's done anything, with the exe coming in at 6 megs - but for a 20
line utility script, having to load the dll holding the constants could be
over-kill...

  And here I think I totally agree. We've got memory, why do we need to
  compress? It will certainly take time to uncompress, and you you're
  counting memory, then you should count the code in the compression
  algorithms. And then there is maintenance. And then there is time
  (to uncompress). And then there are complexity issues.

Glenn Linderman recently posted a question on just how to acquire the
Windows
constants.

   Couldn't we use items from the Unix toolset (in Cygwin) to extract
   most or all of the constants? Maybe (this is an ignorant answer
   mind you) like:

     egrep '# *define' *.h | egrep 'WM_|XX_' | sed 's/# *define //'

   and so on?

art

Re: [perl-win32-gui-hackers] Win32::GUI::Dialog() failure

[Arthur I S. <Art...@ra...>]

OK, I AM A NOVICE. That means "Idiot's Guide to ..." are just too
sophisticated.

I have a problem ("What's your problem.").

I can't seem to get windows events to call my event handlers (original
topic). I have modularized my code so that:

   a.pl   control logic  module
   a/b.pm GUI handler

As part of previous suggestions and new thoughts, I have:
1.  Made the window handle, $window, 'our $window' in a/b.pm
2.  Made the handle 'our $window' in a.pl.
3.  Made a local copy of all event handlers:
    <name>_<event>{ a::b:<name>_<event>;} # so that all calls
    are in the main module and are redirected to b.pm.
4.  Used an exporter (from memory so it may not be exact)
    use var qw( <name>_<event>* $window etc);
    use @ISA ('Exporter');
    use @Exporter qw(  <name>_<event>* $window etc );
5.  I have not used direct module importing (just thought
    of it), as in:
    use b(<name>_<event>* $window etc);
6.  Thought fondly of unassisted ends to my mortal coil.

And in most cases I get the $window window but no interaction
to any event. Sort of 'click and nothing'.

I think I've followed all the suggestions. I've tried to
put use scoping correctly, and I've found out that the
only thing that the exporter seems to export are subroutine
names. It's clear that I don't know what I'm doing. Any
more suggestions?

Re: [perl-win32-gui-hackers] Constants and hashing [Was: Win32::GUI::Dialog() failure]

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

>>our original discussions until now, I think it may be more worthwhile to
>>   figure out how to make _all_ 18000 constants available to Win32::GUI
>>programs, without paying a huge price in memory.  Those constants that
>>actually get used get cached in the stash anyway...
>>
>>
>>    If speed isn't the issue then a binary search has  ...
>
>It is difficult or impossible to do a binary search of compressed data... 
>so if space is the overriding issue, compression is the overriding answer, 
>and linear searching becomes the only practical search technique.  To avoid 
>linear searching of the complete set, a

My 2 cents:)

We have 2 issues:

1) Performance.

2) Memory requirements.

Personally, the performance issue is a none event. I did some timings a 
while back, and the constant lookup logic could be several orders of 
magnitude slower than the current solution and it wouldn't make any 
difference to how a Win32-GUI application would perform. This is because the 
constant code isn't called often enough to make any difference.

Personally, the memory issue is a main problem. I like the idea of having 
all 18000 constants available to  Win32::GUI (if all the constants are 
available, then the module would also be useful for none Win32-GUI modules), 
but at what cost? 50k? 100k? 200k? Think about it for a moment - what would 
you sacrifice? Perhaps it's worth setting some target to aim for?

The binary search is a good idea - and I can think of a ways to make it work 
with compressed data - but we're still talking quite a lot of memory. If 
each constant (including the text and value) is:

average 10 bytes each = total 180,000 bytes
average 20 bytes each = total 360,000 bytes
...

Now, for some cases, 360k is a drop in the ocean - my app runs at 50 meg 
before it's done anything, with the exe coming in at 6 megs - but for a 20 
line utility script, having to load the dll holding the constants could be 
over-kill...

Perhaps less common constant text/values could be stored as a file, with a 
fast binary search lookup?

Cheers,

jez.

Re: [perl-win32-gui-hackers] Constants and hashing [Was: Win32::GUI::Dialog() failure]

[Arthur I S. <Art...@ra...>]

                                                                           
             Glenn Linderman                                               
             <pe...@Ne...>                                             
                                                                        To 
             12/17/2005 03:51          rm...@po...          
             PM                                                         cc 
                                       Jeremy White                        
                                       <jez...@ho...>,            
                                       Art...@ra...,      
                                       per...@li...urce 
                                       forge.net                           
                                                                   Subject 
                                       Re: [perl-win32-gui-hackers]        
                                       Constants and hashing [Was:         
                                       Win32::GUI::Dialog() failure]       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           











On approximately 12/17/2005 4:39 AM, came the following characters from
the keyboard of Robert May:

> So, it was my plan to do a later implementation moving the lookup back
> into XS, using a 'minimal perfect hash' and an efficient C array.  The
> storage for this approach would be something like 8 bytes per constant
> identifier (string pointer + long value) plus the constant identifier
> string length (for the constant lookup array), plus the storage for the
> polynomial values used by the hash function.

Agreed, speed probably isn't the issue, and mph may or may not be
necessary (it mostly benefits speed issues).  After some reflection from
our original discussions until now, I think it may be more worthwhile to
  figure out how to make _all_ 18000 constants available to Win32::GUI
programs, without paying a huge price in memory.  Those constants that
actually get used get cached in the stash anyway...


   If speed isn't the issue then a binary search has at most 15 probes
   to find any of the 18,000 entries in the table with a no time cost
   expansion for another 14,000 entries. As benchmarking showed some
   time back, the implemented 'hash' was better than a binary search
   for some small number of searches. I would expect that the binary
   search would be faster than a hash for some searches. Given a
   uniform distribution of searches, the expected number of probes
   is approximately 8.

   Again, if speed is not a criteria and a minor speed decrease is
   acceptable, then a binary search is a good way to proceed. The
   only overhead are the string pointers in the table of entries.

   If you want a tailored partitioned binary search then one data
   structure / partition is required, the binary search function
   code can be shared. This results in a decrease in the number
   of probes (since the table size for each partition is smaller
   than for the entire data structure), with added overhead to
   determine what partition to access. And on the added overhead,
   we esssentially trade time, i.e. probes, for code to determine
   what partition to use, and we add some small amount of additional
   complexity for multiple tables.

   Since the animal breeds, I would expect that there will be
   future additions and deletions of constants. Hence, a need
   to address the future.

   At the end, I'm not wealthy because I do a terrible job of
   predicting.

art

Re: Fwd: Re: [win32gui] [perl-win32-gui-hackers] Win32::GUI::Dialog() failure

[Arthur S. <asc...@ve...>]

On approximately 12/17/2005 6:46 AM, came the following characters from 
the keyboard of Arthur Schwarz:

> Robert;
"...  For example, my last email just suggested doing a form 
of linear searching, because it would allow space to be saved.... but 
this can be fully optimal in certain circumstances... what 
circumstances?  

   FWIW (I really hate these acronyms, only because I rarely
   know what they mean, so, for what it's worth) linear searching
   is 'optimal' in only a few cases, to wit:
   1. The locale of reference is small.
   2. It is possible to load all of the list into primary cache.
   3. Predictive loads load data not in primary cache into 
      secondary cache before use (and then into primary cache
      before use).
   4. Dynamic instruction code optimization does not intefere with
      the search by putting in latencies.

   In terms of just looking at code and operation, a binary search
   should be faster in most (but not all) cases. In particular, 
   conditions based on a small locale of reference are violated 
   for a binary search.

   See, for example, 
     Self-organizing Linear Search
     J.H. Hester, D. S. Hirschberg
     ACM Computing Surveys, V17N3

   for another look at linear searching.

> It does several things that have ne'er before seen
> the light of day. Assuming a keyword list of ASCII words (not strictly
> necessary):
> 1. Given a list of keywords, it selects the optimum set of columns to use
> to get a minimum height search tree.

I've never heard this idea codified before, but I did, in fact, attempt 
to manually approximate that a few times in the past when I was 
generating mph polynomials.  Computers might be fast enough now to make 
it practical to calculate this automatically.

  Calculation of an optimal parameter set from an arbitrarily large set
  does not take long on average (I suspect). Worst case performance can
  be really bad and depends on tree depth. If at most a single keyword
  is removed from the keyword list at every level then the worst 
  case is bounded by:

      Iterations = O((# keyword) * (maximum # parameters) * (# keywords))
      O         == big O (upper bound of computation)
      and depth == (maximum # parameters)

  The algorithm has nothing to do with MPH, it is merely useful as a
  prepass optimization step. Since the solution is deterministic
  (finiteness guaranteed) and not a branch-and-bound problem it doesn't
  suffer from some of the search issues.

> 2. Given the results of the prepass, it will generate a polynomial whose
> return value is an integer, 0 <= i <  |# keywords| for each input keyword.

I've heard this one discussed, of course without the results of the 
prepass.  But in the codes I've seen, it was never stated as a 
guaranteed achievement; the operational instructions said you could try 
for that, but if it didn't find one, then you might increase the size of 
the max integer, which would result in some gaps in the sequence of 
possible return values, which would "help" the polynomial generator find 
a solution.

   There are a number of polynomial and non-polynomial solutions given
   in the literature (that I've looked at). All of them that I have so
   far seen depend on a search technique of some sort. One such solution
   which is readily available is 'gperf' in Cygwin. My proposed solution
   does not depend on a search and is deterministic.

I'll be interested to see the Arthur Schwarz mph generator when it is 
published.  

  Me to :).

That doesn't mean that I necessarily think that it will be 
the right solution for Win32::GUI::Constant ... my thinking is quite the 
opposite at the moment.

  Not my decision. If used I am sure it will be analyzed for performance
  and used if it performs well.

Fwd: Re: [win32gui] [perl-win32-gui-hackers] Win32::GUI::Dialog() failure

[Arthur S. <asc...@ve...>]

Robert;

As always, THANKS. I'll check out your solution (probably) Monday.

Wrt your constants rework, did you run a timing study and comparison with
the 'old' method. Someone (one of the unbelievers I'm sure) said that I
should do it after I proposed that a binary search be used. Drat. I found
that in the first few searches the existing algorithm was faster.

As to the mph (Miles per Hour in the US and kph elsewhere), this is an
algorithm of my own invention (chest out and proudly displaying my medals).
It is written in C/C++. It does several things that have ne'er before seen
the light of day. Assuming a keyword list of ASCII words (not strictly
necessary):
1. Given a list of keywords, it selects the optimum set of columns to use
to get a minimum height search tree.
2. Given the results of the prepass, it will generate a polynomial whose
return value is an integer, 0 <= i <  |# keywords| for each input keyword.

Time studies need to be done to determine usefullness, rather than
feasibility.

I have searched the literature (in my spare time) and can't find any
algorithms or solutions for either 1. or 2. above. My own solution was
developed into a Master's project in 1990 but had one small flaw. The new
algorithm corrects the flaw and should yield a polynomial. Since the
problem is unsolved I would expect sceptics until I publish my solution (oh
yea of little faith). But I have faith - hopefully not to be dashed.

The literature search was in the Digital Library from the Association of
Computing Machinery (ACM), and yielded 200 out of 1,200 citations.

With respect to 'easily add constants to', why would I want to work myself
out of a non-paying job??? No way. Sorry, For each new constant added (or
removed) Steps 1 and 2 must be rerun. I can't do better than that.

All the work is done at home in my spare time. The (current) hangup is that
I have just finished rewriting my list processor (SLIP - Symmetric List
Processor circa 1960) and now am developing test cases to validate its
operation. Next is the prepass code and then the polynomial generator.

art



                                                                           
             Robert May                                                    
             <rmay@popeslane.c                                             
             lara.co.uk                                               To 
                                       Arthur I Schwarz                    
             12/16/2005 03:40          <Art...@ra...    
             PM                                                         cc 
                                       per...@li...urce 
                                       forge.net                           
             Please respond to                                     Subject 
             rm...@po...         Re: [win32gui]                      
                 ara.co.uk             [perl-win32-gui-hackers]            
                                       Win32::GUI::Dialog() failure        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Arthur I Schwarz wrote:
I'm have partitioned my program into modules:
>
  <name>::GUI
>
The program driver is in <name>:
>
  <name>.anonymous subroutine (the nameless thing at the end)
  &StartWindows   # &<name>::GUI::StartWindows
>
and <name>::GUI::StartWindows I do:
>
   $window->show();
   Win32::GUI::Dialog();
>
The window displays correctly.
All the pull down menus display correctly.
Selecting any item in a pull down menu has no effect (the event seems to
be
unhandled).
Selecting the big X in the window causes the window to close and control
to
return to the perl program.
>
The GUI did work with the same code before partitioning, all code in a
single .pl file.

My suspicion is that you are letting the variable that holds your menu
object go out of scope, but with no code posted it's hard to tell.  Try
using 'our $menu = ...' rather than 'my $menu = ...' when you create the
  menu object.   Letting things go out of scope is very easy to do when
you split code into modules.

On another note, I'm reworking my Minimal Perfect Hash function algorithm
(from college). It is a deterministic algorithm that returns a polynomial
hash function which yields an O(1) probe into a hash table. Any interest
in
converting all of the table lookups in the *.xs files? (PS: this solves
an
otherwise unsolved problem in discovering such a function.)

Is this a perl implementation of an mph polynomial generator?  I've
already re-worked the whole constants support (see the archive for this
list a couple of months back), and it currently uses a perl hash to hold
the constants and do the lookup, but given the potential number of
constants in the windows header files I was thinking of implementing a
mph solution (and have been playing with Taj Khattra's mph-1.2, which I
have ported to compile under MS VC++).  A perl implementation that
generates the polynomial values to stick in the C code would be a nice
way to solve the problem that I have been struggling with of how to make
  a distribution that others can easily add constants to.

Regards,
Rob.

[perl-win32-gui-hackers] Constants and hashing [Was: Win32::GUI::Dialog() failure]

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

Robert May wrote:
>> I've already re-worked the whole constants support (see the archive for 
>> this list a couple of months back), and it currently uses a perl hash 
>> to hold the constants and do the lookup, but given the potential 
>> number of constants in the windows header files I was thinking of 
>> implementing a mph solution (and have been playing with Taj Khattra's 
>> mph-1.2, which I have ported to compile under MS VC++).

Jeremy White wrote:
> Out of curiosity how much faster is a lookup using the mph-1.2 tool set 
> V the perl hash? How much smaller is the mph structure V the perl hash 
> structure?

I have not benchmarked this, but wouldn't expect much difference - 
although I would expect the mph lookup to be slightly faster as there 
will be less dereferencing through perl SV's to retrieve the actual 
value.  Speed isn't actually my primary concern, as the lookup only ever 
happens once per constant - either at compile time if you use the 
'-inline' pragma or during runtime when the constant is first accessed.

I don't intend to change the implementation that was distributed on this 
list for a first release (I do intend to reduce the number of constants 
included), but following up on some other ideas I started to look at how 
much memory was being used, and even with the 3000 or so constants 
currently defined the memory usage is not small (perl hashes are not 
very memory efficient).  There are something like 18000 constants 
defined in the header files included by Win32::GUI - now I'm sure that 
we don't want all of them, but thats going to make the hash huge.

So, it was my plan to do a later implementation moving the lookup back 
into XS, using a 'minimal perfect hash' and an efficient C array.  The 
storage for this approach would be something like 8 bytes per constant 
identifier (string pointer + long value) plus the constant identifier 
string length (for the constant lookup array), plus the storage for the 
polynomial values used by the hash function.


> In terms of distribution, couldn't we assume that anyone wanting to add 
> a constant would have (or need) the ability to build Win32-GUI from 
> source? In which case, couldn't the hash be built as part of the build 
> process?

Yes, it'd have to be, as the polynomial values change whenever a new 
constant is added.  I was only struggling with whether to distribute the 
mph source, and have mph.exe built during the build process, or, as we 
know this module is only for windows, whether to distribute mph.exe. 
It's not a big issue

Regards,
Rob.

[perl-win32-gui-hackers] Re: Win32::GUI::Dialog() failure

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

>> Arthur I Schwarz wrote:
>>
>>> I'm have partitioned my program into modules:

[snip]

>>> The window displays correctly.
>>> All the pull down menus display correctly.
>>> Selecting any item in a pull down menu has no effect (the event seems 
>>> to be
>>> unhandled).

Robert May wrote:
>> My suspicion is that you are letting the variable that holds your menu 
>> object go out of scope, but with no code posted it's hard to tell.  
>> Try using 'our $menu = ...' rather than 'my $menu = ...' when you 
>> create the  menu object.   Letting things go out of scope is very easy 
>> to do when you split code into modules.

Thinking further about it, this is actually unlikely to be the problem 
for a window menu.  I confused myself with an issue that I recently 
tracked down with one of my programs that involved popup menus, where I 
had a handler like this:

sub handler {
   ...
   my $menu = Win32::GUI::Menu->new(...)
   TrackPopupMenu($menu, ...);

   return;
}

In this code $menu is in scope when TrackPopupmenu is called, so the 
menu displays fine, but goes out of scope (destroying the menu) as soon 
as the handler returns, and BEFORE the message pump tries to dispatch 
the windows event that is raised.  As the menu item handlers are stored 
with the windows menu structure they don't exist when the message pump 
sees the event.

Regards,
Rob.

Re: [win32gui] [perl-win32-gui-hackers] Win32::GUI::Dialog() failure

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

>Arthur I Schwarz wrote:
>>I'm have partitioned my program into modules:
>>
>>   <name>::GUI
>>
>>The program driver is in <name>:
>>
>>   <name>.anonymous subroutine (the nameless thing at the end)
>>   &StartWindows   # &<name>::GUI::StartWindows
>>
>>and <name>::GUI::StartWindows I do:
>>
>>    $window->show();
>>    Win32::GUI::Dialog();
>>
>>The window displays correctly.
>>All the pull down menus display correctly.
>>Selecting any item in a pull down menu has no effect (the event seems to 
>>be
>>unhandled).
>>Selecting the big X in the window causes the window to close and control 
>>to
>>return to the perl program.
>>
>>The GUI did work with the same code before partitioning, all code in a
>>single .pl file.
>
>My suspicion is that you are letting the variable that holds your menu 
>object go out of scope, but with no code posted it's hard to tell.  Try 
>using 'our $menu = ...' rather than 'my $menu = ...' when you create the  
>menu object.   Letting things go out of scope is very easy to do when you 
>split code into modules.

I split my code in the same way you do, so I doubt that there is problem 
with Win32::GUI::Dialog();

Another alternative might be that if you are using OEM events Win32-GUI 
can't see your handlers, as they have do be defined in the main package. For 
example, you might have had:

sub Button_Click {};

now it would have to be

sub ::Button_Click {};

>Is this a perl implementation of an mph polynomial generator?  I've already 
>re-worked the whole constants support (see the archive for this list a 
>couple of months back), and it currently uses a perl hash to hold the 
>constants and do the lookup, but given the potential number of constants in 
>the windows header files I was thinking of implementing a mph solution (and 
>have been playing with Taj Khattra's mph-1.2, which I have ported to 
>compile under MS VC++).  A perl implementation that generates the 
>polynomial values to stick in the C code would be a nice way to solve the 
>problem that I have been struggling with of how to make  a distribution 
>that others can easily add constants to.

Out of curiosity how much faster is a lookup using the mph-1.2 tool set V 
the perl hash? How much smaller is the mph structure V the perl hash 
structure?

In terms of distribution, couldn't we assume that anyone wanting to add a 
constant would have (or need) the ability to build Win32-GUI from source? In 
which case, couldn't the hash be built as part of the build process?

Cheers,

jez.

Re: [win32gui] [perl-win32-gui-hackers] Win32::GUI::Dialog() failure

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

Arthur I Schwarz wrote:
> I'm have partitioned my program into modules:
> 
>   <name>::GUI
> 
> The program driver is in <name>:
> 
>   <name>.anonymous subroutine (the nameless thing at the end)
>   &StartWindows   # &<name>::GUI::StartWindows
> 
> and <name>::GUI::StartWindows I do:
> 
>    $window->show();
>    Win32::GUI::Dialog();
> 
> The window displays correctly.
> All the pull down menus display correctly.
> Selecting any item in a pull down menu has no effect (the event seems to be
> unhandled).
> Selecting the big X in the window causes the window to close and control to
> return to the perl program.
> 
> The GUI did work with the same code before partitioning, all code in a
> single .pl file.

My suspicion is that you are letting the variable that holds your menu 
object go out of scope, but with no code posted it's hard to tell.  Try 
using 'our $menu = ...' rather than 'my $menu = ...' when you create the 
  menu object.   Letting things go out of scope is very easy to do when 
you split code into modules.

> On another note, I'm reworking my Minimal Perfect Hash function algorithm
> (from college). It is a deterministic algorithm that returns a polynomial
> hash function which yields an O(1) probe into a hash table. Any interest in
> converting all of the table lookups in the *.xs files? (PS: this solves an
> otherwise unsolved problem in discovering such a function.)

Is this a perl implementation of an mph polynomial generator?  I've 
already re-worked the whole constants support (see the archive for this 
list a couple of months back), and it currently uses a perl hash to hold 
the constants and do the lookup, but given the potential number of 
constants in the windows header files I was thinking of implementing a 
mph solution (and have been playing with Taj Khattra's mph-1.2, which I 
have ported to compile under MS VC++).  A perl implementation that 
generates the polynomial values to stick in the C code would be a nice 
way to solve the problem that I have been struggling with of how to make 
  a distribution that others can easily add constants to.

Regards,
Rob.

[perl-win32-gui-hackers] Win32::GUI::Dialog() failure

[Arthur I S. <Art...@ra...>]

Win32::GUI v1.02

I'm have partitioned my program into modules:

  <name>::GUI

The program driver is in <name>:

  <name>.anonymous subroutine (the nameless thing at the end)
  &StartWindows   # &<name>::GUI::StartWindows

and <name>::GUI::StartWindows I do:

   $window->show();
   Win32::GUI::Dialog();

The window displays correctly.
All the pull down menus display correctly.
Selecting any item in a pull down menu has no effect (the event seems to be
unhandled).
Selecting the big X in the window causes the window to close and control to
return to the perl program.

The GUI did work with the same code before partitioning, all code in a
single .pl file. I have read the caution about trying to execute
Win32::GUI::Dialog() from within an object (don't do it). I don't have a
class established and I would think there's no object. I've looked at
GUI.pm and GUI.xs (the dialog call is in GUI.xs).

So, what can I do to fix the problem? The only thing that I can think of is
to put all the GUI subroutines into <name>.

On another note, I'm reworking my Minimal Perfect Hash function algorithm
(from college). It is a deterministic algorithm that returns a polynomial
hash function which yields an O(1) probe into a hash table. Any interest in
converting all of the table lookups in the *.xs files? (PS: this solves an
otherwise unsolved problem in discovering such a function.)

art

Re: [win32gui] [perl-win32-gui-hackers] [Fwd: RE: alarm() doesn't work on Windows 2003 and Windows Vista]

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

Glenn,

Do you have a pointer to the whole thread so that I can have a browse.

Thanks,
Rob.

Glenn Linderman wrote:
> for swap stack trickery sounds bad... and I doubt we are doing it in 
> Win32::GUI...  Thought I'd put it here for the record, if nothing else.
> 
> -------- Original Message --------
> To: ja...@Ac...
> Message-Id: <200...@ll...>
> Date: Fri, 09 Dec 2005 20:29:41 +0000
> From: Nick Ing-Simmons <ni...@in...>
> 
> Jan Dubois <ja...@Ac...> writes:
> 
>> On Fri, 09 Dec 2005, Nick Ing-Simmons wrote:
>>
>>> Jan Dubois <ja...@Ac...> writes:
>>> >Yes, both the original code, and the patch switching from NULL to 
>>> (HWND)-1
>>> >were from you.
>>>
>>> I have no memory of the (HWND)-1 change at all :-(
>>> Can you point me at the perforce change where I did it ?
>>
>>
>> http://public.activestate.com/cgi-bin/perlbrowse?patch=14160
> 
> 
> Hmm, well it was obviously me. I can only assume I had been reading MSDN
> help on PeekMessage() and saw the use mentioned.
> It does look like a speculative change.
> 
>>
>>> I assume that the change to (HWND)-1 was to avoid grabbing events
>>> destined for GUI. If that is really a problem then I suppose WM_TIMER
>>> events should be posted to a real (invisible?) window created for that
>>> purpose.
>>
>>
>> Yes, that would be a possibility, but I would want to avoid the 
>> additional
>> complexity if it is not needed.  I'll check it out if this would solve 
>> the
>> issue on Windows 2003. Maybe it is trivial to do this.
>>
>> I do sometimes worry about additional message pumps dispatching GUI 
>> messages
>> at "arbitrary" times during Perl execution, but I haven't found any real
>> issues yet.  I think a problem would happen if you execute a Perl 
>> callback
>> in response to a message, and while you are still in the callback, 
>> another
>> message triggers a different callback.  Couldn't the first callback mess
>> with the stack(s) of the second callback?
> 
> 
> They can and they do. Which is why Tk does some swap-stack trickery
> (thanks to Sarathy telling me how).
> 
>>
>> However, this happens all the time in GUI applications with modal
>> dialog boxes.  
> 
> 
> Quite, so GUI apps have to cope - what is less clear is what happens
> to perl code (or core) that does not know there is a GUI.
> 
>> Another area is COM synchronization, which also happens
>> through the message queue (using hidden top level windows for
>> non-GUI programs).  Every COM method call or property access will spin
>> the message pump and deliver GUI messages to windows too.
>>
>> Cheers,
>> -Jan
> 
> 
> 
> 
> 
> 
> 

[perl-win32-gui-hackers] Re: [win32gui] Re: Fixing Scintilla

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

Jeremy White wrote:
>> At first glance these errors look like C++ vs. C syntax problems.  I 
>> haven't looked at the scintilla code, but it would be my guess that 
>> the XS files is being compiled as C (this is the standard Makefile.PL 
>> behaviour) whereas Win32::GUI (for reasons that escape me) is built 
>> using a C++ compiler (see the override in Win32::GUI's Makefile.PL 
>> (sub xs_c) that builds .cpp files from the XS rather than .c files).
> 
> ARH! Yes, you are right. I've always wondered why win32-gui used a C++ 
> compiler, as there is no C++ code.
> 
>> I thin that (2) if preferable, and it is one of my longer-term goals 
>> to get Win32::GUI to use standard 'C' too.
> 
> I changed GUI.h (and GUI_MessageLoops.cpp) to be "C" safe.

Nice work on Scintilla - I haven't tried building it yet, but can 
confirm that Win32::GUI still builds and tests ok with these changes and 
your TYPEMAP changes.

Regards,
Rob.

[perl-win32-gui-hackers] Re: [win32gui] RE: Perl contexts [Was: Fixing Scintilla]

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

Jeremy White wrote:
>> [ I've added a note to myself to look for all the places that we use 
>> dTHX and to ensure that they are necessary - I think they are used 
>> when we get a win32 api callback such that we can't use the NOTXSPROC 
>> calling convention ]
> 
> 
> I'm still not 100% sure how the context works within Win32-GUI but there 
> might be a problem when Win32-GUI is used in a threaded app, where you 
> want different threads to deal with different windows (see 
> AttachThreadInput method in the docs).
> 
> As I understand things, we're storing the context in 
> PERLWIN32GUI_USERDATA via the macro PERLUD_DECLARE and we're fetching 
> the context via the macro PERLUD_FETCH. As we're fetching the context 
> everytime we're doing an event, we are *always* using the perl 
> interpreter that created the window, rather than the context that is 
> associated with the current running thread.
> 
> I'm not to sure what the solution could be, as I understand things you 
> can't pass sub refs around perl threads, which means that NEM would be 
> broken (i.e., thread A creates the window and the sub refs for the 
> events, but you need thread B to respond to events for the window 
> created by A). From very bitter experience, Perl 5.6 and most 5.8.x 
> (5.8.7 seems ok) threading at the deep perl level is broken.

So long as you don't use AttachThreadInput, then I think we're OK, as 
messages get posted to the thread that creates the window, and the 
message loops only pull messages from that thread's message loop. 
You're correct that as soon as you call AttachThreadInput the whole 
thing is broken.

That said, Win32::GUI needs some significant work to be thread-safe (and 
even more work to be thread-friendly).

I've got some ideas of the direction to take this, and think that as a 
first step simply adding a CLONE_SKIP method to each class, that 
prevents the objects getting cloned when a new thread is started is the 
easiest direction.  This would certainly cater for (what I can see is a 
very common case of) wanting to start a thread to do some work, whilst 
keeping all the GUI code in a separate thread.   At least we'd be able 
to use threads (even if in a somewhat limited way) without crashing 
every time we do a thread->join().

I'll tuck your comments away for further though when I get around to 
considering threads in more detail.

Regards,
Rob.

[perl-win32-gui-hackers] RE: [SPAM-MAIL ] - Perl-Win32-GUI-Hackers digest, Vol 1 #239 - 2 msgs - Found word(s) remove list list error in the Text body

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

Que es esto Scintilla?

-----Original Message-----
From: per...@li...
[mailto:per...@li...] On Behalf Of
per...@li...
Sent: Sunday, December 04, 2005 10:34 PM
To: per...@li...
Subject: [SPAM-MAIL ] - Perl-Win32-GUI-Hackers digest, Vol 1 #239 - 2
msgs - Found word(s) remove list list error in the Text body

Send Perl-Win32-GUI-Hackers mailing list submissions to
	per...@li...

To subscribe or unsubscribe via the World Wide Web, visit
=09
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
or, via email, send a message with subject or body 'help' to
	per...@li...

You can reach the person managing the list at
	per...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Perl-Win32-GUI-Hackers digest..."


Today's Topics:

   1. Re: Fixing Scintilla (Robert May)
   2. Perl contexts [Was: Fixing Scintilla] (Robert May)

--__--__--

Message: 1
Date: Sun, 04 Dec 2005 19:16:34 +0000
From: Robert May <rm...@po...>
Reply-To: rm...@po...
Organization: At Home
To: Jeremy White <jez...@ho...>
CC: per...@li...
Subject: [perl-win32-gui-hackers] Re: Fixing Scintilla

Jeremy White wrote:
> I'm trying to fix Scintilla, with the aim of creating a new release of

> this module. The problem is that Scintilla defines and uses it's own=20
> PERLWIN32GUI_USERDATA structure. As this structure has changed over
time=20
> in Win32-GUI it creates all kinds of problems with this module=20
> (Scintilla subclasses Win32-GUI, and uses the PERLWIN32GUI_USERDATA=20
> structure passed to it by Win32-GUI).  The most extreme behaviour is=20
> with perl 5.8.x where the Scintilla does not process events - there is

> also cases where Scintilla crashes.
>=20
> I've managed to get a build of Scintilla working, but I've got several

> issues. Instead of defining it's own version of PERLWIN32GUI_USERDATA
it=20
> now picks it up from GUI.h - which I think is the best solution (?).
>=20
> 1) The original Scintilla:
>=20
> #include "EXTERN.h"
> #include "perl.h"
> #include "XSUB.h"
>=20
> #include <windows.h>
> #include "./include/Scintilla.h"
>=20
> changed to:
>=20
> #include "../Win32-GUI/GUI.h"
> #include "./include/Scintilla.h"
>=20
> However, when compiling with VC I get two errors:
>=20
> *** Using Preserved Perl context.
>=20
> ../Win32-GUI/GUI.h(439) : error C2143: syntax error : missing ')'
before=20
> '=3D'
> ../Win32-GUI/GUI.h(439) : error C2072: 'DoHook' : initialization of a=20
> function
> ../Win32-GUI/GUI.h(439) : error C2059: syntax error : ')'
> ../Win32-GUI/GUI.h(809) : error C2059: syntax error : 'string'
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code

> '0x2'
> Stop.
>=20
> this is with the line:
>=20
> void DoHook(NOTXSPROC LPPERLWIN32GUI_USERDATA perlud, UINT uMsg,
WPARAM=20
> wParam, LPARAM lParam, int* PerlResult, int notify =3D 0);
>=20
> removing " =3D 0" fixes that issue.

At first glance these errors look like C++ vs. C syntax problems.  I=20
haven't looked at the scintilla code, but it would be my guess that the=20
XS files is being compiled as C (this is the standard Makefile.PL=20
behaviour) whereas Win32::GUI (for reasons that escape me) is built=20
using a C++ compiler (see the override in Win32::GUI's Makefile.PL (sub=20
xs_c) that builds .cpp files from the XS rather than .c files).

There are 2 approaches: (1) add the same override to Scintilla to get it

to make .cpp files from the .xs, forcing the compilers into c++ mode,=20
(2) Fix up the Win32::GUI GUI.h file to work correctly with a standard C

compiler.

I thin that (2) if preferable, and it is one of my longer-term goals to=20
get Win32::GUI to use standard 'C' too.

Standard 'C' does not allow defaulting of function parameters in the=20
prototype, so my solution here would be to remove the "=3D 0" from =
GUI.h,=20
and modify the 2 calls to DoHook() in GUI_MessageLoops.cpp that don't=20
pass the last parameter to pass 0 explicitly.

> The second error:
>=20
> *** Using Preserved Perl context.
>=20
> ../Win32-GUI/GUI.h(809) : error C2059: syntax error : 'string'
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code

> '0x2'
> Stop.
>=20
> this is with:
>=20
> extern "C" BOOL WINAPI
> GetWindowInfo(
>    HWND hwnd,
>    PWINDOWINFO pwi
> );
>=20
> Commenting out this code removes the error.

My fix would be to replace that code with
#ifdef __cplusplus
   extern "C"
#endif
BOOL WINAPI GetWindowInfo(
   HWND hwnd,
   PWINDOWINFO pwi
);

> 2) I'm confused about the Perl context and how it's used within=20
> Win32-GUI - and how Scintilla should handle things.
>=20
> I've got it working by doing:
>=20
> dTHX;       /* fetch context */
>=20
> in the Scintilla event handlers, but had to remove NOTXSCALL/NOTXSPROC

> in some functions where the context isn't used/needed.
>=20
> If it would help, I can check in what I've got, with the idea of
fixing=20
> things once I've got my head around these issues?

I'm not overly familiar with this, but the concept is that a call to a C

  function that doesn't require perl context should look like a regular=20
C call;  A call from an XS sub (or anywhere that has a perl context=20
pointer available) to a function that requires a perl context should be=20
defined with a first argument of NOTXACALL/NOTXSPROC macro (but with no=20
following  comma).  These macros defined the correct type of argument to

pass the perl context.  I can do more investigation and expand on this=20
if necessary.

Regards,
Rob.


--__--__--

Message: 2
Date: Sun, 04 Dec 2005 20:21:24 +0000
From: Robert May <rm...@po...>
Reply-To: rm...@po...
Organization: At Home
To: per...@li...
CC: Jeremy White <jez...@ho...>
Subject: [perl-win32-gui-hackers] Perl contexts [Was: Fixing Scintilla]

>> 2) I'm confused about the Perl context and how it's used within=20
>> Win32-GUI - and how Scintilla should handle things.
>>
>> I've got it working by doing:
>>
>> dTHX;       /* fetch context */
>>
>> in the Scintilla event handlers, but had to remove
NOTXSCALL/NOTXSPROC=20
>> in some functions where the context isn't used/needed.
>>
>> If it would help, I can check in what I've got, with the idea of=20
>> fixing things once I've got my head around these issues?
>=20
>=20
> I'm not overly familiar with this, but the concept is that a call to a
C=20
>  function that doesn't require perl context should look like a regular
C=20
> call;  A call from an XS sub (or anywhere that has a perl context=20
> pointer available) to a function that requires a perl context should
be=20
> defined with a first argument of NOTXACALL/NOTXSPROC macro (but with
no=20
> following  comma).  These macros defined the correct type of argument
to=20
> pass the perl context.  I can do more investigation and expand on this

> if necessary.

OK, I've just scanned the perldoc perlguts section entitled "How=20
multiple interpreters and concurrency are supported".  I think it's=20
reasonable to assume the following:

You can always define PERL_NO_GET_CONTEXT - all modern perl's will=20
behave with this regardless of whether PERL_IMPLICIT_CONTEXT is defined=20
or not (although it is defined for current ActiveState Perl builds -=20
it's required for ithread support).  Defining pTHX, pTHX_, aTHX, aTHX_=20
and dTHX are dealt with in perl.h and XSUB.h

In Win32::GUI NOTXSPROC and NOTXSCALL are aliases for pTHX_ and aTHX_=20
respectively.  Any other code in GUI.h is purely for backwards=20
compatibility with older perl's.  Even the "\n*** Using an implicit Perl

context.\n" section should not be necessary, as pTHX_ and aTHX_ should=20
deal with non-thread-capable perl builds.

To understand how to use pTHX_ and aTHX_ correctly read perlguts - but=20
for consistency with Win32::GUI I would recommend using NOTXSPROC and=20
NOTXSCALL macros in their place.

[ I've added a note to myself to look for all the places that we use=20
dTHX and to ensure that they are necessary - I think they are used when=20
we get a win32 api callback such that we can't use the NOTXSPROC calling

convention ]

I hope this helps.

Rob.







--__--__--

_______________________________________________
Perl-Win32-GUI-Hackers mailing list
Per...@li...
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers
http://perl-win32-gui.sourceforge.net/


End of Perl-Win32-GUI-Hackers Digest

[perl-win32-gui-hackers] Win32::GUI::Scintilla V1.08

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

Hi,

I've just committed some changes to Scintilla, the main ones being that 
events now fire for perl 5.8.x. This fix also solves a few issues where 
Scintilla was crashing, again with perl 5.8.x. This module should work with 
any version of Win32::GUI from V1.00 upwards.

I've also updated Scintilla to 1.66 from 1.59, which contains lots of fixes 
and improvements:

http://scintilla.sourceforge.net/ScintillaHistory.html

This module should build via mingw or MS VC, but you will need the latest 
source for Win32-GUI.

If there are any issues, please let me know. I'll try and get a PPM on the 
sourceforge site later in the week.

Cheers,

jez.

[perl-win32-gui-hackers] RE: Perl contexts [Was: Fixing Scintilla]

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

>[ I've added a note to myself to look for all the places that we use dTHX 
>and to ensure that they are necessary - I think they are used when we get a 
>win32 api callback such that we can't use the NOTXSPROC calling convention 
>]

I'm still not 100% sure how the context works within Win32-GUI but there 
might be a problem when Win32-GUI is used in a threaded app, where you want 
different threads to deal with different windows (see AttachThreadInput 
method in the docs).

As I understand things, we're storing the context in PERLWIN32GUI_USERDATA 
via the macro PERLUD_DECLARE and we're fetching the context via the macro 
PERLUD_FETCH. As we're fetching the context everytime we're doing an event, 
we are *always* using the perl interpreter that created the window, rather 
than the context that is associated with the current running thread.

I'm not to sure what the solution could be, as I understand things you can't 
pass sub refs around perl threads, which means that NEM would be broken 
(i.e., thread A creates the window and the sub refs for the events, but you 
need thread B to respond to events for the window created by A). From very 
bitter experience, Perl 5.6 and most 5.8.x (5.8.7 seems ok) threading at the 
deep perl level is broken.

Cheers,

jez.

[perl-win32-gui-hackers] Re: Fixing Scintilla

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

>At first glance these errors look like C++ vs. C syntax problems.  I 
>haven't looked at the scintilla code, but it would be my guess that the XS 
>files is being compiled as C (this is the standard Makefile.PL behaviour) 
>whereas Win32::GUI (for reasons that escape me) is built using a C++ 
>compiler (see the override in Win32::GUI's Makefile.PL (sub xs_c) that 
>builds .cpp files from the XS rather than .c files).

ARH! Yes, you are right. I've always wondered why win32-gui used a C++ 
compiler, as there is no C++ code.

>I thin that (2) if preferable, and it is one of my longer-term goals to get 
>Win32::GUI to use standard 'C' too.

I changed GUI.h (and GUI_MessageLoops.cpp) to be "C" safe.

Cheers,

jez.

[perl-win32-gui-hackers] Perl contexts [Was: Fixing Scintilla]

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

>> 2) I'm confused about the Perl context and how it's used within 
>> Win32-GUI - and how Scintilla should handle things.
>>
>> I've got it working by doing:
>>
>> dTHX;       /* fetch context */
>>
>> in the Scintilla event handlers, but had to remove NOTXSCALL/NOTXSPROC 
>> in some functions where the context isn't used/needed.
>>
>> If it would help, I can check in what I've got, with the idea of 
>> fixing things once I've got my head around these issues?
> 
> 
> I'm not overly familiar with this, but the concept is that a call to a C 
>  function that doesn't require perl context should look like a regular C 
> call;  A call from an XS sub (or anywhere that has a perl context 
> pointer available) to a function that requires a perl context should be 
> defined with a first argument of NOTXACALL/NOTXSPROC macro (but with no 
> following  comma).  These macros defined the correct type of argument to 
> pass the perl context.  I can do more investigation and expand on this 
> if necessary.

OK, I've just scanned the perldoc perlguts section entitled "How 
multiple interpreters and concurrency are supported".  I think it's 
reasonable to assume the following:

You can always define PERL_NO_GET_CONTEXT - all modern perl's will 
behave with this regardless of whether PERL_IMPLICIT_CONTEXT is defined 
or not (although it is defined for current ActiveState Perl builds - 
it's required for ithread support).  Defining pTHX, pTHX_, aTHX, aTHX_ 
and dTHX are dealt with in perl.h and XSUB.h

In Win32::GUI NOTXSPROC and NOTXSCALL are aliases for pTHX_ and aTHX_ 
respectively.  Any other code in GUI.h is purely for backwards 
compatibility with older perl's.  Even the "\n*** Using an implicit Perl 
context.\n" section should not be necessary, as pTHX_ and aTHX_ should 
deal with non-thread-capable perl builds.

To understand how to use pTHX_ and aTHX_ correctly read perlguts - but 
for consistency with Win32::GUI I would recommend using NOTXSPROC and 
NOTXSCALL macros in their place.

[ I've added a note to myself to look for all the places that we use 
dTHX and to ensure that they are necessary - I think they are used when 
we get a win32 api callback such that we can't use the NOTXSPROC calling 
convention ]

I hope this helps.

Rob.

[perl-win32-gui-hackers] Re: Fixing Scintilla

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

Jeremy White wrote:
> I'm trying to fix Scintilla, with the aim of creating a new release of 
> this module. The problem is that Scintilla defines and uses it's own 
> PERLWIN32GUI_USERDATA structure. As this structure has changed over time 
> in Win32-GUI it creates all kinds of problems with this module 
> (Scintilla subclasses Win32-GUI, and uses the PERLWIN32GUI_USERDATA 
> structure passed to it by Win32-GUI).  The most extreme behaviour is 
> with perl 5.8.x where the Scintilla does not process events - there is 
> also cases where Scintilla crashes.
> 
> I've managed to get a build of Scintilla working, but I've got several 
> issues. Instead of defining it's own version of PERLWIN32GUI_USERDATA it 
> now picks it up from GUI.h - which I think is the best solution (?).
> 
> 1) The original Scintilla:
> 
> #include "EXTERN.h"
> #include "perl.h"
> #include "XSUB.h"
> 
> #include <windows.h>
> #include "./include/Scintilla.h"
> 
> changed to:
> 
> #include "../Win32-GUI/GUI.h"
> #include "./include/Scintilla.h"
> 
> However, when compiling with VC I get two errors:
> 
> *** Using Preserved Perl context.
> 
> ../Win32-GUI/GUI.h(439) : error C2143: syntax error : missing ')' before 
> '='
> ../Win32-GUI/GUI.h(439) : error C2072: 'DoHook' : initialization of a 
> function
> ../Win32-GUI/GUI.h(439) : error C2059: syntax error : ')'
> ../Win32-GUI/GUI.h(809) : error C2059: syntax error : 'string'
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code 
> '0x2'
> Stop.
> 
> this is with the line:
> 
> void DoHook(NOTXSPROC LPPERLWIN32GUI_USERDATA perlud, UINT uMsg, WPARAM 
> wParam, LPARAM lParam, int* PerlResult, int notify = 0);
> 
> removing " = 0" fixes that issue.

At first glance these errors look like C++ vs. C syntax problems.  I 
haven't looked at the scintilla code, but it would be my guess that the 
XS files is being compiled as C (this is the standard Makefile.PL 
behaviour) whereas Win32::GUI (for reasons that escape me) is built 
using a C++ compiler (see the override in Win32::GUI's Makefile.PL (sub 
xs_c) that builds .cpp files from the XS rather than .c files).

There are 2 approaches: (1) add the same override to Scintilla to get it 
to make .cpp files from the .xs, forcing the compilers into c++ mode, 
(2) Fix up the Win32::GUI GUI.h file to work correctly with a standard C 
compiler.

I thin that (2) if preferable, and it is one of my longer-term goals to 
get Win32::GUI to use standard 'C' too.

Standard 'C' does not allow defaulting of function parameters in the 
prototype, so my solution here would be to remove the "= 0" from GUI.h, 
and modify the 2 calls to DoHook() in GUI_MessageLoops.cpp that don't 
pass the last parameter to pass 0 explicitly.

> The second error:
> 
> *** Using Preserved Perl context.
> 
> ../Win32-GUI/GUI.h(809) : error C2059: syntax error : 'string'
> NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code 
> '0x2'
> Stop.
> 
> this is with:
> 
> extern "C" BOOL WINAPI
> GetWindowInfo(
>    HWND hwnd,
>    PWINDOWINFO pwi
> );
> 
> Commenting out this code removes the error.

My fix would be to replace that code with
#ifdef __cplusplus
   extern "C"
#endif
BOOL WINAPI GetWindowInfo(
   HWND hwnd,
   PWINDOWINFO pwi
);

> 2) I'm confused about the Perl context and how it's used within 
> Win32-GUI - and how Scintilla should handle things.
> 
> I've got it working by doing:
> 
> dTHX;       /* fetch context */
> 
> in the Scintilla event handlers, but had to remove NOTXSCALL/NOTXSPROC 
> in some functions where the context isn't used/needed.
> 
> If it would help, I can check in what I've got, with the idea of fixing 
> things once I've got my head around these issues?

I'm not overly familiar with this, but the concept is that a call to a C 
  function that doesn't require perl context should look like a regular 
C call;  A call from an XS sub (or anywhere that has a perl context 
pointer available) to a function that requires a perl context should be 
defined with a first argument of NOTXACALL/NOTXSPROC macro (but with no 
following  comma).  These macros defined the correct type of argument to 
pass the perl context.  I can do more investigation and expand on this 
if necessary.

Regards,
Rob.

[perl-win32-gui-hackers] Fixing Scintilla

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

Hi,

I'm trying to fix Scintilla, with the aim of creating a new release of this 
module. The problem is that Scintilla defines and uses it's own 
PERLWIN32GUI_USERDATA structure. As this structure has changed over time in 
Win32-GUI it creates all kinds of problems with this module (Scintilla 
subclasses Win32-GUI, and uses the PERLWIN32GUI_USERDATA structure passed to 
it by Win32-GUI).  The most extreme behaviour is with perl 5.8.x where the 
Scintilla does not process events - there is also cases where Scintilla 
crashes.

I've managed to get a build of Scintilla working, but I've got several 
issues. Instead of defining it's own version of PERLWIN32GUI_USERDATA it now 
picks it up from GUI.h - which I think is the best solution (?).

1) The original Scintilla:

#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

#include <windows.h>
#include "./include/Scintilla.h"

changed to:

#include "../Win32-GUI/GUI.h"
#include "./include/Scintilla.h"

However, when compiling with VC I get two errors:

*** Using Preserved Perl context.

../Win32-GUI/GUI.h(439) : error C2143: syntax error : missing ')' before '='
../Win32-GUI/GUI.h(439) : error C2072: 'DoHook' : initialization of a 
function
../Win32-GUI/GUI.h(439) : error C2059: syntax error : ')'
../Win32-GUI/GUI.h(809) : error C2059: syntax error : 'string'
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2'
Stop.

this is with the line:

void DoHook(NOTXSPROC LPPERLWIN32GUI_USERDATA perlud, UINT uMsg, WPARAM 
wParam, LPARAM lParam, int* PerlResult, int notify = 0);

removing " = 0" fixes that issue.

The second error:

*** Using Preserved Perl context.

../Win32-GUI/GUI.h(809) : error C2059: syntax error : 'string'
NMAKE : fatal error U1077: 'C:\WINDOWS\system32\cmd.exe' : return code '0x2'
Stop.

this is with:

extern "C" BOOL WINAPI
GetWindowInfo(
    HWND hwnd,
    PWINDOWINFO pwi
);

Commenting out this code removes the error.

In both cases I don't understand why they cause errors?

2) I'm confused about the Perl context and how it's used within Win32-GUI - 
and how Scintilla should handle things.

I've got it working by doing:

dTHX;       /* fetch context */

in the Scintilla event handlers, but had to remove NOTXSCALL/NOTXSPROC in 
some functions where the context isn't used/needed.

If it would help, I can check in what I've got, with the idea of fixing 
things once I've got my head around these issues?

Cheers,

jez.

[perl-win32-gui-hackers] Commit (crashes on exit and memory leaks)

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

Last Night I committed a couple of bug fixes:

- GUI.h change order of instructions in PERL_FREE macro to prevent 
crashes (Trackers 1243378 and 1248578)

I hope this fix will eliminate most of the crashes/warnings hat happen 
on program termination.  If you have any example code that still crashes 
or warns when your script ends, then I be interested in seeing it. 
Details of the exact problem below.

- GUI.xs change logic in all message loops (Dialog, DoEvents, DoModal) 
to prevent memory leak (Tracker: 1201190)

All 3 message loops were leaking memory whenever one of the windows 
functions TranslateMDISysAccel, TranslateAccelerator or IsDialogMessage 
processed and dispatched a message.

- Listbox.xs add documentation to differentiate between SetCurSel and 
SetSel (Tracker 1177898)



Crashes on Exit - explanation of the problem and the (simple) fix
------------------------------------------------------------------

Tracker 1243378 gave me some code that reliably crashed on exit in my 
environment (AS Perl 5.8.7, Win98, MSVC 6)

The code was approximately:

[1] my $mw = Win32::GUI::Window->new( ... );
[2] my $re = $mw->AddRichEdit( ... );

[3] $re->Change( -onMouseMove => sub {my $text = $re->Text() } );

Some notation:
- The Win32::GUI::Window object will be referred to as WO
- The Win32::GUI::RichEdit object will be referred to as RO
- The anonymous sub in line [3] will be referred to as AS

Here's what was happening:
Line [1] creates TWO, with ref count 1 (from $mw)
Line [2] creates RO, with ref count 2 (from $re and WO)
Line [3] creates AS, with ref count 1 (from storing in hvEvents hash in 
perlud for RO)
Line [3] increases ref count of RO to 3 (from closure on $re)

Now, when the script finishes the following happens:
$mw and $re go out of scope.
WO ref count goes to 0, RO ref count goes to 2

DESTROY gets called on WO, as it's ref count is 0:
- all child object refs are removed from WO, leading to RO ref count 
going to 1 (from the closure referenced in its own hvEvents hash)
- DestroyWindow() is called on WO window handle.  DestroyWindow() sends 
WM_DESTROY messages to each of the top level window's children, before 
sending WM_DESTROY to the top-level window itself.
- WM_DESTROY received by RO, calls PERLUD_FREE, which among other things 
clears the hvEvents hash.  This reduces the ref count of RO to 0, as AS 
ref count goes to 0, resulting in RO's DESTROY method being called 
before PERLUD_FREE finishes
- RO's destroy method removes any child window references from RO (none 
in this case), then calls DestroyWindow() on RO window handle, resulting 
in RO receiving WM_DESTROY again, and calling PERUD_FREE a second time. 
  PERLUD_FREE gets a pointer to perud, and tries to free stuff that may 
already have been freed by the first call, and frees stuff that the 
first call has not yet freed, but will try to once control returns there.

The fix was simply to make PERUD_FREE set the pointer to perud to NULL 
before freeing the memory used, so that the second PERUD_FREE sees that 
perud has already been tidied-up and does nothing.

Regards,
Rob.

[perl-win32-gui-hackers] Commit

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

Hi,

I've just committed a change to the typemap. It now uses one hash lookup, 
rather than two, and as a result is faster. As this typemap is used for 
almost all objects and method calls, there might be some gains for some 
calls (depending on what the method actually does). The benchmark below is 
for a dummy method that doesn't do anything:

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)

I've tested this change under mingw and vc, and it seems to work fine. If 
there are any issues, drop me a mail.

Cheers,

jez.

Re: [win32gui] RE: [perl-win32-gui-hackers] ANNOUNCE: Win32::GUI v1.03 released

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

Jeremy White wrote:
> 
> I downloaded the 5.8 ppm and everything seems ok.

Thanks for the feedback.

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

RE: [perl-win32-gui-hackers] ANNOUNCE: Win32::GUI v1.03 released

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

>I am please to announce that v1.03 of Win32::GUI is available for
>download from SourceForge.

I downloaded the 5.8 ppm and everything seems ok.

Good work.

Cheers,

jez.