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

Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

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

On approximately 3/14/2004 8:00 PM, came the following characters from
the keyboard of Glenn Linderman:

> I'd rather not hold anything up, 
> but I need NotifyIcon support if I'm going to use NEM.

Please don't hold up a release on my account.  I've chosen to back out 
my attempt to convert code from OEM to NEM...

Besides NotifyIcon, Accelerator Keys, and RightClick support being 
missing from NEM, I fear there may be other features missing that I have 
not yet discovered... and I am already seriously behind schedule in my 
project, and cannot add to that a development project of unknown size 
and scope for completion of the missing features of NEM that I need for 
the project, that already exist in OEM.

While I believe NEM or the followon UEM has a number of technical 
advantages if fully implemented, OEM + HEM presently has the features I 
need.

So a new release would help all the NEM people, so go for it!

And good luck with NEM and UEM development.  I'll try to keep tracking 
progress, and offering suggestions that might be helpful, but for now I 
simply must finish my project, as it has customers with a deadline.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] NEM_ChildMsgLoop and InteractiveGraphicMsgLoop

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

On approximately 3/17/2004 6:52 AM, came the following characters from
the keyboard of Jez White:
>>Only one, about the _RButtonDown.... I notice that NEM doesn't seem to
>>have any support for the right button at all... or else I can't see it,
>>at least.  So _RightClick isn't there either.
> 
> Would it make sense for controls with many events, or unique events (such as
> the treeview and Graphic controls) to have their own NEM msg loop?

Well, it depends on how similar the processing of the events is.  If a 
particular control is very unique, and has events that must have lots of 
special handling, then probably that would be a good thing, for clarity 
and modularization.  But if it is just a matter of adding more events to 
a big switch statement, and the bulk of the processing is very similar 
to other events, then I don't see a particular need.  So this is very 
much a matter of opinion.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] NEM_ChildMsgLoop and InteractiveGraphicMsgLoop

[Jez W. <je...@je...>]

> Only one, about the _RButtonDown.... I notice that NEM doesn't seem to
> have any support for the right button at all... or else I can't see it,
> at least.  So _RightClick isn't there either.

Would it make sense for controls with many events, or unique events (such as
the treeview and Graphic controls) to have their own NEM msg loop?

jez.

Re: [perl-win32-gui-hackers] NEM_ChildMsgLoop and InteractiveGraphicMsgLoop

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

On approximately 3/16/2004 8:24 AM, came the following characters from
the keyboard of Jez White:
> Hi,
>  
> I've been playing with NEM and Win32::GUI::Graphic objects and there 
> seems to be some differences between the NEM and OEM events (NEM does 
> not fire _LButtonDown,_RButtonDown for example). The Win32::GUI::Graphic 
> NEM is handled via NEM_ChildMsgLoop and in OEM via 
> InteractiveGraphicMsgLoop (when the Graphic object has the interactive 
> flag). Another problem I've noticed is that for some reason, the 
> WM_ERASEBKGND is fired in NEM, which causes the background of the image 
> to be redrawn (causing a flicker)...
>  
> Thoughts?

Only one, about the _RButtonDown.... I notice that NEM doesn't seem to 
have any support for the right button at all... or else I can't see it, 
at least.  So _RightClick isn't there either.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

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

On approximately 3/16/2004 11:50 AM, came the following characters from
the keyboard of Laurent ROCHER:

> Hi,
> 
> 
>>So the set of #defines named  PERLWIN32GUI_NEM_* are mostly to do with
>>that bit field.  The DEACTIVATE, ACTIVATE, TERMINATE, MINIMIZE,
>>MAXIMIZE, and RESIZE seem to have two bits set... but no special
>>consideration is given to that in the code, as far as I can tell.  So if
>>any of these are defined, it could cause all of the others to be looked
>>up in the hash?  As well as SCROLL, and one of the ones from MOUSEMOVE
>>to CLICK?
>>
>>Does anyone have an explanation for this?
> 
> 
> I don't know why too.
> 
> For add NEM event, i think you have too place to change :
>     - ParseNEMEvent for parsing event
>     - NEM_WindowMsgLoop for handle event.
> 
> I think we need to redefine PERLWIN32GUI_NEM event constant for handle more
> event per control.
> For sample, if we modify event constant like below, we can win some extra
> bit (and event).
> We can win more bit by create specific event constant for each control.
> But, i think it's ok for now and we don't need to change all constant every
> where.

Yes, this approach would allow multiple controls to reuse the same bits 
for orthogonal items.  That would be more efficient than the "bundling" 
I suggested.  But I guess I'll bundle all the NotifyIcon ones, because 
otherwise I'd need 3 bits, and there are only 2 left.

> Laurent
> 
> GUI.h
> 
> // Common Event (All control)
> #define PERLWIN32GUI_NEM_MOUSEMOVE                      0x00000001
> #define PERLWIN32GUI_NEM_MOUSEDOWN                      0x00000002
> #define PERLWIN32GUI_NEM_MOUSEUP                        0x00000004
> #define PERLWIN32GUI_NEM_KEYDOWN                        0x00000008
> #define PERLWIN32GUI_NEM_KEYUP                          0x00000010
> #define PERLWIN32GUI_NEM_TIMER                          0x00000020
> #define PERLWIN32GUI_NEM_PAINT                          0x00000040
> 
> // Generic control Event constant
> #define PERLWIN32GUI_NEM_CONTROL1                       0x80000000
> #define PERLWIN32GUI_NEM_CONTROL2                       0x40000000
> #define PERLWIN32GUI_NEM_CONTROL3                       0x20000000
> #define PERLWIN32GUI_NEM_CONTROL4                       0x10000000
> #define PERLWIN32GUI_NEM_CONTROL5                       0x08000000
> #define PERLWIN32GUI_NEM_CONTROL6                       0x04000000
> #define PERLWIN32GUI_NEM_CONTROL7                       0x02000000
> #define PERLWIN32GUI_NEM_CONTROL8                       0x01000000
> #define PERLWIN32GUI_NEM_CONTROL9                       0x00800000
> #define PERLWIN32GUI_NEM_CONTROL10                      0x00400000
> #define PERLWIN32GUI_NEM_CONTROL11                      0x00200000
> #define PERLWIN32GUI_NEM_CONTROL12                      0x00100000
> #define PERLWIN32GUI_NEM_CONTROL13                      0x00080000
> #define PERLWIN32GUI_NEM_CONTROL14                      0x00040000
> #define PERLWIN32GUI_NEM_CONTROL15                      0x00020000
> #define PERLWIN32GUI_NEM_CONTROL16                      0x00010000
> #define PERLWIN32GUI_NEM_CONTROL17                      0x00008000
> #define PERLWIN32GUI_NEM_CONTROL18                      0x00004000
> #define PERLWIN32GUI_NEM_CONTROL19                      0x00002000
> #define PERLWIN32GUI_NEM_CONTROL20                      0x00001000
> 
> // Multiple control
> #define PERLWIN32GUI_NEM_CLICK
> PERLWIN32GUI_NEM_CONTROL20
> #define PERLWIN32GUI_NEM_DBLCLICK
> PERLWIN32GUI_NEM_CONTROL19
> #define PERLWIN32GUI_NEM_GOTFOCUS
> PERLWIN32GUI_NEM_CONTROL18
> #define PERLWIN32GUI_NEM_LOSTFOCUS
> PERLWIN32GUI_NEM_CONTROL17
> #define PERLWIN32GUI_NEM_CHANGE
> PERLWIN32GUI_NEM_CONTROL16
> #define PERLWIN32GUI_NEM_CHANGING
> PERLWIN32GUI_NEM_CONTROL15
> // Common control ListView & Header & TreeView
> #define PERLWIN32GUI_NEM_ITEMCLICK
> PERLWIN32GUI_NEM_CONTROL14
> #define PERLWIN32GUI_NEM_NODECLICK
> PERLWIN32GUI_NEM_CONTROL14
> 
> // Specific Window & Dialog
> #define PERLWIN32GUI_NEM_DEACTIVATE
> PERLWIN32GUI_NEM_CONTROL1
> #define PERLWIN32GUI_NEM_ACTIVATE
> PERLWIN32GUI_NEM_CONTROL2
> #define PERLWIN32GUI_NEM_TERMINATE
> PERLWIN32GUI_NEM_CONTROL3
> #define PERLWIN32GUI_NEM_MINIMIZE
> PERLWIN32GUI_NEM_CONTROL4
> #define PERLWIN32GUI_NEM_MAXIMIZE
> PERLWIN32GUI_NEM_CONTROL5
> #define PERLWIN32GUI_NEM_RESIZE
> PERLWIN32GUI_NEM_CONTROL6
> #define PERLWIN32GUI_NEM_SCROLL
> PERLWIN32GUI_NEM_CONTROL7
> // Specific ToolBar
> #define PERLWIN32GUI_NEM_BUTTONCLICK
> PERLWIN32GUI_NEM_CONTROL1
> // Specific ToolTip
> #define PERLWIN32GUI_NEM_NEEDTEXT
> PERLWIN32GUI_NEM_CONTROL1
> // Specific Rebar
> #define PERLWIN32GUI_NEM_HEIGHTCHANGE
> PERLWIN32GUI_NEM_CONTROL1
> // Specific Listview
> #define PERLWIN32GUI_NEM_ITEMCHECK
> PERLWIN32GUI_NEM_CONTROL1
> #define PERLWIN32GUI_NEM_COLUMNCLICK
> PERLWIN32GUI_NEM_CONTROL2
> // Specific Treeview
> #define PERLWIN32GUI_NEM_COLLAPSE
> PERLWIN32GUI_NEM_CONTROL1
> #define PERLWIN32GUI_NEM_COLLAPSING
> PERLWIN32GUI_NEM_CONTROL2
> #define PERLWIN32GUI_NEM_EXPAND
> PERLWIN32GUI_NEM_CONTROL3
> #define PERLWIN32GUI_NEM_EXPANDING
> PERLWIN32GUI_NEM_CONTROL4
> // Specific Rebar
> #define PERLWIN32GUI_NEM_BEGINTRACK
> PERLWIN32GUI_NEM_CONTROL1
> #define PERLWIN32GUI_NEM_ENDTRACK
> PERLWIN32GUI_NEM_CONTROL2
> #define PERLWIN32GUI_NEM_TRACK
> PERLWIN32GUI_NEM_CONTROL3
> #define PERLWIN32GUI_NEM_DIVIDERDBLCLICK
> PERLWIN32GUI_NEM_CONTROL4
> #define PERLWIN32GUI_NEM_ITEMDBLCLICK
> PERLWIN32GUI_NEM_CONTROL5
> 
> 
> 
> 

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

[Laurent R. <ro...@cl...>]

Hi,

> So the set of #defines named  PERLWIN32GUI_NEM_* are mostly to do with
> that bit field.  The DEACTIVATE, ACTIVATE, TERMINATE, MINIMIZE,
> MAXIMIZE, and RESIZE seem to have two bits set... but no special
> consideration is given to that in the code, as far as I can tell.  So if
> any of these are defined, it could cause all of the others to be looked
> up in the hash?  As well as SCROLL, and one of the ones from MOUSEMOVE
> to CLICK?
>
> Does anyone have an explanation for this?

I don't know why too.

For add NEM event, i think you have too place to change :
    - ParseNEMEvent for parsing event
    - NEM_WindowMsgLoop for handle event.

I think we need to redefine PERLWIN32GUI_NEM event constant for handle more
event per control.
For sample, if we modify event constant like below, we can win some extra
bit (and event).
We can win more bit by create specific event constant for each control.
But, i think it's ok for now and we don't need to change all constant every
where.

Laurent

