Win32::GUI

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.

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

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";
}

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" <rocherl@...>
To: "Win32 GUI Hackers" <perl-win32-gui-hackers@...>
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
> Perl-Win32-GUI-Hackers@...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-hackers

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
> Perl-Win32-GUI-Hackers@...
> 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.

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" <rocherl@...>
> To: "Win32 GUI Hackers" <perl-win32-gui-hackers@...>
> 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
>>Perl-Win32-GUI-Hackers@...
>>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
> Perl-Win32-GUI-Hackers@...
> 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.

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!

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.

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.

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

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.

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.

New stuff on CVS :

Changelog : Complet Tooltip API.
    - GUI.h :
        + Add new prototype.
    - GUI_Options.cpp :
        + Add ParseTooltipOptions.
    - ToolTip.xs :
        + Complet API.

Laurent.

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.

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.

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

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.

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
> Perl-Win32-GUI-Hackers@...
> 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.

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

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.

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.

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

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
> Perl-Win32-GUI-Hackers@...
> 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.

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

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.

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.

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

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.

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.

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.

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.