The richedit scrollbars

[Duane Clark]

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