Thomas Faber thfabba@gmx.de writes:
Windows's version of GetTextExtentExPointW, which is called in that function, returns a value of 1 in this case (Wine's does not, which would appear to be a bug), leading to the "i<len" assertion failure if there is no text in the control. The patch fixes riched20 to correctly handle either behavior by adding a fast path for cx <= 0 (the function obviously needs to return 0 in the cx == 0 case too, so it can skip the calculation).
You should not be adding workarounds for Wine bugs, the bugs need to be fixed instead.
Hey,
On 2011-10-24 20:03, Alexandre Julliard wrote:
Thomas Faber thfabba@gmx.de writes:
Windows's version of GetTextExtentExPointW, which is called in that function, returns a value of 1 in this case (Wine's does not, which would appear to be a bug), leading to the "i<len" assertion failure if there is no text in the control. The patch fixes riched20 to correctly handle either behavior by adding a fast path for cx <= 0 (the function obviously needs to return 0 in the cx == 0 case too, so it can skip the calculation).
You should not be adding workarounds for Wine bugs, the bugs need to be fixed instead.
it is not a workaround. It is the current riched20 code that relies on the bug being present (hence why it asserts on Windows). The patch makes it work with a _correctly working_ version of GetTextExtentExPointW (and also with the current one). You could see it as a prerequisite to fixing that bug (that is, to fixing it without breaking richedit controls).
Regards, Tom
Thomas Faber thfabba@gmx.de writes:
it is not a workaround. It is the current riched20 code that relies on the bug being present (hence why it asserts on Windows). The patch makes it work with a _correctly working_ version of GetTextExtentExPointW (and also with the current one). You could see it as a prerequisite to fixing that bug (that is, to fixing it without breaking richedit controls).
Ah OK, it's fine then. Thanks.
-
Alexandre Julliard -
Thomas Faber