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.
>