Alexandre Julliard escribió:
Module: wine Branch: master Commit: f48eb1581dfe176043cbca5c46400c0f86eb5552 URL: http://source.winehq.org/git/wine.git/?a=commit;h=f48eb1581dfe176043cbca5c46...
Author: Alexandre Julliard julliard@winehq.org Date: Mon Aug 20 22:06:50 2007 +0200
winex11: Force a window to managed mode when it is activated.
This patch causes a regression in Visual Basic apps that display a drop-down combo - the drop-down is displayed behind the dialog instead of over it. Details and URL of demostration at http://bugs.winehq.org/show_bug.cgi?id=9443 . Just discovered it minutes ago. Reversing this patch fixes the regression.
This is one of a series of patches on winex11 committed on August 20. Since they did not pass through wine-patches, I don't really know what are they supposed to fix. This is keeping me from simply submitting a reversal of this patch to wine-patches. Could somebody be so kind as to explain?
Alex Villacís Lasso
Alex Villacís Lasso a_villacis@palosanto.com writes:
This is one of a series of patches on winex11 committed on August 20. Since they did not pass through wine-patches, I don't really know what are they supposed to fix. This is keeping me from simply submitting a reversal of this patch to wine-patches. Could somebody be so kind as to explain?
They are supposed to fix the gazillion problems we have with various windows not being managed, thus not getting focus, always staying on top, etc. It does this by making any window that receives focus switch to managed mode at that point. It should give better results than the simple static heuristic based on the window style, but there are certainly some cases where it will do the wrong thing.
What you should do is either figure out if there's a way to make that window behave properly while still keeping it managed, or if not, whether there's a way to identify that kind of windows to prevent them from getting managed at all.
Alexandre Julliard julliard@winehq.org writes:
What you should do is either figure out if there's a way to make that window behave properly while still keeping it managed, or if not, whether there's a way to identify that kind of windows to prevent them from getting managed at all.
In this case it turned out to be easy, the window is WS_CHILD and so is not supposed to be activated, all we have to do is skip the activation check in that case. I'll put in a fix.