Window Focus bug

[emaender]

Please see the code I've posted below. When this application loads, you can click on any one of the 3 buttons without a problem, with each button simply writing text to the debugger.

However, if you click and drag on one of the windows, you no longer get immediate focus on the other windows' button when you mouse over it. This results in the user needing to "double click" on the button to get it to function - an undesirable user experience. It looks like the window that has focus is preventing the other windows button from receiving the "onmouseover" event.

The button contained in the view at the top will work regardless of whether one of the windows currently has focus - leading me to believe the problem is in the Window component.

Is there a way to work around this? Thank you in advance for your help on this!

<canvas width="1000" height="1000" >

<debug x="390" />

<view bgcolor="0xc0c0c0" name="win1" x="10" y="1" width="200" height="200" >
<text>Hello 1</text>
<button name="test1" text="Test 1" onclick="debug.write('Test first window');">
</button>
<simplelayout />
</view>

<window name="win2" x="10" y="210" width="200" height="200"
resizable="true" closeable="true" >
<text>Hello 2</text>
<button name="test2" text="Test 2" onclick="debug.write('Test second window');" >
</button>
<simplelayout />
</window>

<window name="win3" x="210" y="210" width="200" height="200"
resizable="true" closeable="true" >
<text>Hello 3</text>
<button name="test3" text="Test 3" onclick="debug.write('Test third window');" >
</button>
<simplelayout />
</window>

</canvas>

[antun]

Are you sure that you're using LPS-2.0p? There was a bug like this in 1.0.x, but that was resolved.

The focus model that the new LZ components use is that the first click (on any part of the window) will bring the window to focus), so you lower the risk of accidentally clicking something you didn't mean to.

Did that answer your question?

-Antun

[emaender]

Antun -

I am using version 2.0 beta. We have also recreated the problem on version 2.0p. Anything else I can do to resolve this? Thanks again for your assistance.

[antun]

Hi emaender

I think there's been a little confusion here. The behavior I saw, and the behavior I think you described is the expected behavior for the components.

The windows should give you a visual clue as to which is in focus.

-Antun

[tspratt]

We may have made a strategic error basing our app on windows instead of views.

Do you think it would be reasonable for us to try to change this focus behavior, or would we be better off starting over with views?

Do you have any suggestions on where to look to modify the focus behavior? Is the "first click focuses the window" behavior "intercepting" the click (so maybe easy to change), or is the entire focus behavior built from the ground up?

Any hints or suggestions will be appreciated. The base components are not easy to reverse engineer for us Laszlo beginners.

Thanks!
Tracy

[antun]

Hi Tracy

Before we go any further, I just want to be sure I understand the problem here:

You would like for an unfocused window to focus when you click on (say) a button in that window. However, you would also like for that button to perform its onclick behavior.

-Antun

[metasarah]

Tracy,

Thanks for your feedback on the window focus behavior. A few other folks have requested the same change. Although I designed this behavior initially, upon looking at it again, I realized that if the window is "disabled" when not frontmost it should appear so (Mac OS does this often, but not always) OR clicks should activate the window as well as whatever was clicked on (typical Windows behavior). Most people seemed to expect the latter behavior, so I'm updating the window component to behave as you expected.

In general (and after the final release), if you don't like our choices for components you can modify them to behave or look the way you want. If the behavior change is minor, you can continue use the base class and just create your own class instead of the "lz" class. The easiest way to do this would be make a copy of the lz class and modify it.

For the curious, some implementation details...

For the new window behavior, I removed a view from window and added the new focus behavior to basewindow. If I weren't modifying the product, I would have added the new focus behavior in window in an "onhaswindowfocus" event. To create the focus behavior, the window registers for the onmousedown event from LzGlobalMouse, then brings a window to the front if the mousedown was in a subview of a background window.

If I wanted to create a window with the alternate behavior (background windows have disabled components), I could create a window where the content view was a basecomponent. Then create an "onhaswindowfocus" event and set the content view's enabled property to false when the window loses focus and to true when the window has focus. Since the enabled property cascades, all components in that window would appear disabled when the window was in the background.

Sarah

[tspratt]

I tried to implement the new behavior (where a control in non-active window could take a click withoug first clicking on the window) according to your hints, but got hopelessly lost.

My fantasy would be to have you send me the code...

Tracy

[metasarah]

In the final version of LPS 2.0, this is the behavior. You can try it out here: http://www.laszlosystems.com/lps-2.0/examples/components/window_example.lzx?lzt=html

Notice if you click the checkbox, the window comes to the front and the checkbox receives the click and toggles.

[tspratt]

gimme, gimme, gimme!

[metasarah]

The release can be downloaded here: http://www.laszlosystems.com/developers/download/