GUI.h

// Common Event (All control)
#define PERLWIN32GUI_NEM_MOUSEMOVE                      0x00000001
#define PERLWIN32GUI_NEM_MOUSEDOWN                      0x00000002
#define PERLWIN32GUI_NEM_MOUSEUP                        0x00000004
#define PERLWIN32GUI_NEM_KEYDOWN                        0x00000008
#define PERLWIN32GUI_NEM_KEYUP                          0x00000010
#define PERLWIN32GUI_NEM_TIMER                          0x00000020
#define PERLWIN32GUI_NEM_PAINT                          0x00000040

// Generic control Event constant
#define PERLWIN32GUI_NEM_CONTROL1                       0x80000000
#define PERLWIN32GUI_NEM_CONTROL2                       0x40000000
#define PERLWIN32GUI_NEM_CONTROL3                       0x20000000
#define PERLWIN32GUI_NEM_CONTROL4                       0x10000000
#define PERLWIN32GUI_NEM_CONTROL5                       0x08000000
#define PERLWIN32GUI_NEM_CONTROL6                       0x04000000
#define PERLWIN32GUI_NEM_CONTROL7                       0x02000000
#define PERLWIN32GUI_NEM_CONTROL8                       0x01000000
#define PERLWIN32GUI_NEM_CONTROL9                       0x00800000
#define PERLWIN32GUI_NEM_CONTROL10                      0x00400000
#define PERLWIN32GUI_NEM_CONTROL11                      0x00200000
#define PERLWIN32GUI_NEM_CONTROL12                      0x00100000
#define PERLWIN32GUI_NEM_CONTROL13                      0x00080000
#define PERLWIN32GUI_NEM_CONTROL14                      0x00040000
#define PERLWIN32GUI_NEM_CONTROL15                      0x00020000
#define PERLWIN32GUI_NEM_CONTROL16                      0x00010000
#define PERLWIN32GUI_NEM_CONTROL17                      0x00008000
#define PERLWIN32GUI_NEM_CONTROL18                      0x00004000
#define PERLWIN32GUI_NEM_CONTROL19                      0x00002000
#define PERLWIN32GUI_NEM_CONTROL20                      0x00001000

// Multiple control
#define PERLWIN32GUI_NEM_CLICK
PERLWIN32GUI_NEM_CONTROL20
#define PERLWIN32GUI_NEM_DBLCLICK
PERLWIN32GUI_NEM_CONTROL19
#define PERLWIN32GUI_NEM_GOTFOCUS
PERLWIN32GUI_NEM_CONTROL18
#define PERLWIN32GUI_NEM_LOSTFOCUS
PERLWIN32GUI_NEM_CONTROL17
#define PERLWIN32GUI_NEM_CHANGE
PERLWIN32GUI_NEM_CONTROL16
#define PERLWIN32GUI_NEM_CHANGING
PERLWIN32GUI_NEM_CONTROL15
// Common control ListView & Header & TreeView
#define PERLWIN32GUI_NEM_ITEMCLICK
PERLWIN32GUI_NEM_CONTROL14
#define PERLWIN32GUI_NEM_NODECLICK
PERLWIN32GUI_NEM_CONTROL14

// Specific Window & Dialog
#define PERLWIN32GUI_NEM_DEACTIVATE
PERLWIN32GUI_NEM_CONTROL1
#define PERLWIN32GUI_NEM_ACTIVATE
PERLWIN32GUI_NEM_CONTROL2
#define PERLWIN32GUI_NEM_TERMINATE
PERLWIN32GUI_NEM_CONTROL3
#define PERLWIN32GUI_NEM_MINIMIZE
PERLWIN32GUI_NEM_CONTROL4
#define PERLWIN32GUI_NEM_MAXIMIZE
PERLWIN32GUI_NEM_CONTROL5
#define PERLWIN32GUI_NEM_RESIZE
PERLWIN32GUI_NEM_CONTROL6
#define PERLWIN32GUI_NEM_SCROLL
PERLWIN32GUI_NEM_CONTROL7
// Specific ToolBar
#define PERLWIN32GUI_NEM_BUTTONCLICK
PERLWIN32GUI_NEM_CONTROL1
// Specific ToolTip
#define PERLWIN32GUI_NEM_NEEDTEXT
PERLWIN32GUI_NEM_CONTROL1
// Specific Rebar
#define PERLWIN32GUI_NEM_HEIGHTCHANGE
PERLWIN32GUI_NEM_CONTROL1
// Specific Listview
#define PERLWIN32GUI_NEM_ITEMCHECK
PERLWIN32GUI_NEM_CONTROL1
#define PERLWIN32GUI_NEM_COLUMNCLICK
PERLWIN32GUI_NEM_CONTROL2
// Specific Treeview
#define PERLWIN32GUI_NEM_COLLAPSE
PERLWIN32GUI_NEM_CONTROL1
#define PERLWIN32GUI_NEM_COLLAPSING
PERLWIN32GUI_NEM_CONTROL2
#define PERLWIN32GUI_NEM_EXPAND
PERLWIN32GUI_NEM_CONTROL3
#define PERLWIN32GUI_NEM_EXPANDING
PERLWIN32GUI_NEM_CONTROL4
// Specific Rebar
#define PERLWIN32GUI_NEM_BEGINTRACK
PERLWIN32GUI_NEM_CONTROL1
#define PERLWIN32GUI_NEM_ENDTRACK
PERLWIN32GUI_NEM_CONTROL2
#define PERLWIN32GUI_NEM_TRACK
PERLWIN32GUI_NEM_CONTROL3
#define PERLWIN32GUI_NEM_DIVIDERDBLCLICK
PERLWIN32GUI_NEM_CONTROL4
#define PERLWIN32GUI_NEM_ITEMDBLCLICK
PERLWIN32GUI_NEM_CONTROL5

[perl-win32-gui-hackers] NEM_ChildMsgLoop and InteractiveGraphicMsgLoop

[Jez W. <je...@je...>]

Hi,

I've been playing with NEM and Win32::GUI::Graphic objects and there =
seems to be some differences between the NEM and OEM events (NEM does =
not fire _LButtonDown,_RButtonDown for example). The Win32::GUI::Graphic =
NEM is handled via NEM_ChildMsgLoop and in OEM via =
InteractiveGraphicMsgLoop (when the Graphic object has the interactive =
flag). Another problem I've noticed is that for some reason, the =
WM_ERASEBKGND is fired in NEM, which causes the background of the image =
to be redrawn (causing a flicker)...

Thoughts?

jez.

Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

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

On approximately 3/14/2004 8:00 PM, came the following characters from
the keyboard of Glenn Linderman:

> I was working on trying to transform the WM_NOTIFYICON code from the 
> standard message loop to work in the NEM message loop, and allow 
> AddNotifyIcon to take -onClick -onRightClick and -events parameters, 
> with the -events allowing Click and RightClick.  Then I noticed 
> MousEvent in the default case, I guess we'd need -onMouseEvent for that?
> 
> I haven't really figured out the "correct" data structures for where to 
> put the sub refs for -onClick etc. so that they can be found and called 
> via DoEvent_NEM... that was what I'd hoped to figure out tomorrow or so.
> Or else to invent a new DoEvent_NEM type function that accepts the sub 
> ref as a parameter, and does all the standard Perl interfacing. 
> Depending on what I could figure out.  I'd rather not hold anything up, 
> but I need NotifyIcon support if I'm going to use NEM.

OK, I've figured out a few things about NEM event processing.  There is 
a hash with all the events, by name, hung off the window structure. 
And, there is a bitfield, which apparently is an optimization to avoid 
checking the hash to discover that the event name wasn't registered.

So the set of #defines named  PERLWIN32GUI_NEM_* are mostly to do with 
that bit field.  The DEACTIVATE, ACTIVATE, TERMINATE, MINIMIZE, 
MAXIMIZE, and RESIZE seem to have two bits set... but no special 
consideration is given to that in the code, as far as I can tell.  So if 
any of these are defined, it could cause all of the others to be looked 
up in the hash?  As well as SCROLL, and one of the ones from MOUSEMOVE 
to CLICK?

Maybe it is "known" that MOUSEMOVE->CLICK are never used for the same 
types of windows as DEACTIVATE->RESIZE?  But if that is the case, 
there'd be no need for the 0x10000000 bit to be set in 
DEACTIVATE->RESIZE... simple reuse of the lower bits would be fine... 
and then defining a handler for one of these wouldn't cause hash to be 
checked for all of them!

And maybe SCROLL was added later, not noticing that it overlapped with 
the bit in DEACTIVATE->RESIZE?

Does anyone have an explanation for this?

I'm planning to add NOTIFYICON to the list of bits, and set it in the 
flags words if any of NotifyIcon Click, RightClick, or MouseEvent 
handlers are defined.  So hence if any of this "bundle" are defined, all 
of them will pay the price of checking the hash for existance.

And it looks like to support Accelerator keys, I'm going to need to add 
ACCELERATOR to the list, which will use the last available bit... and 
"bundle" all the accelerator keys under that bit.

I wonder if there are other items that could be "bundled" to save bits? 
   MOUSEDOWN MOUSEUP ?  CLICK DBLCLICK ? GOTFOCUS LOSTFOCUS ?

Hmmm. Surprised there is no RIGHTCLICK or DBLRIGHTCLICK on anything in 
these lists!... that'd make a nice bundle too.  Doesn't NEM support 
RightClicking?

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

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

On approximately 3/14/2004 8:00 PM, came the following characters from
the keyboard of Glenn Linderman:
> On approximately 3/14/2004 12:12 PM, came the following characters from
> the keyboard of Laurent ROCHER:
> 
>> Hi All,
>>  
>>     It's probably time to made a new Win32::GUI release based on 
>> Win32-GUI-0_0_665-fix branch.
>>     I can create a Win32-GUI-0.0.671 from this branch.
>>     Does someone have something to put in this branch before release ?
> 
> 
> I was working on trying to transform the WM_NOTIFYICON code from the 
> standard message loop to work in the NEM message loop, and allow 
> AddNotifyIcon to take -onClick -onRightClick and -events parameters, 
> with the -events allowing Click and RightClick.  Then I noticed 
> MousEvent in the default case, I guess we'd need -onMouseEvent for that?
> 
> I haven't really figured out the "correct" data structures for where to 
> put the sub refs for -onClick etc. so that they can be found and called 
> via DoEvent_NEM... that was what I'd hoped to figure out tomorrow or so.
> Or else to invent a new DoEvent_NEM type function that accepts the sub 
> ref as a parameter, and does all the standard Perl interfacing. 
> Depending on what I could figure out.  I'd rather not hold anything up, 
> but I need NotifyIcon support if I'm going to use NEM.
> 
> This was based off of the last dev src that you had .ZIPped.
> 
> I notice also that there is code in the OEM message loop to support 
> Drag&Drop to some extent, but that also is not in the NEM message loop.

Oh, and accelerator key support isn't in NEM yet--I need that too, 
before I can really use NEM.  Looks like we need maybe one more release 
of code on the bug fix branch, to finish NEM before we start work on 
UEM... right now only OEM is fully functional.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

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

On approximately 3/14/2004 12:12 PM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi All,
>  
>     It's probably time to made a new Win32::GUI release based on 
> Win32-GUI-0_0_665-fix branch.
>     I can create a Win32-GUI-0.0.671 from this branch.
>     Does someone have something to put in this branch before release ?

JUST before release, would this be a good time to run all the code 
through some pretty printer, to unify all the indentation, and remove 
all the TABs (except for TABs that mean up-to-8-spaces, according to the
ASCII definition of TAB)?

>     After, it's probably time to stop working on this branch and start 
> working on next Win32-GUI with new event model implementation.
>  
>     I have made huge work on Win32::GUI this week-end for refactoring 
> Win32::GUI code.
>     I have create a .xs file for each control and try to implement 
> all of SendMessage/Macro control API (not finish).
>  
>     For each CLASS control, i have a XS file with :
>  
>        * First part, define some control callback function  :
>             - xxx_onPreCreate  : this function set defaut style for control
>             - xxx_onParseOption: this function parse specific control option
>             - xxx_onPostCreate : this function handle specific control 
> option property (color,...)
>                 This function is call after Window creation and in 
> Change method too.
>                 We probably need a different name.
>  
>             I think we can extend this concept of callback method for 
> all control and add more function.
>             After, we can replace all Switch(class) by a pFct[class] 
> call where pFct it's an array of pointer function.
>             It's possibly something to use for new event model, create a 
> special callback fonction for handle all event of control. Like this, 
> all code for a control it's in one file.
>  
>        * Second Part, i implement all Control API
>             I use same ordre than MSDN documentation (alphabetic order) 
> and use same name than standard Window API (message name or macro name).
>             I use same name because, i think it's probably easier for 
> find documentation in MSDN .
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/wincontrols.asp 
>  
>             I create ALIAS for keep old Win32::GUI name.
>             For sample, with Textfield, i define GetSel (same name 
> as message name) and define an ALIAS for Selection() method.
>  
>     
> ###########################################################################
>     # (@)METHOD:GetSel()
>     # 
>     # (@)METHOD:Selection()
>     # See GetSel.
>    
> void
> GetSel(handle)
>     HWND handle
> ALIAS:
>     Win32::GUI::Textfield::Selection = 1
> PREINIT:
>     DWORD start;
>     DWORD end;
> PPCODE:
>     SendMessage(handle, EM_GETSEL, (WPARAM) &start, (LPARAM) &end);
>     EXTEND(SP, 2);
>     XST_mIV(0, (long) start);
>     XST_mIV(1, (long) end);
>     XSRETURN(2);
>  
>       * Last Part, containt more high level method for the control.
>  
>     I have keep in GUI.PM only pure perl method.
>  
> You can see a copy of my developpement directory here :
> http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/Win32-GUI.zip
>  
>     I you found this work interesting, we can use it as base code for 
> starting to work on next Win32::GUI implentation.
>     We can use MAIN cvs branch (of Win32-GUI CVS module) for this.
>  
> Cheers,
>  
>     Laurent.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

[Jez W. <je...@je...>]

Hi,

I think it is a good time for a new release - lot of bug fixes and minor
enhancements since the last release.

> I was working on trying to transform the WM_NOTIFYICON code from the
> standard message loop to work in the NEM message loop, and allow
> AddNotifyIcon to take -onClick -onRightClick and -events parameters,
> with the -events allowing Click and RightClick.  Then I noticed
> MousEvent in the default case, I guess we'd need -onMouseEvent for that?

Some other controls suffer from a similar situation. For example the tree
control is missing NEM rightclick and other mouse releated events.

> I haven't really figured out the "correct" data structures for where to
> put the sub refs for -onClick etc. so that they can be found and called
> via DoEvent_NEM... that was what I'd hoped to figure out tomorrow or so.
> Or else to invent a new DoEvent_NEM type function that accepts the sub
> ref as a parameter, and does all the standard Perl interfacing.
> Depending on what I could figure out.  I'd rather not hold anything up,
> but I need NotifyIcon support if I'm going to use NEM.

I had a quick look at the source that Laurent has been working on - it's
much cleaner. One question though - where will code go that handle the
events? It would be nice if there is a relative simple and straightforward
process to add additional events to controls without having to jump through
lots of hoops. There have been several times I have considered adding new
events to controls, only to be confused in the process:)

Cheers,

jez.

Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

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

On approximately 3/14/2004 12:12 PM, came the following characters from
the keyboard of Laurent ROCHER:
> Hi All,
>  
>     It's probably time to made a new Win32::GUI release based on 
> Win32-GUI-0_0_665-fix branch.
>     I can create a Win32-GUI-0.0.671 from this branch.
>     Does someone have something to put in this branch before release ?

I was working on trying to transform the WM_NOTIFYICON code from the 
standard message loop to work in the NEM message loop, and allow 
AddNotifyIcon to take -onClick -onRightClick and -events parameters, 
with the -events allowing Click and RightClick.  Then I noticed 
MousEvent in the default case, I guess we'd need -onMouseEvent for that?

I haven't really figured out the "correct" data structures for where to 
put the sub refs for -onClick etc. so that they can be found and called 
via DoEvent_NEM... that was what I'd hoped to figure out tomorrow or so.
Or else to invent a new DoEvent_NEM type function that accepts the sub 
ref as a parameter, and does all the standard Perl interfacing. 
Depending on what I could figure out.  I'd rather not hold anything up, 
but I need NotifyIcon support if I'm going to use NEM.

This was based off of the last dev src that you had .ZIPped.

I notice also that there is code in the OEM message loop to support 
Drag&Drop to some extent, but that also is not in the NEM message loop.

>     After, it's probably time to stop working on this branch and start 
> working on next Win32-GUI with new event model implementation.
>  
>     I have made huge work on Win32::GUI this week-end for refactoring 
> Win32::GUI code.
>     I have create a .xs file for each control and try to implement 
> all of SendMessage/Macro control API (not finish).
>  
>     For each CLASS control, i have a XS file with :
>  
>        * First part, define some control callback function  :
>             - xxx_onPreCreate  : this function set defaut style for control
>             - xxx_onParseOption: this function parse specific control option
>             - xxx_onPostCreate : this function handle specific control 
> option property (color,...)
>                 This function is call after Window creation and in 
> Change method too.
>                 We probably need a different name.
>  
>             I think we can extend this concept of callback method for 
> all control and add more function.
>             After, we can replace all Switch(class) by a pFct[class] 
> call where pFct it's an array of pointer function.
>             It's possibly something to use for new event model, create a 
> special callback fonction for handle all event of control. Like this, 
> all code for a control it's in one file.
>  
>        * Second Part, i implement all Control API
>             I use same ordre than MSDN documentation (alphabetic order) 
> and use same name than standard Window API (message name or macro name).
>             I use same name because, i think it's probably easier for 
> find documentation in MSDN .
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/wincontrols.asp 
>  
>             I create ALIAS for keep old Win32::GUI name.
>             For sample, with Textfield, i define GetSel (same name 
> as message name) and define an ALIAS for Selection() method.
>  
>     
> ###########################################################################
>     # (@)METHOD:GetSel()
>     # 
>     # (@)METHOD:Selection()
>     # See GetSel.
>    
> void
> GetSel(handle)
>     HWND handle
> ALIAS:
>     Win32::GUI::Textfield::Selection = 1
> PREINIT:
>     DWORD start;
>     DWORD end;
> PPCODE:
>     SendMessage(handle, EM_GETSEL, (WPARAM) &start, (LPARAM) &end);
>     EXTEND(SP, 2);
>     XST_mIV(0, (long) start);
>     XST_mIV(1, (long) end);
>     XSRETURN(2);
>  
>       * Last Part, containt more high level method for the control.
>  
>     I have keep in GUI.PM only pure perl method.
>  
> You can see a copy of my developpement directory here :
> http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/Win32-GUI.zip
>  
>     I you found this work interesting, we can use it as base code for 
> starting to work on next Win32::GUI implentation.
>     We can use MAIN cvs branch (of Win32-GUI CVS module) for this.
>  
> Cheers,
>  
>     Laurent.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

[perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation

[Laurent R. <ro...@cl...>]

Hi All,

    It's probably time to made a new Win32::GUI release based on =
Win32-GUI-0_0_665-fix branch.
    I can create a Win32-GUI-0.0.671 from this branch.
    Does someone have something to put in this branch before release ?

    After, it's probably time to stop working on this branch and start =
working on next Win32-GUI with new event model implementation.

    I have made huge work on Win32::GUI this week-end for refactoring =
Win32::GUI code.
    I have create a .xs file for each control and try to implement all =
of SendMessage/Macro control API (not finish).

    For each CLASS control, i have a XS file with :

       * First part, define some control callback function  :
            - xxx_onPreCreate  : this function set defaut style for =
control=20
            - xxx_onParseOption: this function parse specific control =
option
            - xxx_onPostCreate : this function handle specific control =
option property (color,...)
                This function is call after Window creation and in =
Change method too.
                We probably need a different name.

            I think we can extend this concept of callback method for =
all control and add more function.
            After, we can replace all Switch(class) by a pFct[class] =
call where pFct it's an array of pointer function.
            It's possibly something to use for new event model, create a =
special callback fonction for handle all event of control. Like this, =
all code for a control it's in one file.=20

       * Second Part, i implement all Control API
            I use same ordre than MSDN documentation (alphabetic order) =
and use same name than standard Window API (message name or macro name).
            I use same name because, i think it's probably easier for =
find documentation in MSDN .
http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/shellc=
c/platform/commctls/wincontrols.asp=20

            I create ALIAS for keep old Win32::GUI name.
            For sample, with Textfield, i define GetSel (same name as =
message name) and define an ALIAS for Selection() method.

    =
#########################################################################=
##
    # (@)METHOD:GetSel()
    # =20
    # (@)METHOD:Selection()
    # See GetSel.
   =20
void
GetSel(handle)
    HWND handle
ALIAS:
    Win32::GUI::Textfield::Selection =3D 1
PREINIT:
    DWORD start;
    DWORD end;
PPCODE:
    SendMessage(handle, EM_GETSEL, (WPARAM) &start, (LPARAM) &end);
    EXTEND(SP, 2);
    XST_mIV(0, (long) start);
    XST_mIV(1, (long) end);
    XSRETURN(2);

      * Last Part, containt more high level method for the control.

    I have keep in GUI.PM only pure perl method.

You can see a copy of my developpement directory here :
http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/Win32-GUI.zip

    I you found this work interesting, we can use it as base code for =
starting to work on next Win32::GUI implentation.
    We can use MAIN cvs branch (of Win32-GUI CVS module) for this.

Cheers,

    Laurent.

[perl-win32-gui-hackers] NotifyIcon vs NEM

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

Hi,

I can't find any code that processes NotifyIcon Clicks, except in the 
OEM Message Loop.  Are NotifyIcons not supported via NEM?  Or where did 
I miss it?

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

[perl-win32-gui-hackers] Changes to Win32-GUI-0_0_665-Fix

[Jez W. <je...@je...>]

Hi,

I've just committed a couple of changes:

 * Added the method GetIcon for the Imagelist control
 * Added the style option for individual rebar bands

Hopefully I've checked them in correctly:)

Cheers,

jez.

[perl-win32-gui-hackers] Win32::GUI Dev PPM

[Laurent R. <ro...@cl...>]

Hi All,

I have made new PPM build from Sourceforge Win32::GUI CVS.

I build it from my local dev directory with last CVS source (8/03/2004).

I have made 5.6 and 5.8 PPM and a source zip file from my dev directory.

See : http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/index.html


Laurent

Re: [perl-win32-gui-hackers] Menus and NEM

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

On approximately 2/24/2004 6:19 AM, came the following characters from
the keyboard of Stephen Pick:

> Hello,
> 
>>Steve, do you agree that it adds all the functionality of hooks?
> 
> 
> It does seem to, depending on what event_map actually is. If a user
> could add events to the event map that werent already there, something
> like:
> 
> Win32::GUI::RegisterEvent(0x14,"EraseBackground");
> 
> Then it would implement *some* of the functionality of hooks. The
> primary thing about the hooks that I thought was a good benefit was the
> ability to register several handlers per event. 

Interesting.  It is nice to have multiple perspectives on the issue, 
thanks for responding.

So I agree multiple handlers per event can be useful.  In fact, my 
"fetch old handler / encapsulate / set new handler that calls old 
handler" sequence could possibly be done via multiple handlers. 
Ordering of handlers could be an issue, however... performance wise, if 
things are done in the wrong order, some things may have to be redone, 
and that can be an additional cause of strange flicker on the screen.

It would seem that if, when adding a hook, one could specify "first", 
with the default being "last", that most programs could be coded in a 
way that would allow things to be done in the best order.

If the underlying data structures support multiple handlers, then all of 
OEM, NEM, and HEM could be implemented in terms of UEM.  For OEM, one 
would scan the symbol table, and eval a wrapper to convert the parameter 
list.  For NEM, the handlers are passed in at window creation time, and 
one would eval a wrapper to convert the parameter list.  For HEM, a 
handler is passed in via a window object method, and one would eval a 
wrapper to convert the parameter list.  For UEM, the handlers could be 
passed in at window creation time, or later via a window object method, 
and no wrappers would be necessary.

This provides:
(1) immediate compatibility, except for late eval'd handlers in OEM [but 
see (3d)]
(2) A single mechanism for dispatching handlers.
(3) a clear migration path for each existing model
(3a) OEM migration: alter handlers to expect new parameters, change 
their names, and pass them in when creating the window.
(3b) NEM migration: alter handlers to expect new parameters, and change 
the "-onClick" type syntax to "-whenClick" type syntax (or whatever 
syntax the UEM model uses, to be differentiated from NEM).
(3c) HEM migration: alter handlers to expect new parameters, and call a 
differently named method to install the handler, to differentiate HEM 
and UEM handlers.
(3d) Although compatibility for late eval'd handlers in OEM isn't 
available, there is a clear migration path for them: convert them into 
HEM or UEM handlers that are later installed via a method on the window 
object.


