FWD » Core Development » User Interface

Hynek, Constantine, can you comment this, please?

Vladimir Tsichevski wrote:

The issue: in OE this will happen on mouse down, while in FWD this will happen on mouse up.

Do both the focus change and the trigger happen on mouse up? What mouse down handler reports for FOCUS? Also what happens when you mouse down in the frame, move the mouse outside the window and mouse up?

What happens if you mouse down and then press the ESC key?

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

The issue: in OE this will happen on mouse down, while in FWD this will happen on mouse up.

Do both the focus change and the trigger happen on mouse up?

All triggers are fired on mouse up in FWD. The final focus change must be done or must not be done depending on the results of ENTRY triggers.

What mouse down handler reports for FOCUS?

In the example, ENTRY and LEAVE triggers are attached to all widgets. No mouse down trigger is defined in this example.
The focus reported is the system FOCUS handle value.>

Also what happens when you mouse down in the frame, move the mouse outside the window and mouse up?

In FWD: same focus things as if you mouse up in the same frame.
In OE: nothing (same as if you mouse up in the same frame).

Also the event sequence and the resulting focus differ in FWD and OE, but all this is not related to this issue.

The question is why all the activity, whatever it is, happens on different mouse events?

This is managed by some complicated code in TC.processProgressEvent, wrote by you and Constantin. So I wonder why is this? May be, the thing can be configured in OE, and my configuration differs from the one you used when you wrote the code? Or, may be the behavior was changed in some OE versions? I tested this with OE 11.6.

Greg Shah wrote:

What happens if you mouse down and then press the ESC key?

Procedure complete. Press space bar to continue. Both FWD an OE behave the same.

Vladimir Tsichevski wrote:

The question is why all the activity, whatever it is, happens on different mouse events?

IMHO this was just implemented with an assumption that the focus should change on mouse down. I don't think this can be configured in OE. Even different versions of OE with different behavior sounds unlikely.

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

The question is why all the activity, whatever it is, happens on different mouse events?

IMHO this was just implemented with an assumption that the focus should change on mouse down. I don't think this can be configured in OE. Even different versions of OE with different behavior sounds unlikely.

Does this mean this is just an error and must be fixed?

Vladimir Tsichevski wrote:

Hynek Cihlar wrote:

Vladimir Tsichevski wrote:

The question is why all the activity, whatever it is, happens on different mouse events?

IMHO this was just implemented with an assumption that the focus should change on mouse down. I don't think this can be configured in OE. Even different versions of OE with different behavior sounds unlikely.

Does this mean this is just an error and must be fixed?

Yes.

Vladimir, the problem I think originates from cases where the mouse is used inside a widget, and not a frame. See this revised test (uses FILL-IN to better see the focus switch): code...code...

// Demonstrates the FWD bug: focus change happens ON mouse UP instead OF mouse DOWN

// Defines 2 frames with buttons:
// 1. 'outerFrame'
// 2. 'innerFrame' inside the 'outerFrame'

DEFAULT-WINDOW:TITLE = '8376'.
def var focusable1 as char.
def var focusable2 as char.

// DEFINE BUTTON focusable1.
DEFINE FRAME outerFrame focusable1 WITH SIZE 80 BY 10 no-labels.

// DEFINE BUTTON focusable2.
DEFINE FRAME innerFrame focusable2 WITH SIZE 20 BY 4 AT ROW 3 COL 1 no-labels.
FRAME innerFrame:FRAME = FRAME outerFrame:HANDLE.

{functions.i}

{printEntryLeave.i &widget="FRAME outerFrame"}
{printEntryLeave.i &widget="FRAME innerFrame"}
{printEntryLeave.i &widget="focusable1"}
{printEntryLeave.i &widget="focusable2"}

on mouse-select-down of frame innerframe do:
   message "mouse-down innerframe".
  RUN PrintEntry(frame innerframe:HANDLE).
end.

on mouse-select-down of frame outerFrame do:
   message "mouse-down outerframe".
  RUN PrintEntry(frame outerFrame :HANDLE).
end.

on mouse-select-up of frame innerframe do:
   message "mouse-up innerframe".
  RUN PrintEntry(frame innerframe:HANDLE).
end.

on mouse-select-up of frame outerFrame do:
   message "mouse-up outerframe".
  RUN PrintEntry(frame outerFrame :HANDLE).
end.

on mouse-select-down of focusable1 do:
   message "mouse-down focusable1".
  RUN PrintEntry(focusable1:HANDLE).
end.

on mouse-select-down of focusable2 do:
   message "mouse-down focusable2".
  RUN PrintEntry(focusable2:HANDLE).
end.

on mouse-select-up of focusable1 do:
   message "mouse-up focusable1".
  RUN PrintEntry(focusable1:HANDLE).
end.

on mouse-select-up of focusable2 do:
   message "mouse-up focusable2".
  RUN PrintEntry(focusable2:HANDLE).
end.

ENABLE ALL WITH FRAME outerFrame.
ENABLE ALL WITH FRAME innerFrame.
WAIT-FOR GO OF FRAME outerFrame.

If you click into the FILL-IN, it will not switch the system focus immediately if there is a mouse-down trigger - this will be done on mouse-up. Also, if there is no mouse-down trigger, then the system focus will be switched immediately, but the events again will be done on mouse-up.

I think what you found is a case specific to frames - in these cases, because (I think) there is no system focus on it, everything happens on mouse-down, not mouse-up.

Constantin Asofiei wrote:

Vladimir, the problem I think originates from cases where the mouse is used inside a widget, and not a frame. See this revised test...

There is no need to create new tests and add triggers for mouse events, which makes things more complicated.

Even in the original example, if you press the mouse button on a button, the focus processing is deferred until mouse up.

So, the answer is probably: for some mouse targets focus should be updated on mouse down, for other targets - on mouse up.