PR# 13108 Key focus is apparently working, but actually lost.

Problem Report Summary
Submitter: ted_eiffel
Category: EiffelVision
Priority: Medium
Date: 2007/06/11
Class: Bug
Severity: Serious
Number: 13108
Release: 6.0.6.8937
Confidential: No
Status: Closed
Responsible:
Environment: Solaris x86
Synopsis: Key focus is apparently working, but actually lost.

Description
This was found when investigating bug#12510 that Control+Tab inactivated for awhile after Control+Tab with scroll.

Lost key focus resulted Ctrl + Tab did not trigger the main window accelerators any more. But normally switching between windows and doing some focus switching among widgets could make everything back to normal.
 
I attached a small project to reproduce this. In the end, you will find the focused main window does not receive any key inputs.
To Reproduce
Run attached project.
Ctrl + Tab to display the About dialog.
Holding Ctrl, drag the scroll bar on About dialog.
Holding the dragging left pointer button, release Ctrl.
Release left pointer button.
Try typing something. The text field with cursor blinking doesn't receive anything at all.
Problem Report Interactions
From:larryl    Date:2009/04/16    Download   
Unfortunately.. the hack only work for this bug but not bug#12510. Here is the new fix: calling {EV_GTK_EXTERNALS}.gtk_widget_destroy (l_c_object) when a {EV_SCROLLABLE_AREA} is destroyed.

See bug#12510 for more details.

From:larryl    Date:2009/04/15    Status: Closed    Download   
The key of this bug is:

Just after hide/destroy a window where pointer pressed (but not released), when pointer button release, the pointer position within/outside current process window area.

If pointer position within current process window area, then everything works fine.

If pointer position outside current process window area, then bug appears.

I think maybe this is a GTK bug, or Vision2 bug (have to call something to release pointer capture before hide/destroy window?).

After hide/destroy a window, if first call {EV_WIDGET}.enable_capture on next focused window (MAIN_WINDOW in the demo project), then {EV_WIDGET}.disable_capture on the window immediately. The bug disappears. So the hack of this bug is call following feature just after dialog hidden/destroyed.

enable_disable_capture_for_next_focused_widget
        -- Hack for bug#13108
    local
        l_env: EV_ENVIRONMENT
    do
        create l_env
        l_env.application.focus_in_actions.extend_kamikaze (agent (a_widget: EV_
....
Output truncated, Click download to get the full message

From:ted_eiffel    Date:2007/06/11    Download   
Attachments for problem report #13108

Attachment: problem_of_scrollbar.tar.gz     Size:3500