Re: perltray/tk intercept windows minimize function

Regarding your problems with overlapping windows when using Maximize, 
All I can say is "Huh..." because I cannot duplicate the behavior that 
you're describing. It works exactly as I expect on my Window XP machine 
( Don't you just *hate* it when someone says that? ).

As for what Nick was saying, which part was not working? The way I 
understood it was that you should bind to an event that is triggered 
once the window has been minimized, and then call withdraw or whatever 
to hide the window.

my $mw = MainWindow->new;

$mw->bind('<Unmap>', sub {
   if (!$mw->viewable) {
      print "minimized\n";
      $mw->withdraw;
    }
 });

MainLoop;

The problem with the above is that the code in the if block get's called 
twice - once when the Window is minimized, and then again when it is 
withdrawn. Another approach might be:

my $mw = MainWindow->new;

$mw->bind('<FocusOut>', sub {
   if (!$mw->viewable) {
      print "minimized\n";
      $mw->withdraw;
    }
 });

MainLoop;

This should result in withdraw being called once, and doesn't seem to 
have any other side effects. As to whether or not it would fit in with 
your Perltray plans, I cannot say.

Rob







listmail wrote:
> I thought I had this one settled.
>
> The order of execution for Maximize within the code below causes the 
> window to be sized without regard to the width of the task bar.   Its 
> draws a portion of the window behind the task bar.  Its hard to see 
> this happening without some sort of bordering placed at the lower 
> extremities of the window like the one in my previous example.  You 
> can prove this by dragging the window upwards a little bit (by 
> grabbing the title bar) and noting that you still do not expose the 
> bottom edge from under the task bar.  It has something to do with 
> calling Win32::GUI::Maximize or Win32Util::maximize ~after~ the 
> alteration of the window style.  Sadly though,  previously  I thought 
> I had gotten around this by calling the maximize before the alteration 
> of the window style.  That does work and with using either the 
> Win32::GUI::Maximize or Win32Util::maximize subs, but then I found 
> that if you have to call maximize again (like after a deiconify 
> request) at some point, then it exhibits the same problem which I am 
> trying to avoid.
> I tried going back to my initial plans and implementing Nick's 
> suggestions with caching the minimize event, so I could just call a 
> withdraw, but I never could figure that out.  It would be nice to have 
> that feature someday, but it's definitely not a requirement.
>
>
>
> Rob Seegel wrote:
>> Whoops! I forgot the critical update call in the last two messages. 
>> Updated below.
>>
>> use Tk;
>> use Win32::GUI;
>>
>> my $mw = MainWindow->new;
>> $mw->update;  ## Important bit!
>>
>> my $winH = hex($mw->frame);
>> my $style = Win32::GUI::GetWindowLong($winH, -16);
>> $style &= ~(WS_MINIMIZEBOX | WS_MAXIMIZEBOX);
>> Win32::GUI::SetWindowLong($winH, -16, $style);
>> Win32::GUI::DrawMenuBar($winH);
>> Win32::GUI::Maximize($winH);
>>
>> MainLoop;
>>
>>
>> Rob Seegel wrote:
>>> As for maximize -- why not use Thundergnats solution? It seems to 
>>> work perfectly well for me. Below is the updated code...
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
>> This message was posted through the Stanford campus mailing list
>> server.  If you wish to unsubscribe from this mailing list, send the
>> message body of "unsubscribe ptk" to [email protected]
>>
>
>
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==
> This message was posted through the Stanford campus mailing list
> server.  If you wish to unsubscribe from this mailing list, send the
> message body of "unsubscribe ptk" to [email protected]
>
>


-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ptk" to [email protected]