Hi! As I am back from my holidays let me jump into the discussion too. :) Arnaud BERCEGEAY wrote:
because wind_get(WF_WORKXYWH) is buggy in some AESes : with buggy AES, wind_get(WF_WORKXYWH) forget to take into account the height of the toolbar. The method in windom works for all AESes. The "clean" method (use wind_get(WF_WORKXYWH)) fails with some AESes. Now, if the AES is able to tell the application that wind_get(WF_WORKXYWH) is bug free -- and we can use the new bit for wind_set(WF_WORKXYWH) for this purpose -- then windom will use wind_get(WF_WORKXYWH) instead of wind_calc() even if it's not trivial in windom.
This provokes me to give you similar solution as in the XaAES vs Hades Nova problem:
* Which precise AES is buggy? * How many users use this AES nowadays? * Is it worth it to workaround it? * Do either of those:* Fix the AES (TSR?) - works for all applications (I have seen only WinDom not using WF_WORKXYWH so far.... - never heard about the problem before).
* Perhaps fix the problem in gemlib?Regarding the wind_calc() usage. There will be very little applications that would survive on-fly theme change (cause they _use_ and will use wind_calc() on and on) so this 'change theme only for new windows feature' will IMHO stay experimental forever.
Best regards STanda