fxruby users - Apr 2007 - mdiclient windows do not always activate on click

I just noticed that MDIClient windows do not automatically become 
current when they receive a mouse click, but only do so if the click 
happens inside of an enabled widget. This may very well be correct, but 
if so then what is the right way to handle it, if you want a more 
familiar window-manager behavior (click to focus)?

For example, if you change the mditest.rb example like so...

--- mditest.rb  2007-04-18 16:19:59.000000000 -0700
+++ mdi.rb      2007-04-27 14:44:54.000000000 -0700
@@ -134,7 +134,7 @@
      scrollwindow = FXScrollWindow.new(mdichild, 0)
      scrollwindow.verticalScrollBar.setLine(@font.fontHeight)
      btn = FXButton.new(scrollwindow, TYGER,
-      :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width => 600, 
:height => 1000)
+      :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width => 100, 
:height => 100)
      btn.font = @font
      btn.backColor = FXColor::White
      mdichild


...and then click on the empty area within one of the windows behind the 
active child, then that window will not be made active.

However, adding the line

     scrollwindow.enabled = true

makes the behavior feel more normal (to me).

Is there any drawback to enabling things like scroll windows (probably 
also frames and matrixes, but I haven''t tried them)?

Is there a better way to handle this?

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Joel VanderWerf wrote:
> I just noticed that MDIClient windows do not automatically become 
> current when they receive a mouse click, but only do so if the click 
> happens inside of an enabled widget. This may very well be correct, but 
> if so then what is the right way to handle it, if you want a more 
> familiar window-manager behavior (click to focus)?
> 
> For example, if you change the mditest.rb example like so...
> 
> --- mditest.rb  2007-04-18 16:19:59.000000000 -0700
> +++ mdi.rb      2007-04-27 14:44:54.000000000 -0700
> @@ -134,7 +134,7 @@
>       scrollwindow = FXScrollWindow.new(mdichild, 0)
>       scrollwindow.verticalScrollBar.setLine(@font.fontHeight)
>       btn = FXButton.new(scrollwindow, TYGER,
> -      :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width => 600, 
> :height => 1000)
> +      :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width => 100, 
> :height => 100)
>       btn.font = @font
>       btn.backColor = FXColor::White
>       mdichild
> 
> 
> ...and then click on the empty area within one of the windows behind the 
> active child, then that window will not be made active.
> 
> However, adding the line
> 
>      scrollwindow.enabled = true
> 
> makes the behavior feel more normal (to me).
> 
> Is there any drawback to enabling things like scroll windows (probably 
> also frames and matrixes, but I haven''t tried them)?
> 
> Is there a better way to handle this?
> 
Here''s a candidate. In the FXMDIChild''s create method, enable
the
content window (which I guess is everything but the title bar and 
border), and handle mousedown:

   def create(*)
     super
     contentWindow.enable
     contentWindow.connect(SEL_LEFTBUTTONPRESS) do
       parent.setActiveChild self
       false
     end
   end

Unfortunately, a mouse click in (for example) a label inside of the 
content window doesn''t get caught this way. Still looking for something
better...

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

Joel VanderWerf wrote:
> Joel VanderWerf wrote:
>> I just noticed that MDIClient windows do not automatically become 
>> current when they receive a mouse click, but only do so if the click 
>> happens inside of an enabled widget. This may very well be correct, but
>> if so then what is the right way to handle it, if you want a more 
>> familiar window-manager behavior (click to focus)?
>>
>> For example, if you change the mditest.rb example like so...
>>
>> --- mditest.rb  2007-04-18 16:19:59.000000000 -0700
>> +++ mdi.rb      2007-04-27 14:44:54.000000000 -0700
>> @@ -134,7 +134,7 @@
>>       scrollwindow = FXScrollWindow.new(mdichild, 0)
>>       scrollwindow.verticalScrollBar.setLine(@font.fontHeight)
>>       btn = FXButton.new(scrollwindow, TYGER,
>> -      :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width =>
600,
>> :height => 1000)
>> +      :opts => LAYOUT_FIX_WIDTH|LAYOUT_FIX_HEIGHT, :width =>
100,
>> :height => 100)
>>       btn.font = @font
>>       btn.backColor = FXColor::White
>>       mdichild
>>
>>
>> ...and then click on the empty area within one of the windows behind
the
>> active child, then that window will not be made active.
>>
>> However, adding the line
>>
>>      scrollwindow.enabled = true
>>
>> makes the behavior feel more normal (to me).
>>
>> Is there any drawback to enabling things like scroll windows (probably 
>> also frames and matrixes, but I haven''t tried them)?
>>
>> Is there a better way to handle this?
>>
> 
> Here''s a candidate. In the FXMDIChild''s create method,
enable the
> content window (which I guess is everything but the title bar and 
> border), and handle mousedown:
> 
>    def create(*)
>      super
>      contentWindow.enable
>      contentWindow.connect(SEL_LEFTBUTTONPRESS) do
>        parent.setActiveChild self
>        false
>      end
>    end
> 
> Unfortunately, a mouse click in (for example) a label inside of the 
> content window doesn''t get caught this way. Still looking for
something
> better...
And here''s an update on getting click-to-focus to work in MDI land...

The workaround above isn''t quite right, since it enables too many 
windows, and the connect(SEL_LEFTBUTTONPRESS) seems to interfere with 
the ability of FXTable''s scrollbars to scroll the table (I''m
not sure
why, because I do return false).

Anyway, the latest workaround is:

   def create(*)
     super

     pr = proc do |w|
       case w
       when FXComposite, FXLabel
         w.enable
         w.connect(SEL_LEFTBUTTONPRESS) do
           parent.setActiveChild self
           self.setFocus
           false
         end
       end
     end

     pr[contentWindow]
     contentWindow.each_child_recursive do |ch|
       pr[ch]
     end
   end

Is there a more elegant solution? My guess: The source of the problem is 
that I am expecting MDIClient to behave like a window manager, which 
would have focus policy options, like click-to-focus. Possible solutions:

1. MDIClient has a new option for focus policy, and, if CLICK_TO_FOCUS 
is set, then clicking in a child window sends SEL_CHANGED to the 
MDICLient and doesn''t send the message to the child.

2. Another message, SEL_CLICK_INACTIVE or something, is sent to the 
MDIClient only when an inactive part of a child is clicked. The 
MDIClient can choose to activate the window, ignore the message, etc.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407