ReRe: [lazarus] ScrollBox scrolling problem situation
Damn, wedged on Ctrl+V. == * Micha Nelissen [EMAIL PROTECTED] [Wed, 30 Jan 2008 22:27:36 +0100]: Andrey Gusev wrote: - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top); + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top); No. ORect.Left is offset from Win32 - LCL. So if LCL draws at (0,0) it should actually be at (ORect.Left, ORect.Top), so the code is correct. Opposite scrolling of TPaintBox mist be explanable, anyway. Ether by message proccessing bug, or TPaintBox implementation. That's unintelligible (now) to me, why Panel being placed together with TPaintBox react to scroll otherwise then without him ? Get project from last my post in [lazarus] Found serious bug in win32 interface #2 thread. With these changes TScroolBox behaviour is almost adequate. Some problems with child controls positioning when scroll still exists. Hint: try looking at GetLCLClientBoundsOffset (if you didn't already). Thanks fo hint, tha't is was missing part, to my investigations. I am not sure what bug you want to fix? My principal trouble is http://bugs.freepascal.org/view.php?id=10471 Mattias Gaertner have told way: The problem is, that at the moment the win32 interface moves the childs instead of moving the client area. This operation is not atomic, that means, each child move creates messages. It is nearly impossible to make this operation atomic platform independently. That's why instead all widgetsets should instead move the 'client area'. This means the childs should be put on an internal widget - the 'client area widget'. Scrolling means then to simply move the client area widget. So, it is needed that TWin32WSScrollingWinControl creates an internal widget and put its childs on this widget. That's all. The winapi part is not hard. The hardest part is to understand the win32 interface and fix all places, where this might be relevant. I simply fairly try to understand all up to the end. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] ScrollBox scrolling problem situation
Can somebody comments situation with ScrollBox scrolling Win32 wrong implementation ? I have in view of http://bugs.freepascal.org/view.php?id=10471, http://bugs.freepascal.org/view.php?id=10400 issues, that still actual on svn 13339. More concrete: where and how much deeply to dig, to fix that problem ? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] ScrollBox scrolling problem situation
* Andrey Gusev [EMAIL PROTECTED] [Tue, 08 Jan 2008 20:53:48 +0300]: Can somebody comments situation with ScrollBox scrolling Win32 wrong implementation ? I have in view of http://bugs.freepascal.org/view.php?id=10471, http://bugs.freepascal.org/view.php?id=10400 issues, that still actual on svn 13339. 13669, mistyped More concrete: where and how much deeply to dig, to fix that problem ? _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] ScrollBox scrolling problem situation
On Tue, 08 Jan 2008 20:55:59 +0300 Andrey Gusev [EMAIL PROTECTED] wrote: * Andrey Gusev [EMAIL PROTECTED] [Tue, 08 Jan 2008 20:53:48 +0300]: Can somebody comments situation with ScrollBox scrolling Win32 wrong implementation ? I have in view of http://bugs.freepascal.org/view.php?id=10471, http://bugs.freepascal.org/view.php?id=10400 issues, that still actual on svn 13339. 13669, mistyped More concrete: where and how much deeply to dig, to fix that problem ? The problem is, that at the moment the win32 interface moves the childs instead of moving the client area. This operation is not atomic, that means, each child move creates messages. It is nearly impossible to make this operation atomic platform independently. That's why instead all widgetsets should instead move the 'client area'. This means the childs should be put on an internal widget - the 'client area widget'. Scrolling means then to simply move the client area widget. So, it is needed that TWin32WSScrollingWinControl creates an internal widget and put its childs on this widget. That's all. The winapi part is not hard. The hardest part is to understand the win32 interface and fix all places, where this might be relevant. AFAIK the other widgetsets already use an internal client area widget. Mattias _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