Performance is hopefully obtained in the normal cases by using the 
default handlers as much as possible; and by having a mechanism for 
supporting C-written handlers for folks that really really need a 
handler on a high-frequency event, that would bypass the C/Perl/C 
calling techniques.  Rules for writing C handlers and parameter access 
techniques for C handlers must be defined, of course, as well as the 
mechanism for registering a C handler.


> The other points are good, but i've got a small issue with
> documentation:
> 
> Having used the documentation system currently within Win32::GUI's
> source, i found it straightforward and simple to understand, quick to
> write and easilly convertable. What I'd like to see is a few
> improvements to the parser:
> 
> 1. Support for a marker of some kind that indicates that the text should
> be monospaced
> 2. Wiki-compatible output would be great. This isn't difficult. What I
> mean is, a straight block of text that can be pasted right into a wiki
> input form. I think we *need* a wiki because docs are no good lurking in
> the source where users can't see them or update them.

If the documentation is in the source, the wiki user can't update it. 
If the documentation is in the wiki, the programmer won't likely update 
it, because it won't be seen, unless he happens to remember that that is 
documented somewhere, and goes and finds it.

Maybe we need to have some documentation sourced from each place. 
Documentation for the actual interfaces provided by Win32::GUI should 
probably be in the source, and be published to HTML and Wiki.

Examples of use could maybe be separate, but should be "version stamped" 
so that it is clear what version of Win32::GUI the example applied to. 
Can the Wiki force users to supply a (valid) Win32::GUI version number 
with each documentation update?  We have to trust them to supply the 
correct one, of course, and we have to allow changes if they goof, but 
then if documentation isn't updated, at least users would know that it 
is old, and might no longer work, if interfaces have been updated.

> 3. Better support for documenting events, especially with the UEM coming
> up.

It'd be good to cross reference to MSDN, except that MS is notorious for 
changing the links to their web sites.

> 4. Bugfix and standardize the "see also xxx" parsing. Perhaps have
> automatic See Also parsing which makes any word that is a win32::gui
> method or event name a link to docs on that thing.
> 
> Those would all be pretty easy to do, and I'm happy with fixing up the
> documentation tools if nobody else can be bothered. The ability to
> generate POD, HTML and TXT outputs is very handy.
> 
> Glenn's other points are well made. I like the idea of checking the
> symbol table and resolving OEM events on startup. This would certainly
> make things a good deal faster, not that I really notice the slow speed
> of events right at the moment (and hell, I use hooks, which are
> incredibly slow).

And why are they slow?  Is it because of the C/Perl transition, and the 
hooking of high-frequency events?  Or some other reason?  My thoughts 
above are now suggesting using a derivative of HEM as the basis for UEM.

If it is some other reason, can the performance be improved?

> I mentioned Unicode support because it's been asked for a few times on
> the sf bug tracker. Personally I don't need it, but like I said it would
> be good to support this. I have noticed that in windows 2000 labels,
> buttons etc support Japanese characters under Win32::GUI provided that
> your OS language is set to Japanese (_that_ was a disorienting few hours
> (no pun intended :/)...). This is true of XP as well.

I'd like to see Unicode support.  It allows support of multiple 
languages concurrently, with is the nirvana for multi-lingual programs.

