PR# 11596 Calling {EV_DRAWING_AREA}.set_focus from window pointer_enter_actions generates expose
Problem Report Summary
Submitter: prestoat2000
Category: EiffelVision
Priority: Medium
Date: 2006/10/27
Class: Bug
Severity: Serious
Number: 11596
Release: 5.7.64493
Confidential: No
Status: Analyzed
Responsible:
Environment: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.8.0.7) Gecko/20060915 Firefox/1.5.0.7
Solaris 9 on SPARC
Synopsis: Calling {EV_DRAWING_AREA}.set_focus from window pointer_enter_actions generates expose
Description
I implemented the strategy described in a previous report to determne whether a user-initiated resize of a window moves the upper left corner and it more or less works. However, the drawing area is first displayed in the new position where it would be but then "jumps" back to the correct location. I think this might be related to the following unexpected behavior. I have an EV_TITLED_WINDOW which contains an EV_DRAWING_AREA. In the window's pointer_enter_actions, I added a call to {EV_DRAWING_AREA}.set_focus since I want the focus to always be in the drawing area (key press and release events cause changes to the contents of the drawing area). But the `set_focus' call causes an expose event for the entire drawing area whenever the pointer enters or leaves the window that contains it. This seems like a bug to me and seems to be preventing me from keeping the drawing from temporarily moving on the screen when a user-initiated resize moves the upper left window corner, due to an extra unexpected expose event. To reproduce: Run attached test program. Move pointer in and out of window. Each time pointer enters or leaves window, expose_actions are called for the drawing area (the whole area). Please fix if this is a bug or explain to me how I can get the effect I want (user-initiated resize does not move drawing on screen) while still setting focus to the drawing area when pointer enters containing window.
To Reproduce
Problem Report Interactions
This solution sounds like it will work for me. I'm working on something else right now, but I will try this solution as soon as time permits. Let's leave this open for now and I will update it when I have tried your solution. Thanks for the clear explanation.
Hi David, I'm guessing that either X or gdk is generating a full expose when the focus changes to the viewable focus state to update. There doesn't seem to be a way to turn off this behavior. To alleviate the issue, can you connect your key actions to the top level window instead, as these will always be fired if it has the window manager focus, you can then propagate the calls to the drawing area. This is how we are dealing internally with the key events anyway as the window manager only generates the event for the window with the highlighted focus and not the child windows. This can be performed by keeping a flag to say whether or not the drawing area is focused, when you want to focus it you set the flag. There is focus_in_actions and focus_out_actions in EV_APPLICATION to keep track of the flag, if any other widget gains the focus then the flag is unset, if a click is performed on the drawing area you set the flag. Then in the top level window key events you can check whether the flag is set and .... Output truncated, Click download to get the full message