Click on Floating Window Fails to Activate it

General
1

Mac Studio Monterey
Xojo v 2022 4.1
My application has a main window. A button on that window has a command to show a second window. That second window is a floating window.

When that second window is “shown” its Activate event fires. One sign that it is activated is that the little Red close dot in the upper left corner is shown in Red.

Now if I click back on the main window, the floating window remains but it moves into a “deactivated” state (Red button becomes gray) and the main window becomes activated and its Red button becomes red.

Now if I click back on the floating window it does NOT becomes activated unless I click on the title bar of the floating window. To me this is a problem and unexpected. The floating window has a DesktopTextField. If I click inside that control, then the window becomes activated. However if I, for example, click on a button in that floating window, the window itself remain in its deactivated state. If I click on some random part of the window away from a control, it does not activate.

My problem at the moment is that the floating window contains a listbox. I can click on it to select rows of the listbox but this action does not activate the window itself. A side effect of this is that the listbox has a “muted” appearance characteristic of a listbox in a non-activated window.

I have two questions:

  1. Is it really the expected behavior of a floating window that clicking on it does not “activate” it. (Activate event does not occur and the appearance does not activate in the sense the Red button remains gray.)
  2. Is there anyway to detect that a floating window that has been “deactivated” is clicked on in locations apart from the title bar?
2

To partially answer my own question, I can deal with my own problem by taking advantage of the MouseEnter event.

If the floating window is deactivated, then this event fires if the cursor reenters the area of the floating window. In the MouseEnter event, I can place a single line of code

Self.Show

That will cause the floating window to “activate”.

To me it seems peculiar that this is necessary. But it seems to solve my particular problem in that the listbox goes back to a non-muted appearance.

Is this the commonly accepted approach to this problem?

3

This is a long-standing issue and might be due to design decisions at the OS level. Unless things have recently changed, you’re going to need some sort of workaround.

Instead of using the MouseEnter event, try this: place a Canvas over the entire window contents. In the Canvas’s MouseDown event, place this code:

Self.Open
Return False

That will catch any clicks on the window and give it a chance to activate itself, while still passing them on to the underlying controls.

4

I appreciate your jumping in and acknowledging that this is an “issue”.

Trying out your suggestion, I could not get

Self.Open
Return False

to be accepted in the MouseDown event of the canvas although

Self.Show
Return False

seems to accomplish what I am after.

I am not clear why using the canvas is any better than using the MouseEnter event of the floating window itself. Is there a potential problem with this latter?

Thanks for your suggestion and any other comments.

5

This is by design, macOS design.

Buttons and other controls should continue to function on the floating window even while it is not the focused window.

1 Like
6

But that also includes not becoming the focus window when it is clicked on?

7

Sorry, typed that when I was on my phone and away from my computer. :slight_smile:

Generally speaking, my philosophy is that moving the mouse randomly around the screen shouldn’t affect the state of the computer, unless that movement is intended by the user to take action. For example, if I’m using your app and I mouse up to the menu bar to accomplish something, the mouse pointer might pass over the floating window. Using the MouseEnter event will cause the window to react to the pointer, which would likely cause visible changes in the window and make the user think that they may have accidentally done something.

This is a gray area. Floating windows are almost always used to support and manipulate data in a document window. The interaction model is quick interaction with the floater and then the user returns their attention (and focus) to the document. Of course this isn’t a hard rule, and perhaps your app design requires a different pattern. But “quick interaction” is the majority usage case.

In re-reading your comments about the listbox looking deactivated and the buttons going gray, that seems to be the Mac OS behavior. I opened Apple’s Pages app and it behaves the same way: the listbox goes “active” when the floating window is clicked on. Once you click back to the document window, the list goes gray.

1 Like
8

In my hands there is one weird difference between the

  1. Window/MouseEnter approach

and the

  1. Overlying Canvas/MouseDown.

With approach (1) immediately upon entering the window the listbox itself shows its non-muted form.

With approach (2) the click (MouseDown) reactivates the window but the listbox itself remains muted until the user clicks on this control.

I would not understand why this would be the case. But you can choose the behavior that you want.

9

That is indeed very interesting. I’m not sure why the code would behave differently, as long as they are both using Self.Show.

11

Apple has many properties for windows. I find it curious a floating window can’t be switched between “quick interaction” and “normal window”, as there are way more rarely-used properties available.

I’d expect this, as a deactivated floating window is as deactivated as another normal window would be. I mean, its controls should reflect they don’t have focus and are on a deactivated window.