[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] wind_get( WF_WORKXYWH) buggy? (was: Re: usage of wind_calc())



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