> 
> Steve
> 
> 
> 
>>-----Original Message-----
>>From: Glenn Linderman [mailto:pe...@ne...]
>>Sent: 24 February 2004 02:50
>>To: Aldo Calpini
>>Cc: Stephen Pick; Win32 GUI Hackers (E-mail); Jez White (E-mail)
>>Subject: Re: [perl-win32-gui-hackers] Menus and NEM
>>
>>
>>On approximately 2/20/2004 8:17 AM, came the following characters from
>>the keyboard of Aldo Calpini:
>>
>>>hello people :-)
>>>
>>>On Mon, 2004-02-16 at 13:53, Stephen Pick wrote:
>>>
>>>
>>>>Hello,
>>>>
>>>>Looks like menus are indeed a little busted. You can't use both 
>>>>event models on a menu. You can use either the NEM or the OEM, but 
>>>>you can't selectively use NEM here and OEM there. If you add a menu
>>>>to a window that is using the NEM and your window uses OEM, 
>>
>>your menu
>>
>>>>won't work. Your menu's event model must match that of the window 
>>>>you're adding it into.
>>>
>>>
>>>as I said a lot of time ago, the current OEM/NEM interoperability
>>>implementation is going to die. there's too much broken 
>>
>>code in there,
>>
>>>and I thought of a way to simplify things a lot (but they will be
>>>managed a little bit differently).
>>>
>>>the last time I wrote here, I promised a document describing the new
>>>architecture that I'm going to implement, but in the mean 
>>
>>time a damn
>>
>>>stupid 120 GB external USB HD ate my development directory. 
>>
>>more than 1
>>
>>>GB of stuff, more than 6 years of development, sigh :-(
>>>
>>>so, the whole thing exists only in my mind now.
>>>
>>>basically, the idea is the following: there will be a 
>>
>>single messageloop
>>
>>>for each window (including controls), which, in pseudocode, 
>>
>>should do
>>
>>>something like this:
>>>
>>>  if(event_model & BYREF) {
>>>        if(window->eventmap(event_id)) {
>>>            event = window->events{get_event_name(event_id)};
>>>            fire_event(event);
>>>        }
>>>  }
>>>  if(event_model & BYNAME) {
>>>       event_name = window->name . "_" . get_event_name(event_id);
>>>       if(event = perl_get_cv(event_name)) {
>>>           fire_event(event);
>>>       }
>>>  }
>>>
>>>the biggest implication is that the OEM (BYNAME event model) will
>>>probably result a little bit slower: that's because each 
>>
>>message to each
>>
>>>control will trigger a perl_get_cv call (which is orders of 
>>
>>magnitude
>>
>>>slower than a C instruction). on the other hand, every 
>>
>>control will have
>>
>>>the whole range of events (eg. MouseMove, MouseClick, etc.) 
>>
>>enabled by
>>
>>>default. 
>>>
>>>event_model in the code above is a global variable in C 
>>
>>which will be
>>
>>>controlled by a method (Win32::GUI::SetEventModel or something like
>>>that) or by a directive in use (eg. use Win32::GUI EventModel =>
>>>'BYREF').
>>
>>This does sound like it would unify the event models, and add all the 
>>functionality Steve has added via the hooks.  Steve, do you 
>>agree that 
>>it adds all the functionality of hooks?  I've not yet played 
>>with them 
>>to be 100% sure.
>>
>>One could, however, provide a very simple migration path from 
>>slow OEM 
>>performance to fast OEM performance, with one restriction:  
>>If the OEM 
>>functions are required to exist at the time a window is 
>>created, then at 
>>window creation time, the namespace could be searched for the 
>>names of 
>>event functions, and they could be collected into the same data 
>>structures that are used by NEM.
>>
>>This would eliminate a dynamic performance penalty of OEM, at 
>>the cost 
>>of a creation time performance penalty for OEM.  It would 
>>eliminate any 
>>need to record, for each window, whether it uses OEM or NEM.
>>
>>Actually, users could almost perform the OEM->NEM conversion just by 
>>adding the appropriate event names pointing at their old OEM 
>>functions... Except, if the calling convention for the OEM 
>>functions and 
>>NEM functions vary, then they couldn't be used 
>>interchangably.  And that 
>>seems to be part of the design for compatibility... but maybe that is 
>>solvable somehow?  With the "automatic" migration, a simple wrapper 
>>function could be interposed between the NEM calling function 
>>parameters, and the OEM calling function parameters, which 
>>would still 
>>likely be faster than doing all the perl_get_cv's at 
>>run-time?  This is 
>>discussed more under "Re: parameter passing" below...
>>
>>
>>>I'm a little (oh, well, a little is not enough :-) behind with the
>>>situation on CVS, but I'm ready to implement this 
>>
>>architectural change. 
>>
>>>should we branch the CVS repository (or create a new module, which
>>>sounds better to me) or is the current status quiet enough to begin
>>>working on this for the next release?
>>
>>Well, the CVS repository is already branched, bugfix vs development. 
>>However, it would be a shame to lose all the bugfix work, if you are 
>>ready to start implementing afresh.
>>
>>I would suggest that a cooperative approach would be for you 
>>to review 
>>the major code changes, and either accept them, or discuss 
>>them in this 
>>forum, until some consensus can be reached.
>>
>>We should do a release of what we have so far, subject to discussions 
>>started by the last paragraph, before starting another major 
>>initiative. 
>>  And if you wouldn't mind starting from the current bug-fix 
>>branch code 
>>(after the release), then the next release point could be merged back 
>>into the main branch, and you could do your upward-compatible 
>>development there.  Bug fixing could continue on the bug fix 
>>branch, and 
>>you could pick up the bug fixes from time to time in the main 
>>branch, so 
>>there wouldn't be a major synchronization issue later.
>>
>>It sounds to me like the hooks will become somewhat redundant 
>>as a way 
>>of capturing messages, but I doubt that they are seriously 
>>difficult to 
>>support in deprecated mode, even if they are redundant.
>>
>>It is important to me that you retain the ability to set and fetch 
>>pointers to the functions that get invoked for messages, which Steve 
>>only recently added to the NEM.
>>
>>
>>I'll comment on a few of the other threads of discussion, but won't 
>>reproduce them here.
>>
>>Re: context: yes, it would be nice to be able to invoke GUI functions 
>>from any thread, and even have "fake-forked" programs be able to have 
>>independent windows, if that is straightforward.
>>
>>Re: DESTROY: of course it would be nice, but except for 
>>really dynamic 
>>programs, not all that necessary.  In other words, not the 
>>highest priority.
>>
>>Re: VB-likeness.  Not important to me in the least.  Useful 
>>and usable 
>>are much more important.  VB isn't really very object 
>>oriented; we can 
>>be much more so in Perl.
>>
>>Re: PEM.  No comment, until we hear more.
>>
>>Re: Refactoring code: Certainly improvements could and should 
>>be made to 
>>the structure of the code.
>>
>>Re: Unicode, I think you understand the main difficulty, UCS2-LE (I'm 
>>not sure what the -LE means, though) vs UTF-8.  But there should be 
>>samples of such conversions inside the Perl core (Windows port).
>>
>>Re: parameter passing: Passing the object as a first 
>>parameter to each 
>>of the event handling functions is an excellant idea.  As 
>>well as all of 
>>the numbers fromthe event message itself.  We need to allow a 
>>Win32::GUI 
>>program all the power of the C program.  There is a 
>>compatibility issue 
>>here.  Neither the OEM nor NEM models pass such a parameter 
>>at present. 
>>  So we can either figure out ways of passing the parameter 
>>that isn't 
>>"clean", but is compatible, and new or modified functions can 
>>access the 
>>appropriate object, or we need to define UEM (unified event 
>>model) which 
>>has the object, and can provide compatible interfaces for 
>>existing OEM 
>>and NEM functions.  I think the latter is relatively straightforword: 
>>the UEM provides a new interface for UEM-aware functions, and 
>>provides 
>>the old interfaces for NEM-aware functions (and a 
>>compatibility layer to 
>>call that code, and convert the parameters), and converts 
>>pre-existing 
>>OEM functions to NEM functions (with the same, or perhaps with a 
>>slightly different compatibility layer).  The only thing
>>
>>Re: performance: we won't want to see a C/Perl transition on 
>>EVERY mouse 
>>move, for performance reasons.  Perhaps we need to define a clean way 
>>for defining UEM functions in either Perl, or C?  And if the 
>>function is 
>>defined in C, there needs to be a way to call it from C 
>>without hopping 
>>through Perl.  But there also needs to be a way of calling it 
>>from Perl, 
>>in case it is overridden by Perl code, that wants to augment the 
>>previous function by doing something, calling the previous function, 
>>doing some more, and then returning.  This could be a bit 
>>tricky.  Maybe 
>>it can be defined away somehow, but the ability to override 
>>and augment 
>>the existing functions is important for me.  But I'm not sure 
>>it is all 
>>that important for the functions which need speed.  So if 
>>there is not a 
>>universal way to do this, perhaps some restrictions on what functions 
>>may and may not be defined using C is OK.
>>
>>Re: documentation:  What this project doesn't need, is any more 
>>undocumented capabilities.  The greatest feature in the world 
>>is totally 
>>useless if no one can figure it out.  And there are lots of great 
>>features in Win32::GUI that very few people could figure out.  Having 
>>all the documentation on sourceforge would help.  And maybe 
>>wiki's are 
>>the next greatest thing, but the use of too many different types of 
>>technology can prevent a steep learning curve for potential 
>>contributors.  Erick's existing Win32::GUI Documentation 
>>project suffers 
>>from the inability of contributers to figure out how to 
>>contribute, even 
>>with help from Erick.  No doubt the system works for Erick, but it's 
>>visual cues aren't consistent with the selected operations I 
>>attempted, 
>>so it continually convinced me that it wasn't doing what I 
>>asked it to 
>>do, before I got far enough to actually do anything.  Calling 
>>this new 
>>wiki the "Win32::GUI Documentation Project" is somewhat confusing in 
>>light of Erick's existing project.  I think it should be called 
>>something else.  I'm also not sure that it should be a wiki, 
>>vs simply a 
>>collection of CVS controlled POD files, but feel free to 
>>convince me or 
>>ignore me, but I would like some insight as to what made you 
>>choose to 
>>create a wiki.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

[perl-win32-gui-hackers] New GetIcon method for ImageList.xs

[Jez W. <je...@je...>]

Hi,

I'm trying to create a new method, GetIcon for an image list.=20

http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/shellc=
c/platform/commctls/imagelist/functions/imagelist_geticon.asp

It's quite a handy method, the way I'm using it is to populate the =
status bar with a icon, straight from an imagelist.

I've got a version working, but I'm not sure if it's up to "standard"?

Cheers,

jez.

What I've got so far:

ImageList.xs

    =
#########################################################################=
##
    # (@)METHOD:_GetIcon(index, [flags])
int
_GetIcon(handle, index, flags)
    HIMAGELIST handle
    int index
    UINT flags
CODE:
    RETVAL =3D (LONG) ImageList_GetIcon(handle, index, flags);
OUTPUT:
    RETVAL

GUI.pm

sub GetIcon {
  my ($self,$id,$flags)=3D@_;
  my $handle=3D$self->_GetIcon($id,$flags);
  if ($handle) {
    my $icon;
    $icon->{-handle} =3D $handle;
    bless($icon,'Win32::GUI::Icon');
    return $icon;
  }
  return undef;
  }

[perl-win32-gui-hackers] A minor change to rebar.xs

[Jez W. <je...@je...>]

Hi,

I would be grateful if someone could commit this change to the =
InsertBand method of a rebar control. I've added the option "-style".

Cheers,

jez.

    =
#########################################################################=
##
    # (@)METHOD:InsertBand(%OPTIONS)
    #
    # Insert a new band into the rebar control.
    #
    # Allowed %OPTIONS are:
    #
    # -image      =3D> Zero based index of the imagelist.
    # -index      =3D> Zero based index where the band is inserted.
    # -bitmap     =3D> The background bitmap for the band.
    # -child      =3D> Child control. See Below.
    # -foreground =3D> Band foreground colors.
    # -background =3D> Band background colors.
    # -width      =3D> The width of the band.
    # -minwidth   =3D> The minimum width of the band.
    # -minheight  =3D> The minimum height of the band.
    # -text       =3D> The text for the band.
    # -style      =3D> The style of the band. See Below
    #
    # Each band can only contain one child control. However, you can add =
a child window that contains many controls:
    #
    #  $mainwindow =3D <main window code>
    #
    #  my $band =3D new Win32::GUI::Window (
    #      -parent   =3D> $mainwindow,
    #      -name     =3D> "RebarBand1",
    #      -popstyle =3D> WS_CAPTION | WS_SIZEBOX,
    #      -pushstyle =3D> WS_CHILD,
    #  );
    #
    #  # create Date time control for band 1
    #  my $DateTime =3D $band->AddDateTime (
    #      -name     =3D> "DateTime",
    #      -pos      =3D> [0, 0],
    #      -size     =3D> [130, 20],
    #      -tip      =3D> 'A date and time',
    #  );
    #  #set the format for the datetime control
    #  $DateTime->Format('dd-MMM-yyyy HH:mm:ss');
    #
    #  #Add a button to band 1
    #  $band->AddButton (
    #           -name     =3D> 'Button',
    #           -pos      =3D> [135, 0],
    #           -size     =3D> [50, 20],
    #           -text     =3D> 'Button',
    #           -tip      =3D> 'A Button',
    #           -onClick =3D> sub {print 'button clicked' },
    #  );
    #
    # my $rebar =3D $mainwindow->AddRebar(
    #      -name   =3D> "Rebar",
    #      -bandborders =3D> 1,
    #  );
    #
    #  #Insert band
    #  $rebar->InsertBand ( =20
    #    -child     =3D> $band,
    #    -width     =3D> 210,
    #    -minwidth  =3D> 210,
    #    -minheight =3D> 20,
    #  );
    #
    # Styles
    #
    # Each band can have it's own style. As a default, each band has =
RBBS_CHILDEDGE | RBBS_FIXEDBMP
    # RBBS_BREAK 1 The band is on a new line.
    # RBBS_FIXEDSIZE 2 The band can't be sized. With this style, the =
sizing grip is not displayed on the band.
    # RBBS_CHILDEDGE 4 The band has an edge at the top and bottom of the =
child window.
    # RBBS_HIDDEN 8 The band will not be visible.
    # RBBS_FIXEDBMP 32 The background bitmap does not move when the band =
is resized.
    # RBBS_VARIABLEHEIGHT 64 The band can be resized by the rebar =
control.
    # RBBS_GRIPPERALWAYS 128 The band will always have a sizing grip, =
even if it is the only band in the rebar.
    # RBBS_NOGRIPPER 256 The band will never have a sizing grip, even if =
there is more than one band in the rebar.
    #
LRESULT
InsertBand(handle,...)
    HWND handle
PREINIT:
    REBARBANDINFO rbbi;
    int i, next_i;
    UINT index;
CODE:
    ZeroMemory(&rbbi, sizeof(REBARBANDINFO));
    rbbi.cbSize =3D sizeof(REBARBANDINFO);
    rbbi.fStyle =3D RBBS_CHILDEDGE | RBBS_FIXEDBMP;
    SwitchBit(rbbi.fMask, RBBIM_STYLE, 1);
    index =3D (UINT) -1;
    next_i =3D -1;
    for(i =3D 1; i < items; i++) {
        if(next_i =3D=3D -1) {
            if(strcmp(SvPV_nolen(ST(i)), "-image") =3D=3D 0) {
                next_i =3D i + 1;
                rbbi.iImage =3D SvIV(ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_IMAGE, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-index") =3D=3D 0) {
                next_i =3D i + 1;
                index =3D (UINT) SvIV(ST(next_i));
            } else if(strcmp(SvPV_nolen(ST(i)), "-bitmap") =3D=3D 0) {
                next_i =3D i + 1;
                rbbi.hbmBack =3D (HBITMAP) handle_From(NOTXSCALL =
ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_BACKGROUND, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-child") =3D=3D 0) {
                next_i =3D i + 1;
                rbbi.hwndChild =3D (HWND) handle_From(NOTXSCALL =
ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_CHILD, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-foreground") =3D=3D 0) =
{
                next_i =3D i + 1;
                rbbi.clrFore =3D SvCOLORREF(NOTXSCALL ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_COLORS, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-background") =3D=3D 0) =
{
                next_i =3D i + 1;
                rbbi.clrBack =3D SvCOLORREF(NOTXSCALL ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_COLORS, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-width") =3D=3D 0) {
                next_i =3D i + 1;
                rbbi.cx =3D SvIV(ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_SIZE, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-minwidth") =3D=3D 0) {
                next_i =3D i + 1;
                rbbi.cxMinChild =3D SvIV(ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_CHILDSIZE, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-minheight") =3D=3D 0) =
{
                next_i =3D i + 1;
                rbbi.cyMinChild =3D SvIV(ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_CHILDSIZE, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-text") =3D=3D 0) {
                next_i =3D i + 1;
                rbbi.lpText =3D SvPV_nolen(ST(next_i));
                SwitchBit(rbbi.fMask, RBBIM_TEXT, 1);
            } else if(strcmp(SvPV_nolen(ST(i)), "-style") =3D=3D 0) {
                next_i =3D i + 1;
                rbbi.fStyle =3D SvIV(ST(next_i));
            }
        } else {
            next_i =3D -1;
        }
    }
    RETVAL =3D SendMessage(handle, RB_INSERTBAND, (WPARAM) index, =
(LPARAM) &rbbi);
OUTPUT:
    RETVAL

[perl-win32-gui-hackers] wiki's

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

Stephen Pick schrieb:
> 2. Wiki-compatible output would be great. This isn't difficult. What I
> mean is, a straight block of text that can be pasted right into a wiki
> input form. I think we *need* a wiki because docs are no good lurking in
> the source where users can't see them or update them.

You mean RTF->wiki format converter? Or a HTML->wiki format converter?

I'm just working on the new PhpWiki and tried out the new htmlarea3 
(cross-browser WYSIWYG richedit-like textarea replacement, in straight 
jscript)
There we had the same problem of HTML->Wiki conversion, which is NOT 
that easy.

I would advise to use the simpiest of all wiki's guiki, which uses plain 
HTML, but looks best and is easiest. This uses htmlarea3.
I also proposed guiki for the official phpnuke and postnuke wiki module. 
It's just one very short php file, sorry no perl :), but a nobrainer to 
install and use.

http://www.guiki.com/
http://www.interactivetools.com/products/htmlarea/
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [perl-win32-gui-hackers] Menus and NEM

[Stephen P. <Ste...@uc...>]

Hello,

> Steve, do you agree that it adds all the functionality of hooks?

It does seem to, depending on what event_map actually is. If a user
could add events to the event map that werent already there, something
like:

Win32::GUI::RegisterEvent(0x14,"EraseBackground");

Then it would implement *some* of the functionality of hooks. The
primary thing about the hooks that I thought was a good benefit was the
ability to register several handlers per event. Say someone wrote a perl
module that extended the RichEdit control so that all text was
syntax-hilighted. For ease of use the perl module would either need to
create its own RichEdit control or be passed one to work with. The
module may need to handle events from the RichEdit control
transparently, while still allowing the user's script to register event
handlers and work with the RichEdit control normally.

With hooks, this is easy. The author of the RichEdit syntax-hilight
module simply Hook()s the messages that need to be captured. Since the
hooks system lets you add as many event handlers per message ID as you
like (the handler coderefs are simply stored in a big array and called
in sequence), the user can still Hook() the same messages, or use the
NEM or OEM to capture the same messages without breaking the RichEdit
Syntax Hilight module functionality. Hooks are also removable. You can
remove hooks by passing the coderef of the handler you want to remove to
UnHook().

I'm not sure if the proposed model would let you do things like this.
The system for Hooks is kinda messy and a bit of a bolt-on, but it's
quite useful.

The other points are good, but i've got a small issue with
documentation:

Having used the documentation system currently within Win32::GUI's
source, i found it straightforward and simple to understand, quick to
write and easilly convertable. What I'd like to see is a few
improvements to the parser:

1. Support for a marker of some kind that indicates that the text should
be monospaced
2. Wiki-compatible output would be great. This isn't difficult. What I
mean is, a straight block of text that can be pasted right into a wiki
input form. I think we *need* a wiki because docs are no good lurking in
the source where users can't see them or update them.
3. Better support for documenting events, especially with the UEM coming
up.
4. Bugfix and standardize the "see also xxx" parsing. Perhaps have
automatic See Also parsing which makes any word that is a win32::gui
method or event name a link to docs on that thing.

Those would all be pretty easy to do, and I'm happy with fixing up the
documentation tools if nobody else can be bothered. The ability to
generate POD, HTML and TXT outputs is very handy.

Glenn's other points are well made. I like the idea of checking the
symbol table and resolving OEM events on startup. This would certainly
make things a good deal faster, not that I really notice the slow speed
of events right at the moment (and hell, I use hooks, which are
incredibly slow).

I mentioned Unicode support because it's been asked for a few times on
the sf bug tracker. Personally I don't need it, but like I said it would
be good to support this. I have noticed that in windows 2000 labels,
buttons etc support Japanese characters under Win32::GUI provided that
your OS language is set to Japanese (_that_ was a disorienting few hours
(no pun intended :/)...). This is true of XP as well.

Steve


> -----Original Message-----
> From: Glenn Linderman [mailto:pe...@ne...]
> Sent: 24 February 2004 02:50
> To: Aldo Calpini
> Cc: Stephen Pick; Win32 GUI Hackers (E-mail); Jez White (E-mail)
> Subject: Re: [perl-win32-gui-hackers] Menus and NEM
>=20
>=20
> On approximately 2/20/2004 8:17 AM, came the following characters from
> the keyboard of Aldo Calpini:
> > hello people :-)
> >=20
> > On Mon, 2004-02-16 at 13:53, Stephen Pick wrote:
> >=20
> >>Hello,
> >>
> >>Looks like menus are indeed a little busted. You can't use both=20
> >>event models on a menu. You can use either the NEM or the OEM, but=20
> >>you can't selectively use NEM here and OEM there. If you add a menu
> >>to a window that is using the NEM and your window uses OEM,=20
> your menu
> >>won't work. Your menu's event model must match that of the window=20
> >>you're adding it into.
> >=20
> >=20
> > as I said a lot of time ago, the current OEM/NEM interoperability
> > implementation is going to die. there's too much broken=20
> code in there,
> > and I thought of a way to simplify things a lot (but they will be
> > managed a little bit differently).
> >=20
> > the last time I wrote here, I promised a document describing the new
> > architecture that I'm going to implement, but in the mean=20
> time a damn
> > stupid 120 GB external USB HD ate my development directory.=20
> more than 1
> > GB of stuff, more than 6 years of development, sigh :-(
> >=20
> > so, the whole thing exists only in my mind now.
> >=20
> > basically, the idea is the following: there will be a=20
> single messageloop
> > for each window (including controls), which, in pseudocode,=20
> should do
> > something like this:
> >=20
> >   if(event_model & BYREF) {
> >         if(window->eventmap(event_id)) {
> >             event =3D window->events{get_event_name(event_id)};
> >             fire_event(event);
> >         }
> >   }
> >   if(event_model & BYNAME) {
> >        event_name =3D window->name . "_" . get_event_name(event_id);
> >        if(event =3D perl_get_cv(event_name)) {
> >            fire_event(event);
> >        }
> >   }
> >=20
> > the biggest implication is that the OEM (BYNAME event model) will
> > probably result a little bit slower: that's because each=20
> message to each
> > control will trigger a perl_get_cv call (which is orders of=20
> magnitude
> > slower than a C instruction). on the other hand, every=20
> control will have
> > the whole range of events (eg. MouseMove, MouseClick, etc.)=20
> enabled by
> > default.=20
> >=20
> > event_model in the code above is a global variable in C=20
> which will be
> > controlled by a method (Win32::GUI::SetEventModel or something like
> > that) or by a directive in use (eg. use Win32::GUI EventModel =3D>
> > 'BYREF').
>=20
> This does sound like it would unify the event models, and add all the=20
> functionality Steve has added via the hooks.  Steve, do you=20
> agree that=20
> it adds all the functionality of hooks?  I've not yet played=20
> with them=20
> to be 100% sure.
>=20
> One could, however, provide a very simple migration path from=20
> slow OEM=20
> performance to fast OEM performance, with one restriction: =20
> If the OEM=20
> functions are required to exist at the time a window is=20
> created, then at=20
> window creation time, the namespace could be searched for the=20
> names of=20
> event functions, and they could be collected into the same data=20
> structures that are used by NEM.
>=20
> This would eliminate a dynamic performance penalty of OEM, at=20
> the cost=20
> of a creation time performance penalty for OEM.  It would=20
> eliminate any=20
> need to record, for each window, whether it uses OEM or NEM.
>=20
> Actually, users could almost perform the OEM->NEM conversion just by=20
> adding the appropriate event names pointing at their old OEM=20
> functions... Except, if the calling convention for the OEM=20
> functions and=20
> NEM functions vary, then they couldn't be used=20
> interchangably.  And that=20
> seems to be part of the design for compatibility... but maybe that is=20
> solvable somehow?  With the "automatic" migration, a simple wrapper=20
> function could be interposed between the NEM calling function=20
> parameters, and the OEM calling function parameters, which=20
> would still=20
> likely be faster than doing all the perl_get_cv's at=20
> run-time?  This is=20
> discussed more under "Re: parameter passing" below...
>=20
> > I'm a little (oh, well, a little is not enough :-) behind with the
> > situation on CVS, but I'm ready to implement this=20
> architectural change.=20
> >=20
> > should we branch the CVS repository (or create a new module, which
> > sounds better to me) or is the current status quiet enough to begin
> > working on this for the next release?
>=20
> Well, the CVS repository is already branched, bugfix vs development.=20
> However, it would be a shame to lose all the bugfix work, if you are=20
> ready to start implementing afresh.
>=20
> I would suggest that a cooperative approach would be for you=20
> to review=20
> the major code changes, and either accept them, or discuss=20
> them in this=20
> forum, until some consensus can be reached.
>=20
> We should do a release of what we have so far, subject to discussions=20
> started by the last paragraph, before starting another major=20
> initiative.=20
>   And if you wouldn't mind starting from the current bug-fix=20
> branch code=20
> (after the release), then the next release point could be merged back=20
> into the main branch, and you could do your upward-compatible=20
> development there.  Bug fixing could continue on the bug fix=20
> branch, and=20
> you could pick up the bug fixes from time to time in the main=20
> branch, so=20
> there wouldn't be a major synchronization issue later.
>=20
> It sounds to me like the hooks will become somewhat redundant=20
> as a way=20
> of capturing messages, but I doubt that they are seriously=20
> difficult to=20
> support in deprecated mode, even if they are redundant.
>=20
> It is important to me that you retain the ability to set and fetch=20
> pointers to the functions that get invoked for messages, which Steve=20
> only recently added to the NEM.
>=20
>=20
> I'll comment on a few of the other threads of discussion, but won't=20
> reproduce them here.
>=20
> Re: context: yes, it would be nice to be able to invoke GUI functions=20
> from any thread, and even have "fake-forked" programs be able to have=20
> independent windows, if that is straightforward.
>=20
> Re: DESTROY: of course it would be nice, but except for=20
> really dynamic=20
> programs, not all that necessary.  In other words, not the=20
> highest priority.
>=20
> Re: VB-likeness.  Not important to me in the least.  Useful=20
> and usable=20
> are much more important.  VB isn't really very object=20
> oriented; we can=20
> be much more so in Perl.
>=20
> Re: PEM.  No comment, until we hear more.
>=20
> Re: Refactoring code: Certainly improvements could and should=20
> be made to=20
> the structure of the code.
>=20
> Re: Unicode, I think you understand the main difficulty, UCS2-LE (I'm=20
> not sure what the -LE means, though) vs UTF-8.  But there should be=20
> samples of such conversions inside the Perl core (Windows port).
>=20
> Re: parameter passing: Passing the object as a first=20
> parameter to each=20
> of the event handling functions is an excellant idea.  As=20
> well as all of=20
> the numbers fromthe event message itself.  We need to allow a=20
> Win32::GUI=20
> program all the power of the C program.  There is a=20
> compatibility issue=20
> here.  Neither the OEM nor NEM models pass such a parameter=20
> at present.=20
>   So we can either figure out ways of passing the parameter=20
> that isn't=20
> "clean", but is compatible, and new or modified functions can=20
> access the=20
> appropriate object, or we need to define UEM (unified event=20
> model) which=20
> has the object, and can provide compatible interfaces for=20
> existing OEM=20
> and NEM functions.  I think the latter is relatively straightforword:=20
> the UEM provides a new interface for UEM-aware functions, and=20
> provides=20
> the old interfaces for NEM-aware functions (and a=20
> compatibility layer to=20
> call that code, and convert the parameters), and converts=20
> pre-existing=20
> OEM functions to NEM functions (with the same, or perhaps with a=20
> slightly different compatibility layer).  The only thing
>=20
> Re: performance: we won't want to see a C/Perl transition on=20
> EVERY mouse=20
> move, for performance reasons.  Perhaps we need to define a clean way=20
> for defining UEM functions in either Perl, or C?  And if the=20
> function is=20
> defined in C, there needs to be a way to call it from C=20
> without hopping=20
> through Perl.  But there also needs to be a way of calling it=20
> from Perl,=20
> in case it is overridden by Perl code, that wants to augment the=20
> previous function by doing something, calling the previous function,=20
> doing some more, and then returning.  This could be a bit=20
> tricky.  Maybe=20
> it can be defined away somehow, but the ability to override=20
> and augment=20
> the existing functions is important for me.  But I'm not sure=20
> it is all=20
> that important for the functions which need speed.  So if=20
> there is not a=20
> universal way to do this, perhaps some restrictions on what functions=20
> may and may not be defined using C is OK.
>=20
> Re: documentation:  What this project doesn't need, is any more=20
> undocumented capabilities.  The greatest feature in the world=20
> is totally=20
> useless if no one can figure it out.  And there are lots of great=20
> features in Win32::GUI that very few people could figure out.  Having=20
> all the documentation on sourceforge would help.  And maybe=20
> wiki's are=20
> the next greatest thing, but the use of too many different types of=20
> technology can prevent a steep learning curve for potential=20
> contributors.  Erick's existing Win32::GUI Documentation=20
> project suffers=20
> from the inability of contributers to figure out how to=20
> contribute, even=20
> with help from Erick.  No doubt the system works for Erick, but it's=20
> visual cues aren't consistent with the selected operations I=20
> attempted,=20
> so it continually convinced me that it wasn't doing what I=20
> asked it to=20
> do, before I got far enough to actually do anything.  Calling=20
> this new=20
> wiki the "Win32::GUI Documentation Project" is somewhat confusing in=20
> light of Erick's existing project.  I think it should be called=20
> something else.  I'm also not sure that it should be a wiki,=20
> vs simply a=20
> collection of CVS controlled POD files, but feel free to=20
> convince me or=20
> ignore me, but I would like some insight as to what made you=20
> choose to=20
> create a wiki.
>=20
> --=20
> Glenn -- http://nevcal.com/
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> The best part about procrastination is that you are never bored,
> because you have all kinds of things that you should be doing.
>=20
>=20

Re: [perl-win32-gui-hackers] Menus and NEM

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

On approximately 2/20/2004 8:17 AM, came the following characters from
the keyboard of Aldo Calpini:
> hello people :-)
> 
> On Mon, 2004-02-16 at 13:53, Stephen Pick wrote:
> 
>>Hello,
>>
>>Looks like menus are indeed a little busted. You can't use both 
>>event models on a menu. You can use either the NEM or the OEM, but 
>>you can't selectively use NEM here and OEM there. If you add a menu
>>to a window that is using the NEM and your window uses OEM, your menu
>>won't work. Your menu's event model must match that of the window 
>>you're adding it into.
> 
> 
> as I said a lot of time ago, the current OEM/NEM interoperability
> implementation is going to die. there's too much broken code in there,
> and I thought of a way to simplify things a lot (but they will be
> managed a little bit differently).
> 
> the last time I wrote here, I promised a document describing the new
> architecture that I'm going to implement, but in the mean time a damn
> stupid 120 GB external USB HD ate my development directory. more than 1
> GB of stuff, more than 6 years of development, sigh :-(
> 
> so, the whole thing exists only in my mind now.
> 
> basically, the idea is the following: there will be a single messageloop
> for each window (including controls), which, in pseudocode, should do
> something like this:
> 
>   if(event_model & BYREF) {
>         if(window->eventmap(event_id)) {
>             event = window->events{get_event_name(event_id)};
>             fire_event(event);
>         }
>   }
>   if(event_model & BYNAME) {
>        event_name = window->name . "_" . get_event_name(event_id);
>        if(event = perl_get_cv(event_name)) {
>            fire_event(event);
>        }
>   }
> 
> the biggest implication is that the OEM (BYNAME event model) will
> probably result a little bit slower: that's because each message to each
> control will trigger a perl_get_cv call (which is orders of magnitude
> slower than a C instruction). on the other hand, every control will have
> the whole range of events (eg. MouseMove, MouseClick, etc.) enabled by
> default. 
> 
> event_model in the code above is a global variable in C which will be
> controlled by a method (Win32::GUI::SetEventModel or something like
> that) or by a directive in use (eg. use Win32::GUI EventModel =>
> 'BYREF').

This does sound like it would unify the event models, and add all the 
functionality Steve has added via the hooks.  Steve, do you agree that 
it adds all the functionality of hooks?  I've not yet played with them 
to be 100% sure.

One could, however, provide a very simple migration path from slow OEM 
performance to fast OEM performance, with one restriction:  If the OEM 
functions are required to exist at the time a window is created, then at 
window creation time, the namespace could be searched for the names of 
event functions, and they could be collected into the same data 
structures that are used by NEM.

This would eliminate a dynamic performance penalty of OEM, at the cost 
of a creation time performance penalty for OEM.  It would eliminate any 
need to record, for each window, whether it uses OEM or NEM.

Actually, users could almost perform the OEM->NEM conversion just by 
adding the appropriate event names pointing at their old OEM 
functions... Except, if the calling convention for the OEM functions and 
NEM functions vary, then they couldn't be used interchangably.  And that 
seems to be part of the design for compatibility... but maybe that is 
solvable somehow?  With the "automatic" migration, a simple wrapper 
function could be interposed between the NEM calling function 
parameters, and the OEM calling function parameters, which would still 
likely be faster than doing all the perl_get_cv's at run-time?  This is 
discussed more under "Re: parameter passing" below...

> I'm a little (oh, well, a little is not enough :-) behind with the
> situation on CVS, but I'm ready to implement this architectural change. 
> 
> should we branch the CVS repository (or create a new module, which
> sounds better to me) or is the current status quiet enough to begin
> working on this for the next release?

Well, the CVS repository is already branched, bugfix vs development. 
However, it would be a shame to lose all the bugfix work, if you are 
ready to start implementing afresh.

I would suggest that a cooperative approach would be for you to review 
the major code changes, and either accept them, or discuss them in this 
forum, until some consensus can be reached.

We should do a release of what we have so far, subject to discussions 
started by the last paragraph, before starting another major initiative. 
  And if you wouldn't mind starting from the current bug-fix branch code 
(after the release), then the next release point could be merged back 
into the main branch, and you could do your upward-compatible 
development there.  Bug fixing could continue on the bug fix branch, and 
you could pick up the bug fixes from time to time in the main branch, so 
there wouldn't be a major synchronization issue later.

It sounds to me like the hooks will become somewhat redundant as a way 
of capturing messages, but I doubt that they are seriously difficult to 
support in deprecated mode, even if they are redundant.

It is important to me that you retain the ability to set and fetch 
pointers to the functions that get invoked for messages, which Steve 
only recently added to the NEM.


I'll comment on a few of the other threads of discussion, but won't 
reproduce them here.

Re: context: yes, it would be nice to be able to invoke GUI functions 
from any thread, and even have "fake-forked" programs be able to have 
independent windows, if that is straightforward.

Re: DESTROY: of course it would be nice, but except for really dynamic 
programs, not all that necessary.  In other words, not the highest priority.

Re: VB-likeness.  Not important to me in the least.  Useful and usable 
are much more important.  VB isn't really very object oriented; we can 
be much more so in Perl.

Re: PEM.  No comment, until we hear more.

Re: Refactoring code: Certainly improvements could and should be made to 
the structure of the code.

Re: Unicode, I think you understand the main difficulty, UCS2-LE (I'm 
not sure what the -LE means, though) vs UTF-8.  But there should be 
samples of such conversions inside the Perl core (Windows port).

Re: parameter passing: Passing the object as a first parameter to each 
of the event handling functions is an excellant idea.  As well as all of 
the numbers fromthe event message itself.  We need to allow a Win32::GUI 
program all the power of the C program.  There is a compatibility issue 
here.  Neither the OEM nor NEM models pass such a parameter at present. 
  So we can either figure out ways of passing the parameter that isn't 
"clean", but is compatible, and new or modified functions can access the 
appropriate object, or we need to define UEM (unified event model) which 
has the object, and can provide compatible interfaces for existing OEM 
and NEM functions.  I think the latter is relatively straightforword: 
the UEM provides a new interface for UEM-aware functions, and provides 
the old interfaces for NEM-aware functions (and a compatibility layer to 
call that code, and convert the parameters), and converts pre-existing 
OEM functions to NEM functions (with the same, or perhaps with a 
slightly different compatibility layer).  The only thing

Re: performance: we won't want to see a C/Perl transition on EVERY mouse 
move, for performance reasons.  Perhaps we need to define a clean way 
for defining UEM functions in either Perl, or C?  And if the function is 
defined in C, there needs to be a way to call it from C without hopping 
through Perl.  But there also needs to be a way of calling it from Perl, 
in case it is overridden by Perl code, that wants to augment the 
previous function by doing something, calling the previous function, 
doing some more, and then returning.  This could be a bit tricky.  Maybe 
it can be defined away somehow, but the ability to override and augment 
the existing functions is important for me.  But I'm not sure it is all 
that important for the functions which need speed.  So if there is not a 
universal way to do this, perhaps some restrictions on what functions 
may and may not be defined using C is OK.

Re: documentation:  What this project doesn't need, is any more 
undocumented capabilities.  The greatest feature in the world is totally 
useless if no one can figure it out.  And there are lots of great 
features in Win32::GUI that very few people could figure out.  Having 
all the documentation on sourceforge would help.  And maybe wiki's are 
the next greatest thing, but the use of too many different types of 
technology can prevent a steep learning curve for potential 
contributors.  Erick's existing Win32::GUI Documentation project suffers 
from the inability of contributers to figure out how to contribute, even 
with help from Erick.  No doubt the system works for Erick, but it's 
visual cues aren't consistent with the selected operations I attempted, 
so it continually convinced me that it wasn't doing what I asked it to 
do, before I got far enough to actually do anything.  Calling this new 
wiki the "Win32::GUI Documentation Project" is somewhat confusing in 
light of Erick's existing project.  I think it should be called 
something else.  I'm also not sure that it should be a wiki, vs simply a 
collection of CVS controlled POD files, but feel free to convince me or 
ignore me, but I would like some insight as to what made you choose to 
create a wiki.

-- 
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.

Re: [perl-win32-gui-hackers] Menus and NEM

[Jez W. <je...@je...>]

I'm looking at this more from the users perspective, not as a hacker.

I think a decision has to be made whether to make any new module is going to
be backward compatible or not. Personally, I think this would be a good time
to "start from scratch" and incorporate all the lessons that have been
learnt so far. Why not deprecate the OEM and only support NEM - this would
make the job easier for you guys, while reducing the amount of confusion on
our part? Users who are still reliant on OEM (myself included) would just
use the current code line until they are ready to upgrade. Some users would
be alienated, but in the medium term it would be a win win situation for
everyone. A clean, simple code line would be a benefit to all.

General things I'd like to see:

* Destroy working correctly on all objects.
* The parent window (and or the control?) passed as first parameter for
every event (this would allow context aware event handlers - as Johan
Lindstom suggested a few weeks back).
* A Win32::GUI website hosted on sourceforge (with lots content,
documentation and examples).

The first two points would allow you to create and destroy controls/windows
dynamically - and more importantly - handle them in a simple OO design
methodology (rather than using closures, evals and symbol table
manipulation).

Cheers,

jez.


----- Original Message ----- 
From: "Aldo Calpini" <da...@pe...>
To: "Steve Pick" <st...@ba...>
Cc: "Win32 GUI Hackers (E-mail)"
<per...@li...>
Sent: Monday, February 23, 2004 11:31 AM
Subject: Re: [perl-win32-gui-hackers] Menus and NEM


> On Mon, 2004-02-23 at 01:38, Steve Pick wrote:
> > The idea for the event model is good. I noticed that we're running out
of
> > space to add events to the NEM because it uses the eventmask thing, and
> > there's only enough bits in that for 32 events. I was wondering if that
> > whole thing should be done away with, and we should not bother to check
the
> > event mask but rather just look up event names in the "event map" that
you
> > mention, then fire them if they are defined by the user.
>
> not so directly. the big win in using an eventmask thing is that, before
> trying to call the Perl event itself, Win32::GUI can do a quick bit
> comparison on a C variable, and it does take an infinitesimal amount of
> time. doing a hash lookup, instead, is a costly operation. not as costly
> as doing a perl_call_pv, granted, but costly. if we want to keep
> performance at an acceptable level (remember that NEM events are always
> checked for existence, even several times in a second (think about
> MouseMove)) this lookup should be implemented somehow in C, perhaps with
> an ad-hoc data structure.
>
> > I think the events code is very messy right now, supporting both NEM and
OEM
> > with tons of redundant code. It would (I think) be nice to start a new
> > module. There are several things with Win32::GUI that need to be
addressed
> > and are best addressed from scratch. Things like:
>
> erm... I wasn't talking about starting a new "module" in Perl terms, but
> a new "module" in *CVS terms*, which is a quite different thing! :-)
>
> the upcoming implementation is called Win32::GUI 1.00 in my mind, and I
> see no reason to change this to something else. so, let's see if your
> reason convince me :-)
>
> > 1. Perl context bugs
>
> this means adding a plethora of pTHX_ and aTHX_ everywhere, I suppose. I
> have to check the correct formula for this, but should not be a big
> deal.
>
> > 2. Freeing Win32 objects like windows, dialogs etc. Effectively we want
to
> > be able to destroy these objects when their DESTROY sub is called by
Perl
>
> this can be done easily enough. the main point seems to be that a
> reference to a control is placed in its parent hash. eg. if you make
> $Window->AddButton( -name => 'foo'), you are adding an hash key
> $Window->{foo}. so, just deleting this key and calling DestroyWindow on
> the button should free all resources. the problem with DESTROY is that
> the order of calling (and, in my experience, the exact time at which
> this happens) is not guaranteed at all. I had all kinds of problems
> trying to implement a proper DESTROY, but I can revamp my experience in
> this field if this is an important issue :-)
>
> > 3. Move away from the whole "works like Visual Basic" idea. Originally
this
> > was a nice plan, but this is not VB, but perl, and there are many
> > differences between the languages that mean making things work similarly
to
> > visual basic *but with subtle differences* is actually a lot more
confusing
> > than making things work in a perly way, as perl coders expect them to
work.
>
> that's true, oh so true :-)
>
> > Things like hyphens at the start of hash keys and so on should probably
be
> > dropped, for example. I think it's better to basically convert the
relevant
> > APIs (windows shell, gui and gdi) into a useable form implemented in
Perl.
>
> I think hypens at the start of hash keys are a Good Thing. remember that
> controls are stored in their parent's hash, and without the hypens, you
> could make a big mess out of it.
>
> > In other words, stay close to the C API rather than VB, but give it a
Perl
> > twist that allows easy creation of objects (windows, buttons etc), and
gives
> > a good amount of functions/methods for manipulating those objects and
> > sending messages to them.
>
> well, Win32::GUI already does that. the only thing "borrowed" from VB
> was the event model (eg. Button_Click). but I expect, with the new
> implementation of NEM, that OEM will be absolutely deprecated. we can't
> just remove it (for backward compatibility issues), but once people
> realize that NEM performs a lot better, nobody will want to use OEM
> anymore. but still, if they feel comfortable with OEM, they will be able
> to use it.
>
> > 4. wxPerl is eclipsing Win32::GUI, so any new module would have to
continue
> > Win32::GUI's track as being a module that is not, in fact, just about
the
> > GUI. Win32::GUI can now handle resources, controlling other processes
via
> > messages, drawing in GDI, etc.
>
> well, your mileage may vary. in the past, I've used Win32::GUI to
> generate bitmaps for a website (which I later converted to png, of
> course) by drawing a path in a window and dumping its DC to a file. that
> was because GD and other drawing techniques were not giving me the same
> antialiasing on TrueType fonts that Win32::GUI did :-)
>
> Win32::GUI never claimed to be "the killer module" for GUI frontends, so
> if there's a better toolkit (which is portable also), this is not a
> problem. Win32::GUI will be there if (for whatever reason) one wants to
> hook directly into the Win32 SDK APIs. it's also (reportedly to me) much
> simpler to program with than wx for small applications.
>
> > 5. Better support for extending with new controls.
>
> that's the next issue in my mind, after NEM, and is called PEM (Package
> Event Model). stay tuned for more :-)
>
> > 6. A better code structure, move all things like labels, buttons and
stuff
> > into their own XS code, keep GUI.xs as the main repository for common
> > functions/methods that apply to all related objects. Win32::GUI has
> > obviously grown kind of like fungus, with bits added on pretty much at
> > random and not exactly cleanly (like my "hooks" code). This would also
help
> > with point 2.
>
> that's another issue, and I can really use some help from you all. at a
> certain point, I started doing such a "separation", and if you look
> closely at the code, you'll see that there are several things that still
> needs to be completely implemented (for example, each .xs file should
> have its own onParseOption, onPreCreate, onPostCreate hooks).
>
> we could (should?) rethink package organization based on the "nature" of
> the stuff Win32::GUI does manage. for example, there are windows with
> position and size (eg. Buttons, Labels, etc.) and windows which should
> not have an "explicit" position and size (eg. Statusbars).
>
> currently, the Win32::GUI package contains *all* methods that refers to
> windows (and so position, size, style, etc.) as well as functions
> directly imported from the Win32 SDK APIs (eg. GetTextExtentPoint32).
>
> anyway, the code surely needs a bit of refactoring, but this is not
> something that should be visible to the end user.
>
> > 7. Ramy suggested a name change a few days ago. I like Win32::Windows,
as it
> > describes what Win32::GUI does a little better. The module does control
> > Windows, not just the GUI. Open to debate, of course.
>
> yes, this is the main point to debate :-)
> Win32::GUI is what it is and has its history. we can extend the codebase
> and add functionality to do other things than building GUI frontends,
> but I'm afraid that the "core" (what most people will use this module
> for) will always be GUI stuff. from another point of view, every window
> on the screen, every graphical resource on the system has to do with
> User Interaction, so GUI still seems a reasonable name to me. back to
> the roots of the module, the Win32 "bits" it implements are mainly
> USER32.DLL and GDI32.DLL. if you take the "U" from the first and the "G"
> and "I" from the second, you still can make "GUI" :-)
>
> > 8. Unicode support would be nice. I know little about unicode and am
> > confused by all these API functions that have W appended to them for
wide
> > character functionality, and how one should use these functions
> > appropriately.
>
> well, I've never really investigated this issue. I don't think simply
> appending a 'W' to API calls will do some good. the main point, I guess,
> is how to seamlessly integrate Win32's idea of Unicode (which isn't
> Unicode really, but rather UCS2-LE) and Perl's idea of Unicode (which is
> UTF-8 really).
>
> > Obviously if we're going to extend the module in the above ways (or
write a
> > new one) then we need to rename it and release it in a new form, because
> > changing things like the 8 points above will really break backward
compat. I
> > think there are a few things that will need to be laid down at the start
to
> > define how we do things, like check user arguments for errors, how we
> > document stuff, and so on, but all that will have to be discussed if
anyone
> > really wants to help take on a whole new project.
>
> my personal opinion is to avoid breaking things that much. Perl itself
> lived for something like 15 years and 5 major releases before needing to
> throw backward compatibility away. we are still at 0.0.something, so
> there's plenty of time :-)
>
> still, the need to clearly *define* things before embarking on this
> journey is perfectly correct. and to me, one of the biggest thing to be
> defined at this point is how to document stuff. but let's this be
> another topic :-).
>
> cheers,
> Aldo
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Perl-Win32-GUI-Hackers mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers

