From: Laurent R. <ro...@cl...> - 2004-03-25 23:26:46
|
Hi all, I have commit new Win32::GUI code in CVS [Module : Win32-GUI, Branch : = HEAD]. Changelog : - New Base code :=20 + Separate each control in a specific XS file. + Add callback function for each control (onPreCreate, = onParseOption, onPostCreate, onParseEvent, OnEvent). + Rewrite Event Loop. + Merge all event firing code in on function (DoEvent) for OEM = and NEM. + New DoModal function. + Improve Change method. + Add lot of control Win32 API method. (Keep alphabetical order = and standard API name). =20 + Add new events for control. + Some Clean Up. + Reduce size of allocate structure per window. + Add Perl context handling. + and more... - Fix doc tools generator (DoDoc.pl and DoHtml.pl) I have add docs and samples directory in CVS too for have a complet = tree. In docs, you can found two scripts : dodoc.pl : for generate pod files from sources codes. dohtml.pl : for transform pod to html. In Samples, i have commit one sample i made for show EOM/NEM/BOTH event = model. Laurent. |
From: Laurent R. <ro...@cl...> - 2004-03-26 19:06:06
|
Hi, I correct and commit some little bug. Changelog : - GUI.h : PERLUD_FROM_WND macro return now 0 (MinGW Warning). - GUI.pm : + new Graphic method use standard _new creation (and replace hard coded constant) + Fix timer DESTROY - Window.xs : Graphic_onEvent return Perlresult (and not 0). For building with MinGW, you need to upgrade to last w32api-2.5. http://www.mingw.org/download.shtml#hdr2 Laurent. |
From: Laurent R. <ro...@cl...> - 2004-03-28 15:34:35
|
Hi All, I commit new stuff. I add reference of Sourceforge Tracker BUG and RFE in changelog. I close someone but need to check if other can be already close or fix. Changelog : [#627779] : Not able use with embedded perl [#918896] : No [Dbl]RightClick events in NEM [#921170] : 670: DC Circle strange arguments [#918899] : No NotifyIcon support in NEM [#880798] : Accelerators don't work with NEM Add destroy window mechanism and free perlud ressource when windows destroy Add NEM support for notifyIcon. Add full mouse support (left/middle/right mousedown, mouseup, mouseDblClick) - Annimation.xs : + Correct Event handling and add OpenEx method. - Button.xs : + Use dwFlags & dwFlagsMask in perlcs for set check state. + Fix GetCheck and SetCheck Alias. - Combobox.xs : + Add ComboboxEx ExtendedStyle. + Add some documentation and missing methods. - DC.xs : + Fix Circle method. - GUI.h : + Add new dwFlagsMask value in PERLWIN32GUI_CREATESTRUCT and a BitmaskOptionValueMask macro + Add PERLUD_FREE macro calling new Perlud_Free function. + Add new common Event constant. - GUI.pm : + Win32::GUI::_new : Use tie return value for safe. + Win32::GUI::Window::DESTROY : Change timer/notifyicon clean up (probably no more need). + Win32::GUI::Timer : Change new and Destroy method. We store timer name in -timers parent hash, and Timer object only 1 time as parent child. We don't store window parent reference in Timer object for avoid circular reference. + Win32::GUI::NotifyIcon : Change new and Destroy method. Same mechanism than Timer. + In Win32::GUI::WindowProps HASH mechanism : Add a DESTROY method and call DestroyWindow for remove Self Window. - GUI.xs : + RegisterClassEx() : Unregister class if first register fail, and re-try to register. + Create : Increment self reference when add to parent hash. + DoModal : Remove a forget printf. - GUI_Events.cpp : + DoEvent_Timer() : Change timer name search (related new method change) + DoEvent_NotifyIcon() : Change NotifiIcon name and object search (related new method change) and add NEM event support. - GUI_Helpers.cpp : + Add Perlud_Free : Free all allocated data in perlud (hvEvent, avHooks, svSelf and perlpud). Use PERLUD_FREE macro for call it. - GUI_MessageLoops.cpp : + Add PERLUD_FREE on WN_DESTROY event. + Add new standard event : MouseDblClick, MouseRightDown, MouseRightUp, MouseRightDblClick, MouseMiddleDown, MouseMiddleUp, MouseMiddleDblClick, Char. + Add new NotifyIcon event : DblClick, RightDblClick, MiddleClick, MiddleDblClick. + In CustomMsgLoop : Call ControlMsgLoop if PERLWIN32GUI_INTERACTIVE style flag is set. - GUI_Options.cpp : + ParseNEMEvent : Add new standard event. + Add ParseNotifyIconOptions and ParseNEMNotifyIconEvent : add NEM support for NotifyIcon. - NotifyIcon.xs : + Use ParseNotifyIconOptions for parsing option and NEM event. - Splitter.xs : + Splitter_onEvent : Fix PerlResult return. - Window.xs : + Graphic_onEvent & Graphic_onParseEvent : Clean Interactive graphics event handling. Now, CustomMsgLoop call ControlMsgLoop if PERLWIN32GUI_INTERACTIVE style flag is set. Ouf ;o) I try to commit less thing next time. Laurent |
From: Laurent R. <ro...@cl...> - 2004-03-28 19:58:05
|
Hi, Some small bug fix : - UpDown : + Fix Scroll event. - GUI_Events.cpp : + In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after event call. I looking for NEM support for accelerator and i don't know if my current implementation was good. If you look in sample below, you see it's always call -onClick window event with accelerator name but not call button click event like in OEM. For NEM support it's probably nicer to call Button click method like OEM do. What do you think ? Laurent. use Win32::GUI; my $acc = new Win32::GUI::AcceleratorTable( "A" => "Window", "B" => "Button", ); $W = new Win32::GUI::Window( -name => "Window", -title => "test", -pos => [100, 100], -size => [280, 280], -accel => $acc, # NEM call comment for OEM. -onClick => sub { my ($self, $name) = @_; print "Window OnClick : $name\n"; }, ); $W->AddButton( -name => "Button", -pos => [5, 5], -size => [100, 100], -text => "Just button", ); $W->Show; Win32::GUI::Dialog(); # OEM call sub Window_Click { print "Window_Click\n"; } sub Button_Click { print "Button_Click\n"; } |
From: Jez W. <je...@je...> - 2004-03-29 10:30:43
|
My 2 cents worth. I *really* like this approach. The idea of one handler is much cleaner and simpler, especially when you have many items in the table. Going one step further I'd like to see the same kind of approach taken for menus! cheers, jez. ----- Original Message ----- From: "Laurent ROCHER" <ro...@cl...> To: "Win32 GUI Hackers" <per...@li...> Sent: Sunday, March 28, 2004 8:56 PM Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS. > Hi, > > Some small bug fix : > - UpDown : > + Fix Scroll event. > - GUI_Events.cpp : > + In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after > event call. > > I looking for NEM support for accelerator and i don't know if my current > implementation was good. > If you look in sample below, you see it's always call -onClick window event > with accelerator name but not call button click event like in OEM. > For NEM support it's probably nicer to call Button click method like OEM do. > What do you think ? > > Laurent. > > use Win32::GUI; > > my $acc = new Win32::GUI::AcceleratorTable( > "A" => "Window", > "B" => "Button", > ); > > $W = new Win32::GUI::Window( > -name => "Window", > -title => "test", > -pos => [100, 100], > -size => [280, 280], > -accel => $acc, > # NEM call comment for OEM. > -onClick => sub { my ($self, $name) = @_; print "Window OnClick : > $name\n"; }, > ); > > $W->AddButton( > -name => "Button", > -pos => [5, 5], > -size => [100, 100], > -text => "Just button", > ); > > $W->Show; > Win32::GUI::Dialog(); > > # OEM call > sub Window_Click { > print "Window_Click\n"; > } > > sub Button_Click { > print "Button_Click\n"; > } > > > > ------------------------------------------------------- > 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: Glenn L. <pe...@ne...> - 2004-03-29 18:52:37
|
The approach is workable, but it 1) isn't as easily portable from OEM accelerators, which I think is useful to preserve. 2) a single handler is forced to "couple" the code for widely disparate events, which isn't always the easiest to maintain... and you often wind up with a haandler that has an extra switch statement in it to further dispatch the event. The OEM accelerator model caused the dispatch of the exact, already defined widget_Click event, allowing accelerators to be handled without writing any additional code, which is a great timesaver for adding many simple accelerators in many applications, which I think should be preserved. 3) As I outlined in my previous message, some extensions could be made to accelerators. If all accelerator keys are mapped to names that do not have widgets, then you do wind up with the option of handling all accelerators in a single handler, if that method appeals to you and/or is an appropriate technique for particular applications. Regarding handling menus via a single handler. I have the same concerns that for many applications that adds an extra switch statement, and couples disparate lines of code. And the implementation in Windows and Win32::GUI for menus and accelerators is quite different, although that alone shouldn't stop us from giving a unified interface if it makes sense, isn't too hard, and is seen as desirable for some applications. So what is the essence of a menu? And how are they different from accelerators? An accelerator is: "key" => "name" (or possibly, by enhancement, "key" => sub {...} ) A menu is "text" => "name" # OEM "text" => { -name => "name, -onClick => sub {...}, } # NEM The "text" part can also have flags which encode a level of hierarchy, and some geometry (separators and columnization at least) specifications. For OEM, we have the _Click event available, and if the name_Click function exists it is called when the menu item is selected. So indeed, the action part of the activity is very similar to accelerators, but under the covers, there is a collection of Windows data structures created, that are not created for accelarators... but this is mostly for the user interface differences between menus and accelerators. For NEM, while it isn't presently implemented, one could envision that other events could be defined for menu items.... at least a RightClick event could be envisioned, possibly also GotFocus/LostFocus, DblClick, DblRightClick, maybe others). If this sort of extension would be made, which I think would be useful (note that Windows differentiates clicking and right clicking on Start menu items, among other things), then the vision of accelerators and menus as being fairly similar starts to break down.... there is no possibility of RightClick-ing an accelerator :) And there could be a richer event model for menus than a simple, single, Click event. And I would doubt that handling a richer event model for menus would appropriately be done by a single handler in most applications. On approximately 3/29/2004 2:30 AM, came the following characters from the keyboard of Jez White: > My 2 cents worth. I *really* like this approach. The idea of one handler is > much cleaner and simpler, especially when you have many items in the table. > Going one step further I'd like to see the same kind of approach taken for > menus! > > cheers, > > jez. > > ----- Original Message ----- > From: "Laurent ROCHER" <ro...@cl...> > To: "Win32 GUI Hackers" <per...@li...> > Sent: Sunday, March 28, 2004 8:56 PM > Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS. > > > >>Hi, >> >>Some small bug fix : >> - UpDown : >> + Fix Scroll event. >> - GUI_Events.cpp : >> + In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after >>event call. >> >>I looking for NEM support for accelerator and i don't know if my current >>implementation was good. >>If you look in sample below, you see it's always call -onClick window > > event > >>with accelerator name but not call button click event like in OEM. >>For NEM support it's probably nicer to call Button click method like OEM > > do. > >>What do you think ? >> >>Laurent. >> >>use Win32::GUI; >> >>my $acc = new Win32::GUI::AcceleratorTable( >> "A" => "Window", >> "B" => "Button", >>); >> >>$W = new Win32::GUI::Window( >> -name => "Window", >> -title => "test", >> -pos => [100, 100], >> -size => [280, 280], >> -accel => $acc, >> # NEM call comment for OEM. >> -onClick => sub { my ($self, $name) = @_; print "Window OnClick : >>$name\n"; }, >>); >> >>$W->AddButton( >> -name => "Button", >> -pos => [5, 5], >> -size => [100, 100], >> -text => "Just button", >>); >> >>$W->Show; >>Win32::GUI::Dialog(); >> >># OEM call >>sub Window_Click { >> print "Window_Click\n"; >>} >> >>sub Button_Click { >> print "Button_Click\n"; >>} >> >> >> >>------------------------------------------------------- >>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 > > > > > ------------------------------------------------------- > 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 > > -- 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-29 18:26:16
|
Hi Laurent, I'm excited about all the enhancements you are making to Win32::GUI these days, can hardly wait to try them out! On approximately 3/28/2004 11:56 AM, came the following characters from the keyboard of Laurent ROCHER: > Hi, > > Some small bug fix : > - UpDown : > + Fix Scroll event. > - GUI_Events.cpp : > + In DoEvent_* functions : PERLWIN32GUI_EVENTHANDLING is set after > event call. > > I looking for NEM support for accelerator and i don't know if my current > implementation was good. Of course a strong correlation to the behavior in OEM would be best, at least as a default behavior. Other options could be considered, but they should be options, not the default. > If you look in sample below, you see it's always call -onClick window event > with accelerator name but not call button click event like in OEM. > For NEM support it's probably nicer to call Button click method like OEM do. > What do you think ? I would agree calling the button click event would be better.... if the button click event exists. So Accellerator table is made of "key" => "name" where _Click event should be called for the widget named "name". That assumes that 1) A widget named "name" is defined 2) The widget supports a _Click event (in OEM, sub name_Click exists) In OEM, I think if either of the above is false, that the accelerator has no useful effect. In NEM, the default behavior should be similiar: if the widget named "name" exists, and has a sub defined for _Click event, it should be called. But we could also define additional behaviors for accelerators... A) Calling the _Click event of the parent Window, as you seem to be presently doing, might be a nice default if there is no widget named "name", or it has on _Click event. B) Maybe instead of overusing the _Click event of the parent Window, one could define a new parent -onAccel event, that would get called with the accelerator name as a parameter, if there is no widget named "name". I think if there is a widget named "name", and it doesn't have a _Click event, then the accelerator for that name should be ignored until there is a _Click event defined for that widget. This would result in an extension to the current Accelerator support, allowing definition of Accelerators that don't have corresponding GUI actions. Which I think is not only OK, but could be very useful. One could put the essence of the interface on the GUI, but one could define Accelerator keys that could do complex combinations of GUI actions, or even non-GUI actions, instead of being limited to the unit actions available on the GUI. C) One could change AcceleratorTable from "key" => "name" to also allow "key" => sub { }, and this would get the parent window and the accelerator key as parameters? And would completely decouple that accelerator key from any named widget. Clearly this would be more work to implement, but would nicely fit the NEM model, as far as I can tell. > Laurent. > > use Win32::GUI; > > my $acc = new Win32::GUI::AcceleratorTable( > "A" => "Window", > "B" => "Button", > ); > > $W = new Win32::GUI::Window( > -name => "Window", > -title => "test", > -pos => [100, 100], > -size => [280, 280], > -accel => $acc, > # NEM call comment for OEM. > -onClick => sub { my ($self, $name) = @_; print "Window OnClick : > $name\n"; }, > ); > > $W->AddButton( > -name => "Button", > -pos => [5, 5], > -size => [100, 100], > -text => "Just button", > ); > > $W->Show; > Win32::GUI::Dialog(); > > # OEM call > sub Window_Click { > print "Window_Click\n"; > } > > sub Button_Click { > print "Button_Click\n"; > } > > > > ------------------------------------------------------- > 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 > > -- 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-29 20:40:57
|
Hi all, If i resume, Accelerator event implement could be : 1) if accelerator define like : "key" => sub { } or "key" => \&mysub - Call this function with Window Self + accelerator name. 2) if accelerator define like : "Key" => "Name" - Find a window called "Name" in current window hierarchy and call -onClick event if exist with Window Self . - Call Window -onClick event if exist with Self + Name (-acc is availlable only for Window and Dialog so Click event isn't use for specific stuff). - Check for OEM Name_Click and call it if exist. Of course we stop after first event call. I think it's not too much difficult to do ;o) Laurent. > Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS. > Hi Laurent, > > I'm excited about all the enhancements you are making to Win32::GUI > these days, can hardly wait to try them out! |
From: Glenn L. <pe...@ne...> - 2004-03-29 21:28:21
|
On approximately 3/29/2004 12:39 PM, came the following characters from the keyboard of Laurent ROCHER: > Hi all, > > If i resume, Accelerator event implement could be : > > 1) if accelerator define like : "key" => sub { } or "key" => \&mysub > - Call this function with Window Self + accelerator name. This one will clearly wind up being the fastest to locate and invoke, under NEM. > 2) if accelerator define like : "Key" => "Name" > - Find a window called "Name" in current window hierarchy and > call -onClick event if exist with Window Self . > - Call Window -onClick event if exist with Self + Name (-acc is availlable > only for Window and Dialog so Click event isn't use for specific stuff). Yes, -accel is only available for those two, but I could imagine other uses for Click event on the "white space" of a parent window. So that is why I suggested making a new "Accel" event, so one could specify -onAccel => sub {...} > - Check for OEM Name_Click and call it if exist. This last would only be done for OEM mode, and BOTH mode, I presume. > Of course we stop after first event call. > > I think it's not too much difficult to do ;o) More power to you! > Laurent. > > >>Subject: Re: [perl-win32-gui-hackers] New Win32::GUI code in MAIN CVS. >>Hi Laurent, >> >>I'm excited about all the enhancements you are making to Win32::GUI >>these days, can hardly wait to try them out! > > > > -- 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-30 20:15:29
|
Hi, I commit new Accelerator event handling. - GUI.h : + Add FindChildWindowsProc prototype and search typedef struct. - GUI_Events.cpp : + Rewrite DoEvent_Accelerator. - GUI_Helpers.cpp : + Add FindChildWindowsProc for search a child with specific name. > > > > 1) if accelerator define like : "key" => sub { } or "key" => \&mysub > > - Call this function with Window Self + accelerator name. > > This one will clearly wind up being the fastest to locate and invoke, > under NEM. Yes, it's faster way. > > 2) if accelerator define like : "Key" => "Name" > > - Find a window called "Name" in current window hierarchy and > > call -onClick event if exist with Window Self . > > - Call Window -onClick event if exist with Self + Name (-acc is availlable > > only for Window and Dialog so Click event isn't use for specific stuff). > > Yes, -accel is only available for those two, but I could imagine other > uses for Click event on the "white space" of a parent window. So that > is why I suggested making a new "Accel" event, so one could specify > -onAccel => sub {...} Actually, i keep Click because : - I win an NEM event flag ;o) - For Click event on the "white space", it's not standard window event. And, i think it's more application implementation to use KeyDown event and check white space. - We can reuse Click event for menu (like Jez suggest) (so accelerator and menu call same method). When your menu is "text" => "name" like in OEM. We can call Window -click event if we can't found a OEM event handler. But of course it's easy to change. > > - Check for OEM Name_Click and call it if exist. > > This last would only be done for OEM mode, and BOTH mode, I presume. Actually, i call it, only if haven't find a named child window or named child window is OEM/BOTH. I can call Unknow_Click method like in OEM (for compatibility). Laurent |
From: Glenn L. <pe...@ne...> - 2004-04-02 21:43:22
|
On approximately 3/30/2004 12:14 PM, came the following characters from the keyboard of Laurent ROCHER: > Hi, > > I commit new Accelerator event handling. > - GUI.h : > + Add FindChildWindowsProc prototype and search typedef struct. > - GUI_Events.cpp : > + Rewrite DoEvent_Accelerator. > - GUI_Helpers.cpp : > + Add FindChildWindowsProc for search a child with specific name. Sounds good. >>>2) if accelerator define like : "Key" => "Name" >>> - Find a window called "Name" in current window hierarchy and >>>call -onClick event if exist with Window Self . >>> - Call Window -onClick event if exist with Self + Name (-acc is > > availlable > >>>only for Window and Dialog so Click event isn't use for specific stuff). >> >>Yes, -accel is only available for those two, but I could imagine other >>uses for Click event on the "white space" of a parent window. So that >>is why I suggested making a new "Accel" event, so one could specify >>-onAccel => sub {...} > > > Actually, i keep Click because : > - I win an NEM event flag ;o) > - For Click event on the "white space", it's not standard window event. > And, i think it's more application implementation to use KeyDown event > and check white space. > - We can reuse Click event for menu (like Jez suggest) (so accelerator > and menu call same method). > When your menu is "text" => "name" like in OEM. > We can call Window -click event if we can't found a OEM event > handler. > > But of course it's easy to change. OK, I'm no expert in what is standard window event, so that sounds reasonable, given the availability of KeyDown on window. So is it implemented that menus without -onClick events will call Window -onClick? If not, this isn't a very good reason, and I'm not fond of the idea, but I can see it would be slightly handy. So it occurred to me this morning that if we are going this route, that Buttons without -onClick should also fall into the Window -onClick. I'm not fond of the idea because the Window -onClick, winds up having to handle lots of events, so has to include a "dispatcher" or "switch statement" to do so... and inside GUI, if -onClick is specified for all the individual events, the dispatching can be done in C code instead of Perl code, which should be faster. I can see the "convenience" of writing one humongous function to handle all of Accelerators, Menus, and Buttons, with the same code regardless of which way an operation is invoked... but it suffers in performance, and I am somewhat negative about encouraging that. Specifying -onClick => sub { ... } allows the dispatch to happen in C, and if the ... is simply { & my_sprongle_handler() } that is fine to handle either the sprongle button, the accelerator key for sprongle, or the Tools / Sprongle menu entry. So you have 3 dinky wrapper functions... or you could specify -onClick => \& my_sprongle_handler if there is no need to distinguish between which way the handler was invoked. But I can't complain too much, because both technique will be available for use. >>> - Check for OEM Name_Click and call it if exist. >> >>This last would only be done for OEM mode, and BOTH mode, I presume. > > > Actually, i call it, only if haven't find a named child window or named > child window is OEM/BOTH. > I can call Unknow_Click method like in OEM (for compatibility). Ah. OK. -- 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-04-04 18:17:34
|
I commit new thing. Changelog : Complet API and documentation - Combobox.xs, DateTime.xs, GUI.pm, GUI.xs : + Add some documentation - DC.xs : + Add lot of new methods - GUI.h : + Add some new prototype - GUI_Options.cpp + Add new parse options function. - Header.xs : + Add new methods and styles options. - Label.xs : + Add new styles options. - Listbox.xs : + Add new styles options and documentation. - ListView.xs : + Add new methods, styles options and documentation. - Rebar.xs : + Add new methods, styles options and documentation. - Toolbar.xs : + Add new methods, styles options and documentation. - Trackbar.xs : + Add new styles options and documentation. - TreeView.xs : + Add new styles options and documentation. - TYPEMAP + Add HRGN. Laurent. |
From: Laurent R. <ro...@cl...> - 2004-04-06 19:12:19
|
New stuff on CVS : Changelog : Complet Tooltip API. - GUI.h : + Add new prototype. - GUI_Options.cpp : + Add ParseTooltipOptions. - ToolTip.xs : + Complet API. Laurent. |
From: Laurent R. <ro...@cl...> - 2004-04-08 21:38:18
|
New changes on CVS : Changelog : Complet ImageList and TabStrip API. - Font.xs : + Improve parsing font options. - GUI.h : + Add new prototype. - GUI.pm : + Add method AddMasked for ImageList. + Add method Change for NotifyIcon. - ImageList.xs: + Add new methods and documentation. - StatusBar.xs: + Add new style option. - TabStrip.xs: + Add new methods, styles options and documentation. - Trackbar.xs : + Change styles name options. - Todo : + Complete todo Laurent. |
From: Glenn L. <pe...@ne...> - 2004-04-10 21:27:49
|
On approximately 4/8/2004 2:36 PM, came the following characters from the keyboard of Laurent ROCHER: > New changes on CVS : Hi Laurent, You've been putting some many nice new features out lately, I thought I should bite the bullet, and try again to move my code to the NEM. "The bullet" seemed to need to include getting the code from CVS, to get all the new goodies, and I've been wanting to get my CVS set up for quite a while anyway, but just was trying not to spend that time.... Well, Tortoise CVS didn't seem to be a big problem, it seems to have done a checkout. But when I go to build things, then it won't compile. So with the same basic environment (compiler setup, VC++ 6.0, but different directory to build in), I can compile the last release of GUI. I don't know if I've missed something in CVS setup, or missed something somewhere else, or if it is code changes, but I get the following errors. As far as I can tell, the obvious things are OK: GUI.cpp #include GUI.h, and GUI.h #include winuser.h, and winuser.h is where WINDOWINFO is declared. But, the error makes it seem like it isn't declared. Any clues? cl -c -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1 -DVERSION=\"0.0.671\" -DXS_VERSION=\"0.0.671\" "-IC:\Perl\lib\CORE" GUI.cpp GUI.cpp *** Using Preserved Perl context. GUI.xs(1886) : warning C4101: 'targ' : unreferenced local variable GUI.xs(2179) : error C2065: 'WINDOWINFO' : undeclared identifier GUI.xs(2179) : error C2146: syntax error : missing ';' before identifier 'pwi' GUI.xs(2179) : error C2065: 'pwi' : undeclared identifier GUI.xs(2181) : error C2228: left of '.cbSize' must have class/struct/union type GUI.xs(2182) : error C2065: 'GetWindowInfo' : undeclared identifier GUI.xs(2184) : error C2228: left of '.rcClient' must have class/struct/union type GUI.xs(2184) : error C2228: left of '.left' must have class/struct/union type GUI.xs(2185) : error C2228: left of '.rcClient' must have class/struct/union type GUI.xs(2185) : error C2228: left of '.top' must have class/struct/union type GUI.xs(2186) : error C2228: left of '.rcClient' must have class/struct/union type GUI.xs(2186) : error C2228: left of '.right' must have class/struct/union type GUI.xs(2187) : error C2228: left of '.rcClient' must have class/struct/union type GUI.xs(2187) : error C2228: left of '.bottom' must have class/struct/union type *** PACKAGE Win32::GUI::Menu... *** PACKAGE Win32::GUI::MenuButton... *** PACKAGE Win32::GUI::MenuItem... NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. -- 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-04-12 17:34:23
|
Hi, You can add #define WINVER 0x0501 in you gui.h for this problem but you need to download and install last microsoft SDK for other problem. see: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm You need Core SDK Build environment (31 mb). It's a huge download. If you want i can make a zip with only include and lib directory (7mo). Laurent > On approximately 4/8/2004 2:36 PM, came the following characters from > the keyboard of Laurent ROCHER: > > New changes on CVS : > > Hi Laurent, You've been putting some many nice new features out lately, > I thought I should bite the bullet, and try again to move my code to the > NEM. "The bullet" seemed to need to include getting the code from CVS, > to get all the new goodies, and I've been wanting to get my CVS set up > for quite a while anyway, but just was trying not to spend that time.... > > Well, Tortoise CVS didn't seem to be a big problem, it seems to have > done a checkout. > > But when I go to build things, then it won't compile. So with the same > basic environment (compiler setup, VC++ 6.0, but different directory to > build in), I can compile the last release of GUI. I don't know if I've > missed something in CVS setup, or missed something somewhere else, or if > it is code changes, but I get the following errors. As far as I can > tell, the obvious things are OK: GUI.cpp #include GUI.h, and GUI.h > #include winuser.h, and winuser.h is where WINDOWINFO is declared. But, > the error makes it seem like it isn't declared. > > Any clues? > > cl -c -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE > -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT > -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG > -O1 -DVERSION=\"0.0.671\" -DXS_VERSION=\"0.0.671\" > "-IC:\Perl\lib\CORE" GUI.cpp > GUI.cpp > > *** Using Preserved Perl context. > > GUI.xs(1886) : warning C4101: 'targ' : unreferenced local variable > GUI.xs(2179) : error C2065: 'WINDOWINFO' : undeclared identifier > GUI.xs(2179) : error C2146: syntax error : missing ';' before identifier > 'pwi' > GUI.xs(2179) : error C2065: 'pwi' : undeclared identifier > GUI.xs(2181) : error C2228: left of '.cbSize' must have > class/struct/union type > GUI.xs(2182) : error C2065: 'GetWindowInfo' : undeclared identifier > GUI.xs(2184) : error C2228: left of '.rcClient' must have > class/struct/union type > GUI.xs(2184) : error C2228: left of '.left' must have class/struct/union > type > GUI.xs(2185) : error C2228: left of '.rcClient' must have > class/struct/union type > GUI.xs(2185) : error C2228: left of '.top' must have class/struct/union type > GUI.xs(2186) : error C2228: left of '.rcClient' must have > class/struct/union type > GUI.xs(2186) : error C2228: left of '.right' must have > class/struct/union type > GUI.xs(2187) : error C2228: left of '.rcClient' must have > class/struct/union type > GUI.xs(2187) : error C2228: left of '.bottom' must have > class/struct/union type > *** PACKAGE Win32::GUI::Menu... > *** PACKAGE Win32::GUI::MenuButton... > *** PACKAGE Win32::GUI::MenuItem... > NMAKE : fatal error U1077: 'cl' : return code '0x2' > Stop. > |
From: Laurent R. <ro...@cl...> - 2004-04-17 08:36:44
|
New changes on CVS : Changelog : Add new options and documentation. - Button.xs : + Add new style option and documentation. - Combobox.xs + Add new style option and documentation. - Header.xs + Add new style option and documentation. - GUI_Helper.cpp : + CreateObjectWithHandle : Fix memory leak - GUI.pm : + Add documentation. - Label.xs : + Add new option. - Rebar.xs : + Add new option. - Trackbar.xs : + Add documentation. - Window.xs : + Add documentation. Laurent. |
From: Glenn L. <pe...@ne...> - 2004-04-18 23:36:01
|
Hi Laurent, I got the compile working with the new SDK variables set up. (Lots of other stuff going on, so slow progress. Nice to have CVS set up so I can easily pick up and compile the latest changes now). So my first step was to test the new GUI, with a functioning OEM script. It failed. Upon investigation, it seems that one used to be able to make a new window $mw = Win32::GUI::Window->new( -name => 'Main', ... ); and then add a button $but = $mw->AddButton( -name => 'b_nl', ..., -width => 24, ... ); And then do things like print "but-width: $but->{'-width'}\n"; and get back the 24. Now this always seemed very mysterious to me, because there was no data member of the hash referenced by $but named '-width'. However, when I had found the %TwoWayMethodMap in gui.pm which contained "-width" as one of the entries, I convinced myself that this "fashionable" but not understood technique was how the sort of print statement above could work. Unfortunately, the above code sequence doesn't work on the latest CVS version. The print statement just prints "but-width:" without the 24 :( So we need to decide if this is something we want to have keep working, so that we can stay "fashionable". Clearly, I could call Width() directly, but the borrowed code would need significant modification, because is uses many of the fashionable techniques! The item below is clearly an internal, but I am less sure whether the above behavior should be considered internal or external. So I also noticed that the object types got renumbered to remove the gap after WIN32__GUI__DIALOG ... some code I'd borrowed had also depended on that, but since it was just discriminating between WINDOW & DIALOG and "all the rest", I could simply change the "> 10" test to "> 1", and that works for all versions of Win32::GUI. On approximately 4/12/2004 10:32 AM, came the following characters from the keyboard of Laurent ROCHER: > Hi, > > You can add #define WINVER 0x0501 in you gui.h for this problem but you need > to download and install last microsoft SDK for other problem. > > see: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm > > You need Core SDK Build environment (31 mb). > It's a huge download. > If you want i can make a zip with only include and lib directory (7mo). > > Laurent > > > > >>On approximately 4/8/2004 2:36 PM, came the following characters from >>the keyboard of Laurent ROCHER: >> >>>New changes on CVS : >> >>Hi Laurent, You've been putting some many nice new features out lately, >>I thought I should bite the bullet, and try again to move my code to the >>NEM. "The bullet" seemed to need to include getting the code from CVS, >>to get all the new goodies, and I've been wanting to get my CVS set up >>for quite a while anyway, but just was trying not to spend that time.... >> >>Well, Tortoise CVS didn't seem to be a big problem, it seems to have >>done a checkout. >> >>But when I go to build things, then it won't compile. So with the same >>basic environment (compiler setup, VC++ 6.0, but different directory to >>build in), I can compile the last release of GUI. I don't know if I've >>missed something in CVS setup, or missed something somewhere else, or if >>it is code changes, but I get the following errors. As far as I can >>tell, the obvious things are OK: GUI.cpp #include GUI.h, and GUI.h >>#include winuser.h, and winuser.h is where WINDOWINFO is declared. But, >>the error makes it seem like it isn't declared. >> >>Any clues? >> >>cl -c -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE >>-DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT >>-DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG >>-O1 -DVERSION=\"0.0.671\" -DXS_VERSION=\"0.0.671\" >>"-IC:\Perl\lib\CORE" GUI.cpp >>GUI.cpp >> >>*** Using Preserved Perl context. >> >>GUI.xs(1886) : warning C4101: 'targ' : unreferenced local variable >>GUI.xs(2179) : error C2065: 'WINDOWINFO' : undeclared identifier >>GUI.xs(2179) : error C2146: syntax error : missing ';' before identifier >>'pwi' >>GUI.xs(2179) : error C2065: 'pwi' : undeclared identifier >>GUI.xs(2181) : error C2228: left of '.cbSize' must have >>class/struct/union type >>GUI.xs(2182) : error C2065: 'GetWindowInfo' : undeclared identifier >>GUI.xs(2184) : error C2228: left of '.rcClient' must have >>class/struct/union type >>GUI.xs(2184) : error C2228: left of '.left' must have class/struct/union >>type >>GUI.xs(2185) : error C2228: left of '.rcClient' must have >>class/struct/union type >>GUI.xs(2185) : error C2228: left of '.top' must have class/struct/union > > type > >>GUI.xs(2186) : error C2228: left of '.rcClient' must have >>class/struct/union type >>GUI.xs(2186) : error C2228: left of '.right' must have >>class/struct/union type >>GUI.xs(2187) : error C2228: left of '.rcClient' must have >>class/struct/union type >>GUI.xs(2187) : error C2228: left of '.bottom' must have >>class/struct/union type >>*** PACKAGE Win32::GUI::Menu... >>*** PACKAGE Win32::GUI::MenuButton... >>*** PACKAGE Win32::GUI::MenuItem... >>NMAKE : fatal error U1077: 'cl' : return code '0x2' >>Stop. >> > > > > > ------------------------------------------------------- > 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 > > > -- 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-04-19 15:19:35
|
Hi, Yes, you right, i break TIED window property. You can reactivate it by changing in _new methods : my $self = tie %tier, $class, $oself; By : tie %tier, $class, $oself; my $self = bless \%tier, $class; I mode this change when i want to add Window destruuction when undef a perl window reference. But, i have trouble when this feature is activated. You can replace hard coded window type constant by Win32::GUI::constant("WIN32__GUI__DIALOG", 0). Laurent > Hi Laurent, > > I got the compile working with the new SDK variables set up. (Lots of > other stuff going on, so slow progress. Nice to have CVS set up so I > can easily pick up and compile the latest changes now). > > So my first step was to test the new GUI, with a functioning OEM script. > It failed. > > Upon investigation, it seems that one used to be able to make a new window > > $mw = Win32::GUI::Window->new( -name => 'Main', ... ); > > and then add a button > > $but = $mw->AddButton( -name => 'b_nl', ..., -width => 24, ... ); > > And then do things like > > print "but-width: $but->{'-width'}\n"; > > and get back the 24. > > Now this always seemed very mysterious to me, because there was no data > member of the hash referenced by $but named '-width'. However, when I > had found the %TwoWayMethodMap in gui.pm which contained "-width" as one > of the entries, I convinced myself that this "fashionable" but not > understood technique was how the sort of print statement above could work. > > Unfortunately, the above code sequence doesn't work on the latest CVS > version. The print statement just prints "but-width:" without the 24 :( > So we need to decide if this is something we want to have keep working, > so that we can stay "fashionable". > > Clearly, I could call Width() directly, but the borrowed code would need > significant modification, because is uses many of the fashionable > techniques! > > The item below is clearly an internal, but I am less sure whether the > above behavior should be considered internal or external. > > So I also noticed that the object types got renumbered to remove the gap > after WIN32__GUI__DIALOG ... some code I'd borrowed had also depended on > that, but since it was just discriminating between WINDOW & DIALOG and > "all the rest", I could simply change the "> 10" test to "> 1", and that > works for all versions of Win32::GUI. > |
From: Glenn L. <pe...@ne...> - 2004-04-19 16:09:39
|
Thanks for the quick response... I'm off camping for the rest of the week but I'll play with this some when I get back. So one would think that an appropriate "untie" would be possible, to allow Window destruction. On approximately 4/19/2004 8:17 AM, came the following characters from the keyboard of Laurent ROCHER: > Hi, > > Yes, you right, i break TIED window property. > You can reactivate it by changing in _new methods : > my $self = tie %tier, $class, $oself; > By : > tie %tier, $class, $oself; > my $self = bless \%tier, $class; > > I mode this change when i want to add Window destruuction when undef a perl > window reference. > But, i have trouble when this feature is activated. > > You can replace hard coded window type constant by > Win32::GUI::constant("WIN32__GUI__DIALOG", 0). > > Laurent > > > >>Hi Laurent, >> >>I got the compile working with the new SDK variables set up. (Lots of >>other stuff going on, so slow progress. Nice to have CVS set up so I >>can easily pick up and compile the latest changes now). >> >>So my first step was to test the new GUI, with a functioning OEM script. >> It failed. >> >>Upon investigation, it seems that one used to be able to make a new window >> >> $mw = Win32::GUI::Window->new( -name => 'Main', ... ); >> >>and then add a button >> >> $but = $mw->AddButton( -name => 'b_nl', ..., -width => 24, ... ); >> >>And then do things like >> >> print "but-width: $but->{'-width'}\n"; >> >>and get back the 24. >> >>Now this always seemed very mysterious to me, because there was no data >>member of the hash referenced by $but named '-width'. However, when I >>had found the %TwoWayMethodMap in gui.pm which contained "-width" as one >>of the entries, I convinced myself that this "fashionable" but not >>understood technique was how the sort of print statement above could work. >> >>Unfortunately, the above code sequence doesn't work on the latest CVS >>version. The print statement just prints "but-width:" without the 24 :( >>So we need to decide if this is something we want to have keep working, >>so that we can stay "fashionable". >> >>Clearly, I could call Width() directly, but the borrowed code would need >>significant modification, because is uses many of the fashionable >>techniques! >> >>The item below is clearly an internal, but I am less sure whether the >>above behavior should be considered internal or external. >> >>So I also noticed that the object types got renumbered to remove the gap >>after WIN32__GUI__DIALOG ... some code I'd borrowed had also depended on >>that, but since it was just discriminating between WINDOW & DIALOG and >>"all the rest", I could simply change the "> 10" test to "> 1", and that >>works for all versions of Win32::GUI. >> > > > > > -- 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-04-26 16:42:25
|
Hi All, I commit new changes. - Window properties now re-work. - Handle correctly Window life and Perl variable life (i hope it work because i loose my hair on it ;o) - Add MDI window support (3 new class MDIFrame, MDIClient and MDIChild). For MDI, i have add a sample in Samples directory. It's work but one stuff don't work as expected :-( I have a trouble with menu identifer when try to add a window menu to MDIClient. It's use 0 based identifier for window child menu item but not assigned default MDIChild identifier. So, i have a conflict with standard menu item. Need to investigate ... Laurent. Changelog : Add MDI Window Support and Fix Tied property & Window Destruction. - GUI.h : + Added new MDI Constants and Callback functions. + Added a dwData field in PERLWIN32GUI_USERDATA. - GUI.pm : + _new : Fix tied hash property. + Comment AUTOLOAD in Win32::GUI::Window : Is usefull ? + New Win32::GUI::MDIFrame, Win32::GUI::MDIClient, Win32::GUI::MDIChild class. + Win32::GUI::WindowProps : Fix Destroy managing. + Register new class for MDI. - GUI.xs : + In GetKeyboardState : Use a stack array for key. + In RegisterClassEx : + Added MDIFrame, MDIClient, MDIChild widget option. + Avoid reccursive Window Msg Loop call. + In Create : + Use a weaken reference for perlpud->SvSelf for clean reference count and memory free. + Added MDI support. + Added dwData field support. + In Change : Added MDI support. + In Dialog, DoEvents, DoModal : Added MDI event loop support. + LockWindowUpdate : Rewrite shorter. - GUI_Constants.cpp : + Added MDI class constants. - GUI_Helpers.cpp : + Addes MDI class callback. + Perlud_Free : Correct destruction problem. - GUI_MessageLoops.cpp : + In CommonMsgLoop : Don't manage WM_GETMINMAXINFO for MDI Child. + In WindowMsgLoop : + Added support for WndProc call. + For WM_DESTROY, call default MsgLoop before free perlud. + Handle WM_MDIACTIVATE & WM_SETFOCUS for MDI Window. + Added DefMDIFrameLoop and MDIFrameMsgLoop for MDIFrame Window. + Added MDIClientMsgLoop for MDICLient window. + Added DefMDIChildLoop and MDIChildMsgLoop for MDIChild Window. - GUI_Options.cpp : + In ParseWindowOptions : Added a missing else for class specific option parsing. - Makefile.pl & Makefile_m.pl : Add new MDI.xs file. - MDI.xs : Manage MDI window. - Window.xs : Remove MDI class and add MDI event documentation. - Samples\MDI.pl : New Sample form MDI use. - Docs\DoDoc.pl : Add new MDI.xs file. |
From: Laurent R. <ro...@cl...> - 2004-04-26 21:44:26
|
Hi I restore AUTOLOAD sub in Win32::GUI::Window. I understand now what this sub do. It's permit to directly call a child window procedure like this : $Win->Child->Show; it's do same job as : $Win->{Child}->Show; ChangeLog : Restore AUTOLOAD - GUI.pm : + Uncomment AUTOLOAD + Add AUTOLOAD to MDIFrame, MDIClient. Laurent |
From: Laurent R. <ro...@cl...> - 2004-04-30 18:11:53
|
Hi all, I have commit fix for problem with MDiClient and Menu ID for child. I update MDI.pl sample too for show how add Window Child menuitem to mainframe menu. ChangeLog : Fix IdFirstChild option for MDIClient. - GUI.pm : + Remove registered class for MDIClient. - GUI.xs : + RegisterClassEx : Remove MDIClient value for -widget option. + Create : SubClass MDIClient window. + Added SetActiveWindow. - GUI_MessageLoops.cpp : + MDIClientMsgLoop: Rewrite as simple subclass MsgLoop. - MDI.xs : + MDIClient_onPreCreate : Change classname. + MDIChild_onPreCreate : Change default style. Laurent. |
From: Laurent R. <ro...@cl...> - 2004-05-08 17:40:37
|
Hi all, I commit new stuff on CVS - Add MonthCal control - Fix TextField -prompt option ChangeLog : + [Laurent Rocher] : Add MonthCal Control - MonthCall.xs : New file - GUI.h : + Add new event argtype for SV*. + New MonthCall control callback function and constant. - GUI.pm : + Add MonthCall control. - GUI_Constants.cpp : + Add MonthCall class constant. - GUI_Events.cpp : + DoEvent : Add new type argument for SV*. - GUI_Helpers.cpp : + Add MonthCall control. - Makefile.pl, Makefile_m.pl : + Add MonthCall.xs - Samples\MonthCal.pl : New file - Docs\DoDoc.pl : + Add MonthCall.xs + [Steven M. Martin] : Fix TextField -prompt option. - GUI.pm : + Win32::GUI::Textfield new : Fix TextField -prompt option when prompt left was negative. Laurent. |
From: Glenn L. <pe...@ne...> - 2004-04-27 02:14:22
|
On approximately 4/26/2004 9:40 AM, came the following characters from the keyboard of Laurent ROCHER: > Hi All, > > I commit new changes. > - Window properties now re-work. Good :) :) > - Handle correctly Window life and Perl variable life > (i hope it work because i loose my hair on it ;o) > - Add MDI window support (3 new class MDIFrame, MDIClient and > MDIChild). > > For MDI, i have add a sample in Samples directory. This sounds good, and looks good. Unfortunately, not compatible with old Win32::GUI::MDI. I wonder if there is any way to have the added functionality you are producing, and still be compatible with the old code. My old code was: # MDI window $mdi_window = Win32::GUI::MDI->new ( -name => 'mdi_window', -parent => $mw, -text => 'MDI', -top => 0, -left => 0, -width => $mwsw, -height => $mwsh - 40, -visible => 1, ); if ( ! $mdi_window ) { GUtil::demise( "MDI creation error: $^E\n" ); } # label_bitmap inside MDI window $label_bitmap = $mdi_window->AddLabel( -name => 'label_bitmap', -bitmap => 1, -left => 0, -top => 0, -width => $mwsw - 40, -height => $mwsh - 40, -tip => 'list display area', ); The interesting feature is that the label is automatically resized when you insert a different bitmap via later calles like $label_bitmap->SetImage ( $bitmap ); The size is taken from the $bitmap image content. But by being within an MDI window, scroll bars were automatically added to that window so that the whole bitmap could be viewed when it is bigger than the containing MDI window, and the scroll bars would go away when the bitmap was smaller than the containing MDI window. And no other code was needed to achieve it. Probably I was using Win32::GUI::MDI for an inappropriate usage. This is all code that I wrote, and I am willing to rework it, but some ideas on how I should best do such a thing would be appreciated. The basic goal is a scrollable, fixed size container for a dynamically sized bitmap. Showing it via a label is not particularly necessary, but that seems to be convenient. One thing I didn't like about my above implementation is that I hadn't figured out how to control the scroll bars via API calls at all, to choose which part of the image was showing. The user could scroll at will, however. I'm not sure whether the old Win32::GUI::MDI corresponds more directly to the new MDIFrame or the MDIClient, or whether one must always have an MDIClient and MDIChild inside an MDIFrame, or just can put a label directly into an MDIFrame.... I tried substituting MDIFrame for MDI in my code above, and got a surprising error: Use of uninitialized value in substitution (s///) at GUI.pm line 1046. After uncommenting the debugging print statement in AUTOLOAD, I discover that it is failing to autoload a method named "-name" on Win32::GUI::MDIFrame, but not sure why. Well, I'll play a bit more, maybe you'll have some ideas of where I should look. > It's work but one stuff don't work as expected :-( > I have a trouble with menu identifer when try to add a window menu to > MDIClient. This limit won't affect me, as I'm not using different menus for MDI windows. > It's use 0 based identifier for window child menu item but not assigned > default MDIChild identifier. > So, i have a conflict with standard menu item. Need to investigate ... > > Laurent. > > Changelog : Add MDI Window Support and Fix Tied property & Window > Destruction. > - GUI.h : > + Added new MDI Constants and Callback functions. > + Added a dwData field in PERLWIN32GUI_USERDATA. > - GUI.pm : > + _new : Fix tied hash property. > + Comment AUTOLOAD in Win32::GUI::Window : Is usefull ? > + New Win32::GUI::MDIFrame, Win32::GUI::MDIClient, > Win32::GUI::MDIChild class. > + Win32::GUI::WindowProps : Fix Destroy managing. > + Register new class for MDI. > - GUI.xs : > + In GetKeyboardState : Use a stack array for key. > + In RegisterClassEx : > + Added MDIFrame, MDIClient, MDIChild widget option. > + Avoid reccursive Window Msg Loop call. > + In Create : > + Use a weaken reference for perlpud->SvSelf for clean reference > count and memory free. > + Added MDI support. > + Added dwData field support. > + In Change : Added MDI support. > + In Dialog, DoEvents, DoModal : Added MDI event loop support. > + LockWindowUpdate : Rewrite shorter. > - GUI_Constants.cpp : > + Added MDI class constants. > - GUI_Helpers.cpp : > + Addes MDI class callback. > + Perlud_Free : Correct destruction problem. > - GUI_MessageLoops.cpp : > + In CommonMsgLoop : Don't manage WM_GETMINMAXINFO for MDI Child. > + In WindowMsgLoop : > + Added support for WndProc call. > + For WM_DESTROY, call default MsgLoop before free perlud. > + Handle WM_MDIACTIVATE & WM_SETFOCUS for MDI Window. > + Added DefMDIFrameLoop and MDIFrameMsgLoop for MDIFrame Window. > + Added MDIClientMsgLoop for MDICLient window. > + Added DefMDIChildLoop and MDIChildMsgLoop for MDIChild Window. > - GUI_Options.cpp : > + In ParseWindowOptions : Added a missing else for class specific > option parsing. > - Makefile.pl & Makefile_m.pl : Add new MDI.xs file. > - MDI.xs : Manage MDI window. > - Window.xs : Remove MDI class and add MDI event documentation. > - Samples\MDI.pl : New Sample form MDI use. > - Docs\DoDoc.pl : Add new MDI.xs file. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > Perl-Win32-GUI-Hackers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers > > > -- 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. |