[interfacekit] async BView::FrameResized()

Hi folks,

I have noticed a problem with the way we have implemented 
BView::FrameResized(). If you look at BView::_ResizeBy(), you will see the 
view sends itself a BMessage which is supposed to look as if the message 
came from the app_server like it does on R5. This means FrameResized() will 
be call asynchronously.

Suppose you have a BView implementation like BBox, which ignores the 
"width" and "height" arguments passed to the function, and just uses 
Bounds() to get the current width/height. It uses this information to 
invalidate parts of the view. Obviously, if the width/height arguments are 
not equal to the Bounds() width/height, then it will invalidate the wrong 
parts of the view. This is actually what happens, and I think what I 
described is the reason for why it happens on Haiku. I have observed the 
same problem on BeOS R5 though, but I would need to make some tests to see 
if the width/height arguments are sometimes not in sync with Bounds() 
width/height (on R5).

The simple question: Why is FrameResized() not called directly from 
BView::_ResizeBy()? Only to have a valid Window()->CurrentMessage()? Or 
were there other reasons? How could we make sure that using Bounds() in 
FrameResized() would always equal the width/height argument? Or should 
assuming that be considered a bug in the client application (provided the 
same problem exists on R5)?

Thanks for your input!

Best regards,
-Stephan

Other related posts: