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
From:prestoat2000    Date:2006/11/09    Download   
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.

From:misterieking    Date:2006/11/08    Status: Analyzed    Download   
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

From:prestoat2000    Date:2006/10/27    Download   
Attachments for problem report #11596

Attachment: test.e     Size:2211
Attachment: test.ecf     Size:1498