From: Laurent R. <ro...@cl...> - 2004-04-27 18:26:06
|
Hi, I remove Win32::GUI::MDI because it's current implementation not = realy permit to use it in an MDI application context.=20 I don't think anyone use this class ;o) And, i don't know this usage = too. I can restore old Win32::GUI::MDI class. But, this class name = probably confuse user for create MDI application. Win32::GUI::MDI use same window class than Win32::GUI::MDIClient. You can replace Win32::GUI::MDI with a Win32::GUI::MDIClient but = AddLablel method don't exist for this class.=20 It's only have a AddChild. And this class it's not same as a = Win32::GUI::Window like Win32::GUI::MDI. For compatibility, i think you can replace Win32::GUI::MDI by = something like that : $mdi_window =3D Win32::GUI::Window->new ( -remstyle =3D> WS_OVERLAPPEDWINDOW, -addstyle =3D> WS_VISIBLE | WS_CHILD | WS_CLIPCHILDREN | WS_VSCROLL = | WS_HSCROLL, -classname =3D> 'MDICLIENT', -name =3D> 'mdi_window', -parent =3D> $mw, -text =3D> 'MDI', -top =3D> 0, -left =3D> 0, -width =3D> $mwsw, -height =3D> $mwsh - 40, ); Laurent. > On approximately 4/26/2004 9:40 AM, came the following characters from > the keyboard of Laurent ROCHER: > > Hi All, > >=20 > > I commit new changes. > > - Window properties now re-work. >=20 > Good :) :) >=20 > > - 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). > >=20 > > For MDI, i have add a sample in Samples directory. >=20 > This sounds good, and looks good. Unfortunately, not compatible with=20 > old Win32::GUI::MDI. I wonder if there is any way to have the added=20 > functionality you are producing, and still be compatible with the old=20 > code. My old code was: >=20 > # MDI window >=20 > $mdi_window =3D Win32::GUI::MDI->new ( > -name =3D> 'mdi_window', > -parent =3D> $mw, > -text =3D> 'MDI', > -top =3D> 0, -left =3D> 0, > -width =3D> $mwsw, -height =3D> $mwsh - 40, > -visible =3D> 1, > ); > if ( ! $mdi_window ) > { GUtil::demise( "MDI creation error: $^E\n" ); > } >=20 > # label_bitmap inside MDI window >=20 > $label_bitmap =3D $mdi_window->AddLabel( > -name =3D> 'label_bitmap', > -bitmap =3D> 1, > -left =3D> 0, -top =3D> 0, -width =3D> $mwsw - 40, -height =3D> = $mwsh - 40, > -tip =3D> 'list display area', > ); >=20 > The interesting feature is that the label is automatically resized = when=20 > you insert a different bitmap via later calles like >=20 > $label_bitmap->SetImage ( $bitmap ); >=20 > 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=20 > that the whole bitmap could be viewed when it is bigger than the=20 > containing MDI window, and the scroll bars would go away when the = bitmap=20 > was smaller than the containing MDI window. And no other code was=20 > needed to achieve it. >=20 > 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=20 > on how I should best do such a thing would be appreciated. >=20 > The basic goal is a scrollable, fixed size container for a dynamically = > sized bitmap. Showing it via a label is not particularly necessary, = but=20 > that seems to be convenient. >=20 > 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=20 > choose which part of the image was showing. The user could scroll at=20 > will, however. >=20 > 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=20 > MDIClient and MDIChild inside an MDIFrame, or just can put a label=20 > directly into an MDIFrame.... >=20 > I tried substituting MDIFrame for MDI in my code above, and got a=20 > surprising error: >=20 > Use of uninitialized value in substitution (s///) at GUI.pm line 1046. >=20 > After uncommenting the debugging print statement in AUTOLOAD, I = discover=20 > that it is failing to autoload a method named "-name" on=20 > Win32::GUI::MDIFrame, but not sure why. >=20 > Well, I'll play a bit more, maybe you'll have some ideas of where I=20 > should look. >=20 |
From: Glenn L. <pe...@ne...> - 2004-04-27 22:30:58
|
On approximately 4/27/2004 11:24 AM, came the following characters from the keyboard of Laurent ROCHER: > Hi, > > I remove Win32::GUI::MDI because it's current implementation not > realy permit to use it in an MDI application context. > I don't think anyone use this class ;o) And, i don't know this > usage too. Yes, I did get the idea when I started using Win32::GUI::MDI that it wasn't "true" MDI. > I can restore old Win32::GUI::MDI class. But, this class name > probably confuse user for create MDI application. I wonder if restoring it under a different name would cause problems? It would provide a migration path, albeit, an incompatible change. But if we can find a work-alike, then there is no need to add the class back. Or it would be nice to document the work-alike if we can find it. > Win32::GUI::MDI use same window class than Win32::GUI::MDIClient. > You can replace Win32::GUI::MDI with a Win32::GUI::MDIClient but > AddLablel method don't exist for this class. > It's only have a AddChild. And this class it's not same as a > Win32::GUI::Window like Win32::GUI::MDI. > > For compatibility, i think you can replace Win32::GUI::MDI by > something like that : > > $mdi_window = Win32::GUI::Window->new ( > -remstyle => WS_OVERLAPPEDWINDOW, > -addstyle => WS_VISIBLE | WS_CHILD | WS_CLIPCHILDREN | WS_VSCROLL | > WS_HSCROLL, > -classname => 'MDICLIENT', > -name => 'mdi_window', > -parent => $mw, > -text => 'MDI', > -top => 0, -left => 0, > -width => $mwsw, -height => $mwsh - 40, > ); This is much closer than anything I found. But: The scroll bars appear immediately (but maybe that's just because I need to juggle some sizes that might be a little different than the old class). But after playing some more, I don't think that was it. The scroll bars seem to be "stuck" at the top left... attempting to drag them to see other parts of the window fails, they jump back to the top left. Removing WS_CLIPCHILDREN produced no discernible difference. Removing the WS_VSCROLL and WS_HSCROLL eliminated the inital scroll bars, but it actually eliminated them completely :( -- 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-05-14 03:26:57
|
On approximately 4/27/2004 3:32 PM, came the following characters from the keyboard of Glenn Linderman: > On approximately 4/27/2004 11:24 AM, came the following characters from > the keyboard of Laurent ROCHER: > >> Hi, >> >> I remove Win32::GUI::MDI because it's current implementation not >> realy permit to use it in an MDI application context. I don't >> think anyone use this class ;o) And, i don't know this usage too. > > > Yes, I did get the idea when I started using Win32::GUI::MDI that it > wasn't "true" MDI. > >> I can restore old Win32::GUI::MDI class. But, this class name >> probably confuse user for create MDI application. > > > I wonder if restoring it under a different name would cause problems? It > would provide a migration path, albeit, an incompatible change. But if > we can find a work-alike, then there is no need to add the class back. > Or it would be nice to document the work-alike if we can find it. Well, I see that there is really very little code in Win32::GUI to support the old Win32::GUI::MDI class. But it must be very magic code, because I haven't found a way to make it out of what is presently in the CVS. >> Win32::GUI::MDI use same window class than Win32::GUI::MDIClient. >> You can replace Win32::GUI::MDI with a Win32::GUI::MDIClient but >> AddLablel method don't exist for this class. >> It's only have a AddChild. And this class it's not same as a >> Win32::GUI::Window like Win32::GUI::MDI. >> >> For compatibility, i think you can replace Win32::GUI::MDI by >> something like that : >> >> $mdi_window = Win32::GUI::Window->new ( >> -remstyle => WS_OVERLAPPEDWINDOW, >> -addstyle => WS_VISIBLE | WS_CHILD | WS_CLIPCHILDREN | WS_VSCROLL >> | WS_HSCROLL, >> -classname => 'MDICLIENT', >> -name => 'mdi_window', >> -parent => $mw, >> -text => 'MDI', >> -top => 0, -left => 0, >> -width => $mwsw, -height => $mwsh - 40, >> ); So when I try doing this, it sort of works, as I mentioned earlier (see below), but not quite enough to be able to use it. From perusing the code, the biggest difference that I can find is that during the window creation, the above code leaves perlcs.iclass as WIN32__GUI__WINDOW, making it susceptible to executing code in other places that is cased on perlcs.iclass ! Whereas when it had type WIN32__GUI__MDICLIENT then some of those cases didn't happen. At least, that is the best "educated guess" that I can come with. So, because I can't find a replacement, and it seems quite useful to my code, and for backward compatibility, could this MDICLIENT window type be reinstated in the source code? > This is much closer than anything I found. But: > > The scroll bars appear immediately (but maybe that's just because I need > to juggle some sizes that might be a little different than the old > class). But after playing some more, I don't think that was it. > > The scroll bars seem to be "stuck" at the top left... attempting to drag > them to see other parts of the window fails, they jump back to the top > left. > > Removing WS_CLIPCHILDREN produced no discernible difference. > > Removing the WS_VSCROLL and WS_HSCROLL eliminated the inital scroll > bars, but it actually eliminated them completely :( -- 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-04-27 22:42:17
|
I tried to add VERSION checking code to my application so I could easily keep it working under both old and new GUI versions... but the CVS currently identifies itself as 0.0.671. This is less than the older versions 0.0.680.... I think the CVS version should always be bigger than anything that was ever released.... I'd suggest 0.1.0 or 0.0.999 for the "latest CVS" at present, although a future release could still be 0.0.681 or more. Or we could use a technique similar to the perl releases.... odd numbers are "latest CVS" and releases are always even (henceforth). Under this theory, we would put 0.0.681 in the CVS, and the next release would be 0.0.682 ... as soon as the release is complete, the CVS would go to 0.0.683, etc. On approximately 4/27/2004 11:24 AM, came the following characters from the keyboard of Laurent ROCHER: > Hi, > > I remove Win32::GUI::MDI because it's current implementation not > realy permit to use it in an MDI application context. > I don't think anyone use this class ;o) And, i don't know this > usage too. > > I can restore old Win32::GUI::MDI class. But, this class name > probably confuse user for create MDI application. > > Win32::GUI::MDI use same window class than Win32::GUI::MDIClient. > You can replace Win32::GUI::MDI with a Win32::GUI::MDIClient but > AddLablel method don't exist for this class. > It's only have a AddChild. And this class it's not same as a > Win32::GUI::Window like Win32::GUI::MDI. > > For compatibility, i think you can replace Win32::GUI::MDI by > something like that : > > $mdi_window = Win32::GUI::Window->new ( > -remstyle => WS_OVERLAPPEDWINDOW, > -addstyle => WS_VISIBLE | WS_CHILD | WS_CLIPCHILDREN | WS_VSCROLL | > WS_HSCROLL, > -classname => 'MDICLIENT', > -name => 'mdi_window', > -parent => $mw, > -text => 'MDI', > -top => 0, -left => 0, > -width => $mwsw, -height => $mwsh - 40, > ); > > > Laurent. > > > 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. > > -- 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-29 18:41:50
|
> I tried to add VERSION checking code to my application so I could easily > keep it working under both old and new GUI versions... but the CVS > currently identifies itself as 0.0.671. This is less than the older > versions 0.0.680.... 0.0.680 ?? Don't know this version. > I think the CVS version should always be bigger than anything that was > ever released.... > > I'd suggest 0.1.0 or 0.0.999 for the "latest CVS" at present, > although a future release could still be 0.0.681 or more. > I actually change version number only when build a new release. But, it's probably better to upgrade CVS Version number always to next release version. I think MAIN CVS version can be upgrade to 0.1 (number for next release). Because, this version have lot of a new features and first step for a 1.0 release ;o) Laurent. |
From: Glenn L. <pe...@ne...> - 2004-04-29 20:39:39
|
Sounds fine. Just we need to do something to distinguish releases from "CVS builds". 0.0.680 seems to have found its way to my hard disk, from one of your builds... On approximately 4/29/2004 11:33 AM, came the following characters from the keyboard of Laurent ROCHER: > >>I tried to add VERSION checking code to my application so I could easily >>keep it working under both old and new GUI versions... but the CVS >>currently identifies itself as 0.0.671. This is less than the older >>versions 0.0.680.... > > > 0.0.680 ?? Don't know this version. > > >>I think the CVS version should always be bigger than anything that was >>ever released.... >> >>I'd suggest 0.1.0 or 0.0.999 for the "latest CVS" at present, >>although a future release could still be 0.0.681 or more. >> > > > I actually change version number only when build a new release. > But, it's probably better to upgrade CVS Version number always to next > release version. > > I think MAIN CVS version can be upgrade to 0.1 (number for next release). > Because, this version have lot of a new features and first step for a 1.0 > release ;o) > > 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: Laurent R. <ro...@cl...> - 2004-03-29 21:49:49
|
I add some add-on to DoModal method. - Prevent re-call DoModal on same dialog. - Add a parameter flag for disable all top window (By default only parent/active window is disable). And fix a problem with MinGW. Changelog : - GUI.h : + Add Animate_OpenEx macro for MinGW + Add a IS_MODAL dwPlStyle flag. + Add EnableWindowsProc callback. - GUI.xs : + DoModal() : - Return false if function already in DoModal. - Add a boolean parameter for disable all Top Window and not only parent/caller. - GUI_Helpers.cpp : + Add EnableWindowsProc : Activate or Deactivate current thread top window. - GUI.pm : + Remove Win32::GUI::Window::DESTROY because unnecessary and conflic with Win32::GUI::WindowProps. Laurent. |