Menu
▾
▴
perl-win32-gui-hackers
|
From: Laurent R. <ro...@cl...> - 2004-03-14 20:13:12
|
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. |
|
From: Glenn L. <pe...@ne...> - 2004-03-15 04:00:12
|
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. |
|
From: Jez W. <je...@je...> - 2004-03-15 11:07:04
|
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. |
|
From: Glenn L. <pe...@ne...> - 2004-03-15 21:52:11
|
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. |
|
From: Glenn L. <pe...@ne...> - 2004-03-15 22:53:28
|
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. |
|
From: Laurent R. <ro...@cl...> - 2004-03-16 19:51:51
|
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
|
|
From: Glenn L. <pe...@ne...> - 2004-03-16 21:37:59
|
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. |
|
From: Glenn L. <pe...@ne...> - 2004-03-17 17:50:24
|
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. |
|
From: Laurent R. <ro...@cl...> - 2004-03-21 19:03:31
|
Hi All,
> 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...
>
Ok, if nobody have objection, i made a new release tomorrow.
I tag this release as Win32-GUI-0_0_671 on CVS and upload source and PPM on
sourceforge.
> 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.
I continue my work on refactoring Win32::GUI code.
I have made lot of change :
- Add some more methods for controls
- Extend callback function to all control. It's probably interresting to
continue in this way for add posibility to create Win32::GUI extension by
adding a system for register callback function.
- Completly rewrite message loop and event handling.
I rewrite all messageloop and keep common event handling in it.
I think message loop are now much easier.
WindowMsgLoop : Message loop for main window class
(WINDOW,DIALOGBOX)
ControlMsgLoop : for child message loop. Use for subclassing
standard child control and Win32::GUI::Class.
ContainerMsgLoop : Special message loop for create container class
with Win32::GUI::Class.
CustomMsgLoop : Special message loop for create specific
Win32::GUI control (splitter, graphics).
Now all specific event is handle in a <Control>_OnEvent callback
function.
Each event is fire by a unique DoEvent method (same concept DoEventNEM
with arglist).
DoEvent handle NEM and OEM event call. (UEM?)
- Try Write code for NotifyIcon and Accelerator NEM handling (not tested
yet)
- New DoModal() (based Aldo previous mail)
- Some code cleanup
- Fix some problem with url link in dodoc.pl and dohtml.pl.
- ...
I have test some script and it's work not to bad.
I try to keep compatibility with previous version.
You can see a copy of my developpement directory here :
http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/Win32-GUI.zip
After Win32::GUI 0.0.671 release, i think we can work on this base code for
next release.
It's probably better to use Main Win32-GUI CVS branch now.
Cheers,
Laurent
|
|
From: Glenn L. <pe...@ne...> - 2004-03-22 09:44:58
|
Apologies, I haven't read your code yet, so I might have asked something obvious in the below. You are "on a roll" Laurent! It all sounds good! On approximately 3/21/2004 11:02 AM, came the following characters from the keyboard of Laurent ROCHER: > I continue my work on refactoring Win32::GUI code. > I have made lot of change : > - Add some more methods for controls Would this happen to include RightClick and DblRightClick ? > Each event is fire by a unique DoEvent method (same concept DoEventNEM > with arglist). > DoEvent handle NEM and OEM event call. (UEM?) This sounds more efficient. UEM doesn't exist yet, it is what I named a concept that would seem to unify OEM, NEM, and Aldo's next generation event model. I think the big interface change with Aldo's next generation event model was the addition of the window widget object reference as a parameter to the event sub. Neither OEM nor NEM passed that, so you can't add it easily without being incompatible. It would be useful, though, to have the object reference as a parameter but would require a new flag to indicate that the -on* and -event defined subs were expecting the new parameter (which should probably be the first parameter). So I'm not sure if you should call your new DoEvent UEM quite yet, but it seems a good foundation step in that direction. > - Try Write code for NotifyIcon and Accelerator NEM handling (not tested > yet) Thanks, I'll take a look at this when I get a chance. Since I'd gone a certain distance in converting to NEM in my project, and didn't want to back-out all that code, I had actually implemented a couple "wrapper" functions that searched for -on* and -event, and processed them in Perl, using eval to create NAME_EVENT (OEM style) subs that call the NEM subs, and then eliminated those parameters (-on* and -event) from the calls to Win32::GUI, resulting in OEM. Well, the upshot is that I am using NEM style calls, and converting them to OEM on the fly, so I should be able to quickly flip-flop my application between using OEM and NEM. Which might help in my testing of your additions, if I get time to do that. -- 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. |
|
From: Laurent R. <ro...@cl...> - 2004-03-22 12:50:16
|
> Apologies, I haven't read your code yet, so I might have asked something
> obvious in the below. You are "on a roll" Laurent! It all sounds good!
>
> On approximately 3/21/2004 11:02 AM, came the following characters from
> the keyboard of Laurent ROCHER:
>
> > I continue my work on refactoring Win32::GUI code.
> > I have made lot of change :
> > - Add some more methods for controls
>
> Would this happen to include RightClick and DblRightClick ?
Yes those events are handle for control supporting then.
Generaly, Common Control (TreeView, ...) support them via standard notify
code (NM_RCLICK, NM_RDBLCLK).
Basic control (button, label, textfield, ...) have sometime specific message
for that but don't work for every control.
However, all control receive standard window mouse event (WM_MOUSEMOVE,
WM_LBUTTONDOWN, WM_LBUTTONUP, ...).
Those events are handle by MouseMove, MouseDown, MouseUp event.
It's possible to add RMouseDown, RMouseUp, MMouseDown, MMouseUp for Right
and Middle button click.
Click/DblClick event are different than standard mouse event, it's control
dependent.
Event name isn't unified, for sample :
- Graphic generate LButtonDown instead MouseDown and have a RButtonDown
event didn't exist for other control.
- Listbox have a Click event when receive LBN_SELCHANGE. A Change event
should be nicer.
I don't change this for compatibility reason.
>
> > Each event is fire by a unique DoEvent method (same concept
DoEventNEM
> > with arglist).
> > DoEvent handle NEM and OEM event call. (UEM?)
>
> This sounds more efficient. UEM doesn't exist yet, it is what I named a
> concept that would seem to unify OEM, NEM, and Aldo's next generation
> event model.
Yes all event firing code using only one function (easier to change, add
model event).
>
> I think the big interface change with Aldo's next generation event model
> was the addition of the window widget object reference as a parameter to
> the event sub. Neither OEM nor NEM passed that, so you can't add it
> easily without being incompatible. It would be useful, though, to have
> the object reference as a parameter but would require a new flag to
> indicate that the -on* and -event defined subs were expecting the new
> parameter (which should probably be the first parameter).
>
> So I'm not sure if you should call your new DoEvent UEM quite yet, but
> it seems a good foundation step in that direction.
NEM event always send window self reference as first parameter.
I don't think it's usefull for OEM event because function use window name.
It's a good reason to use NEM event ;o)
But, it's possible to add a new event model option switch for do that.
Something like -eventmodel => [both, byref, byname, byname_self].
byname_self is same than byname but with a self as first parameter.
A global SetEventModel can be usefull for setup default event model (actualy
it's BYNAME by default).
> > - Try Write code for NotifyIcon and Accelerator NEM handling (not
tested
> > yet)
>
> Thanks, I'll take a look at this when I get a chance. Since I'd gone a
> certain distance in converting to NEM in my project, and didn't want to
> back-out all that code, I had actually implemented a couple "wrapper"
> functions that searched for -on* and -event, and processed them in Perl,
> using eval to create NAME_EVENT (OEM style) subs that call the NEM
> subs, and then eliminated those parameters (-on* and -event) from the
> calls to Win32::GUI, resulting in OEM. Well, the upshot is that I am
> using NEM style calls, and converting them to OEM on the fly, so I
> should be able to quickly flip-flop my application between using OEM and
> NEM. Which might help in my testing of your additions, if I get time to
> do that.
Ok, i understand why you want self in OEM ;o)
I have same problem with my TabFrame package (NEM didn't exist when i write
it).
I need to keep all instance in a global hash, doing something like that :
# Keep object reference
$Instance{$options{-name}} = $self;
# Add Click Event
eval qq(
sub main::$options{-name}_Click {
return Win32::GUI::TabFrame->ClickEvent($options{-name});
}
);
sub ClickEvent {
my $class = shift;
my $name = shift;
my $element = $Instance{$name};
...
}
NEM, it's easier for that ;o)
Actually, with new event model handling, NEM and OEM work in concert (adding
a new event handle, it's handle in both mode).
Laurent.
|
|
From: Jez W. <je...@je...> - 2004-03-22 11:32:55
|
Good work Laurent! I had a quick glance through your dev codeline, and it looks good. I'm quite interested in the DoModal stuff:) I've got quite a few test scripts, so once you've committed these changes I'll run through them. With the 671 build, perhaps it's time for a bit of self promotion and spread this build around the web (update the activestate repository etc)? cheers, jez. ----- Original Message ----- From: "Laurent ROCHER" <ro...@cl...> To: <per...@li...> Cc: "Aldo Calpini" <da...@pe...> Sent: Sunday, March 21, 2004 7:02 PM Subject: Re: [perl-win32-gui-hackers] Time for a new Release ? and start next Win32::GUI implementation > Hi All, > > > > 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... > > > > Ok, if nobody have objection, i made a new release tomorrow. > I tag this release as Win32-GUI-0_0_671 on CVS and upload source and PPM on > sourceforge. > > > 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. > > I continue my work on refactoring Win32::GUI code. > I have made lot of change : > - Add some more methods for controls > - Extend callback function to all control. It's probably interresting to > continue in this way for add posibility to create Win32::GUI extension by > adding a system for register callback function. > - Completly rewrite message loop and event handling. > I rewrite all messageloop and keep common event handling in it. > I think message loop are now much easier. > WindowMsgLoop : Message loop for main window class > (WINDOW,DIALOGBOX) > ControlMsgLoop : for child message loop. Use for subclassing > standard child control and Win32::GUI::Class. > ContainerMsgLoop : Special message loop for create container class > with Win32::GUI::Class. > CustomMsgLoop : Special message loop for create specific > Win32::GUI control (splitter, graphics). > Now all specific event is handle in a <Control>_OnEvent callback > function. > Each event is fire by a unique DoEvent method (same concept DoEventNEM > with arglist). > DoEvent handle NEM and OEM event call. (UEM?) > - Try Write code for NotifyIcon and Accelerator NEM handling (not tested > yet) > - New DoModal() (based Aldo previous mail) > - Some code cleanup > - Fix some problem with url link in dodoc.pl and dohtml.pl. > - ... > > I have test some script and it's work not to bad. > I try to keep compatibility with previous version. > > You can see a copy of my developpement directory here : > http://perso.club-internet.fr/rocherl/Win32-GUI-Dev/Win32-GUI.zip > > After Win32::GUI 0.0.671 release, i think we can work on this base code for > next release. > It's probably better to use Main Win32-GUI CVS branch now. > > Cheers, > Laurent > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers |
|
From: Laurent R. <ro...@cl...> - 2004-03-22 13:01:22
|
> Good work Laurent! I had a quick glance through your dev codeline, and it > looks good. I'm quite interested in the DoModal stuff:) I've got quite a few > test scripts, so once you've committed these changes I'll run through them. If this script isn't too complex it's could be nice to add it in Samples directory. I think to add this directory in main CVS for provide nice samples with Win32::GUI. > > With the 671 build, perhaps it's time for a bit of self promotion and spread > this build around the web (update the activestate repository etc)? > I don't know how to update ActiveState repository. If Aldo put a new Win32-GUI dist file in his CPAN repository, it's automaticly update in ActiveState ? Laurent |
|
From: Aldo C. <da...@pe...> - 2004-03-22 13:20:59
|
On Mon, 2004-03-22 at 14:00, Laurent ROCHER wrote: > If this script isn't too complex it's could be nice to add it in Samples > directory. I think to add this directory in main CVS for provide nice samples with > Win32::GUI. I definitely agree. > I don't know how to update ActiveState repository. > If Aldo put a new Win32-GUI dist file in his CPAN repository, it's > automaticly update in ActiveState ? AFAIK, if the distribution passes the test suite, it is automatically updated in the ActiveState repository. there maybe a problem, however, because some time ago they arbitrarily decided that Win32::GUI was version 0.99 (yes, sometimes ActiveState sucks), and so if we release something like 0.0.671 this will result older than what they already have in the repository. but I will update the file on CPAN nonetheless, and we'll see what happens. cheers, Aldo |
|
From: Jez W. <je...@je...> - 2004-03-22 16:08:31
|
> If this script isn't too complex it's could be nice to add it in Samples > directory. > I think to add this directory in main CVS for provide nice samples with > Win32::GUI. Most of my test scripts are simple, they just test a single control or various GUI concepts. If you create a directory on CVS I'll commit them. I'll also send a email to the users list asking for people to mail me examples, and I'll commit any responses I get. I'll also search though the mailing list and pull out any good examples I find. You can never have to many examples:) Cheers, jez. |
|
From: Laurent R. <ro...@cl...> - 2004-03-22 16:47:06
|
> > If this script isn't too complex it's could be nice to add it in Samples > > directory. > > I think to add this directory in main CVS for provide nice samples with > > Win32::GUI. > Most of my test scripts are simple, they just test a single control or > various GUI concepts. > > If you create a directory on CVS I'll commit them. I'll also send a email to > the users list asking for people to mail me examples, and I'll commit any > responses I get. I'll also search though the mailing list and pull out any > good examples I find. It's probably too short for 0.0.671 (i have finish build all zip ;o). I finish all for 0.0.671 release in 665-fix branch. After this branch should be considered close. For next major release, we can work on MAIN Win32-GUI branch. If Aldo and others are agree, i can commit my code as base code for it. I include Samples, Docs and t directory in it, so we have a complete Win32-GUI tree. > You can never have to many examples:) I agree ;o) Laurent. |
|
From: Glenn L. <pe...@ne...> - 2004-03-15 18:18:29
|
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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X