Re: [perl-win32-gui-hackers] Menus and NEM

[Aldo C. <da...@pe...>]

On Mon, 2004-02-23 at 18:05, Jez White wrote:
> I'm looking at this more from the users perspective, not as a hacker.
> 
> I think a decision has to be made whether to make any new module is going to
> be backward compatible or not. Personally, I think this would be a good time
> to "start from scratch" and incorporate all the lessons that have been
> learnt so far. Why not deprecate the OEM and only support NEM - this would
> make the job easier for you guys, while reducing the amount of confusion on
> our part? Users who are still reliant on OEM (myself included) would just
> use the current code line until they are ready to upgrade. Some users would
> be alienated, but in the medium term it would be a win win situation for
> everyone. A clean, simple code line would be a benefit to all.

still, I don't see the need to "start from scratch" as you say. once the
new NEM will be implemented, supporting OEM will be absolutely
transparent in terms of coding. think of it as a Unified Event Model
architecture. OEM will be deprecated in terms of performance, but it can
stay as it is. developers will be able to concentrate on events itself
and not worry about users calling them as OEM or NEM, trust me :-) 

> General things I'd like to see:
> 
> * Destroy working correctly on all objects.

as I said, this is a little nasty, but it can be implemented.

> * The parent window (and or the control?) passed as first parameter for
> every event (this would allow context aware event handlers - as Johan
> Lindstom suggested a few weeks back).

no. the current plan is:
- the object itself will be passed as the first parameter for every
event with NEM (*and* there will be a method to get a reference to its
parent, as well as another method to get a reference to its topmost 
container)
- OEM will stay as it is, that is no object is passed to events

> * A Win32::GUI website hosted on sourceforge (with lots content,
> documentation and examples).

I have already set up a simple wiki (a Kwiki, actually) at:

http://perl-win32-gui.sourceforge.net/cgi-bin/index.cgi

I just hacked Kwiki a bit to let it grok POD text, because I *want*
documentation to be in POD natively. personally, I find the concept of
wiki to be a good idea in this case, so this site (eg. the home of
perl-win32-gui.sourceforge.net implemented as a wiki) could be the
repository of all things Win32::GUI, and everybody could contribute.


cheers,
Aldo

Re: [perl-win32-gui-hackers] Menus and NEM

[Jez W. <je...@je...>]

> still, I don't see the need to "start from scratch" as you say. once the
> new NEM will be implemented, supporting OEM will be absolutely
> transparent in terms of coding. think of it as a Unified Event Model
> architecture. OEM will be deprecated in terms of performance, but it can
> stay as it is. developers will be able to concentrate on events itself
> and not worry about users calling them as OEM or NEM, trust me :-)

No problem:) I still think there is scope and opertunity for change if you
guys need it...

> no. the current plan is:
> - the object itself will be passed as the first parameter for every
> event with NEM (*and* there will be a method to get a reference to its
> parent, as well as another method to get a reference to its topmost
> container)
> - OEM will stay as it is, that is no object is passed to events

Sounds good to me. I assume you could something like:

sub SomeEventHandler {
 my $self=shift;
 my $win=$self->Parent;
}

>
> I have already set up a simple wiki (a Kwiki, actually) at:
>
> http://perl-win32-gui.sourceforge.net/cgi-bin/index.cgi
>
> I just hacked Kwiki a bit to let it grok POD text, because I *want*
> documentation to be in POD natively. personally, I find the concept of
> wiki to be a good idea in this case, so this site (eg. the home of
> perl-win32-gui.sourceforge.net implemented as a wiki) could be the
> repository of all things Win32::GUI, and everybody could contribute.

Sounds good. Steve has added lots and lots of doco in the last few weeks -
may that effort continue, with us all contrubuting:)

One thing I would suggest, is to add a way for people to submit example code
(perhaps catagorised by control?).

Cheers,

jez.