Duane Clark wrote:
The easy fix is to have WM_NCCALCSIZE return the true size of the enclosing window, which is what we have done here. The more difficult fix is to create a custom Richedit MoveWindow procedure for use in the WM_SIZE message above. Since it is very unlikely that an app would call and use the WM_NCCALCSIZE message, we stick with the easy fix for now.
Sorry for being a pest about this, and it's not like the Richedit is in my focus at the moment, but what does Windows do under the same circumstances?
Changelog: A fix to get edit control scrolls bars to draw in the correct position.
Shachar Shemesh wrote:
Duane Clark wrote:
The easy fix is to have WM_NCCALCSIZE return the true size of the enclosing window, which is what we have done here. The more difficult fix is to create a custom Richedit MoveWindow procedure for use in the WM_SIZE message above. Since it is very unlikely that an app would call and use the WM_NCCALCSIZE message, we stick with the easy fix for now.
Sorry for being a pest about this, and it's not like the Richedit is in my focus at the moment, but what does Windows do under the same circumstances?
Well, Windows does not embed an edit control within another Window to come up with the richedit control. So in that case "the true size of the enclosing window" (and I probably should have said "the true size of the client area of the enclosing window") matches the client area of the richedit control. So there is no issue there. This is purely an artifact of the way richedit has been implemented in Wine. This also is why the problem disappears in Wine's notepad when an edit control is used directly (as by your patch of a few weeks ago).
Basically the problem comes about because Wine determines what size to set the edit control to with the results of a WM_NCCALCSIZE sent message to the enclosing window, which in our case is the richedit window. If we do not return "the true size of the client area of the enclosing window", then the edit control is drawn incorrectly.
And I really do think that the likelihood of an app using WM_NCCALCSIZE on a richedit control to be rather remote, and the likelihood that the value returned affecting the results even more remote. So I personally consider the effort to write a custom WM_SIZE routine to be largely