Re: [lazarus] Found serious bug in win32 interface

2008-01-30 Thread Andrey Gusev 

* Paul Ishenin [EMAIL PROTECTED] [Wed, 30 Jan 2008 11:27:16 +0700]:

Andrey Gusev wrote:
 That:
 --- interfaces/win32/win32callback.inc(revision 13905)
 +++ interfaces/win32/win32callback.inc(working copy)
 @@ -504,7 +504,7 @@
   if (ControlDC = 0) or not needParentPaint then
   begin
 DCIndex := Windows.SaveDC(PaintMsg.DC);
 -MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
 +MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
 {$ifdef DEBUG_DOUBLEBUFFER}
 Windows.GetClipBox(PaintMsg.DC, ClipBox);
 DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), ' 

with

 clipping rect (',








I saw it all yesterday.
That's question:
How it contrived by develoers team: to build correctly worked 
tabular-components on top of so fundamental bug ???


_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

[lazarus] Found serious bug in win32 interface #2

2008-01-30 Thread Andrey Gusev 

--- interfaces/win32/win32callback.inc (revision 13905)
+++ interfaces/win32/win32callback.inc (working copy)
@@ -504,7 +504,7 @@
if (ControlDC = 0) or not needParentPaint then
begin
DCIndex := Windows.SaveDC(PaintMsg.DC);
- MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
+ MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
{$ifdef DEBUG_DOUBLEBUFFER}
Windows.GetClipBox(PaintMsg.DC, ClipBox);
DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
with
clipping rect (',

I can provide application that's confirm my rightfulness.
But i don't wish to do it, until all child-control negative effects will
debugged (by me), it need to LazReport designer functionality.
If wished, try to place oversized TPaintBox on TScrollBox and try it to
scroll (with above patch applied).

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface

2008-01-30 Thread Andrey Gusev 

* Paul Ishenin [EMAIL PROTECTED] [Wed, 30 Jan 2008 11:27:16 +0700]:

Andrey Gusev wrote:
 That:
 --- interfaces/win32/win32callback.inc(revision 13905)
 +++ interfaces/win32/win32callback.inc(working copy)
 @@ -504,7 +504,7 @@
   if (ControlDC = 0) or not needParentPaint then
   begin
 DCIndex := Windows.SaveDC(PaintMsg.DC);
 -MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
 +MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
 {$ifdef DEBUG_DOUBLEBUFFER}
 Windows.GetClipBox(PaintMsg.DC, ClipBox);
 DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), ' 

with

 clipping rect (',






Please try to build ide with your changes and you'll see nice effects 

:)




I saw it all yesterday.
That's question:
How it contrived by develoers team: to build correctly worked
tabular-components on top of so fundamental bug ???

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface #2

2008-01-30 Thread Mattias Gärtner 
Zitat von Andrey Gusev [EMAIL PROTECTED]:

 --- interfaces/win32/win32callback.inc (revision 13905)
 +++ interfaces/win32/win32callback.inc (working copy)
  @@ -504,7 +504,7 @@
 if (ControlDC = 0) or not needParentPaint then
  begin
  DCIndex := Windows.SaveDC(PaintMsg.DC);
  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
 + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
  {$ifdef DEBUG_DOUBLEBUFFER}
  Windows.GetClipBox(PaintMsg.DC, ClipBox);
 DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
 with
 clipping rect (',

 I can provide application that's confirm my rightfulness.
 But i don't wish to do it, until all child-control negative effects will
 debugged (by me), it need to LazReport designer functionality.
 If wished, try to place oversized TPaintBox on TScrollBox and try it to
 scroll (with above patch applied).

It might improve the situation, but I guess it will not fix the whole problem.
See here:
http://wiki.lazarus.freepascal.org/Win32/64_Interface


Mattias

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface #2

2008-01-30 Thread Andrey Gusev 
* Mattias G#228;rtner [EMAIL PROTECTED] [Wed, 30 Jan 2008 
18:45:57 +0100]:

Zitat von Andrey Gusev [EMAIL PROTECTED]:

 --- interfaces/win32/win32callback.inc (revision 13905)
 +++ interfaces/win32/win32callback.inc (working copy)
  @@ -504,7 +504,7 @@
 if (ControlDC = 0) or not needParentPaint then
  begin
  DCIndex := Windows.SaveDC(PaintMsg.DC);
  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
 + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
  {$ifdef DEBUG_DOUBLEBUFFER}
  Windows.GetClipBox(PaintMsg.DC, ClipBox);
 DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
 with
 clipping rect (',

 I can provide application that's confirm my rightfulness.
 But i don't wish to do it, until all child-control negative effects
will
 debugged (by me), it need to LazReport designer functionality.
 If wished, try to place oversized TPaintBox on TScrollBox and try it
to
 scroll (with above patch applied).

It might improve the situation, but I guess it will not fix the whole
problem.
See here:
http://wiki.lazarus.freepascal.org/Win32/64_Interface


It was said, about intermeditate layer, earlier (by You).
Also, it implementation started in win32wsfrorms, rudimentary state.
But observed, with above correction, child controls scrolls correctly, 
except
page and line messages processing, which brings some negative shift, for 
childs.
Undoubtedly, we can force to work existing variant, a few various 
methods can be invented

(twice MoveWindowOrg for example).
But pointed bug is nice explaination (and chance to eliminate) the 
strange opposite scrolling behaviour.

see http://bugs.freepascal.org/view.php?id=10400,
also observation, described in my #16900 reply, 
http://bugs.freepascal.org/view.php?id=10471,

correspond to pointed bug presence.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

RE: [lazarus] Found serious bug in win32 interface #2

2008-01-30 Thread Andrew Brunner 
What I don't understand is why would you need to implement a localized
ScrollWindow(..) to provide the effect of Scrolling a window.

For the sake simplicity Windows scrolls a window and takes care of all
children in that window.  

These aren't questions that need answers.  I'm just pointing out that MS
Windows sufficiently offers API to scroll a window with children.  I just
wanted to point that out.

Thanks.



-Original Message-
From: Andrey Gusev [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, January 30, 2008 3:48 PM
To: lazarus@miraclec.com
Subject: Re: [lazarus] Found serious bug in win32 interface #2

* Mattias G#228;rtner [EMAIL PROTECTED] [Wed, 30 Jan 2008 
18:45:57 +0100]:
 Zitat von Andrey Gusev [EMAIL PROTECTED]:

  --- interfaces/win32/win32callback.inc (revision 13905)
  +++ interfaces/win32/win32callback.inc (working copy)
   @@ -504,7 +504,7 @@
  if (ControlDC = 0) or not needParentPaint then
   begin
   DCIndex := Windows.SaveDC(PaintMsg.DC);
   - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
  + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
   {$ifdef DEBUG_DOUBLEBUFFER}
   Windows.GetClipBox(PaintMsg.DC, ClipBox);
  DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
  with
  clipping rect (',
 
  I can provide application that's confirm my rightfulness.
  But i don't wish to do it, until all child-control negative effects
 will
  debugged (by me), it need to LazReport designer functionality.
  If wished, try to place oversized TPaintBox on TScrollBox and try it
 to
  scroll (with above patch applied).

 It might improve the situation, but I guess it will not fix the whole
 problem.
 See here:
 http://wiki.lazarus.freepascal.org/Win32/64_Interface

It was said, about intermeditate layer, earlier (by You).
Also, it implementation started in win32wsfrorms, rudimentary state.
But observed, with above correction, child controls scrolls correctly, 
except
page and line messages processing, which brings some negative shift, for 
childs.
Undoubtedly, we can force to work existing variant, a few various 
methods can be invented
(twice MoveWindowOrg for example).
But pointed bug is nice explaination (and chance to eliminate) the 
strange opposite scrolling behaviour.
see http://bugs.freepascal.org/view.php?id=10400,
also observation, described in my #16900 reply, 
http://bugs.freepascal.org/view.php?id=10471,
correspond to pointed bug presence.

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface

2008-01-30 Thread Micha Nelissen 
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.

 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).

I am not sure what bug you want to fix?

Micha

_
 To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface

2008-01-30 Thread Marc Weustink 

Andrey Gusev wrote:

* Paul Ishenin [EMAIL PROTECTED] [Wed, 30 Jan 2008 11:27:16 +0700]:

Andrey Gusev wrote:
 That:
 --- interfaces/win32/win32callback.inc(revision 13905)
 +++ interfaces/win32/win32callback.inc(working copy)
 @@ -504,7 +504,7 @@
   if (ControlDC = 0) or not needParentPaint then
   begin
 DCIndex := Windows.SaveDC(PaintMsg.DC);
 -MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
 +MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
 {$ifdef DEBUG_DOUBLEBUFFER}
 Windows.GetClipBox(PaintMsg.DC, ClipBox);
 DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), ' 

with

 clipping rect (',


 



Please try to build ide with your changes and you'll see nice effects 

:)




I saw it all yesterday.
That's question:
How it contrived by develoers team: to build correctly worked
tabular-components on top of so fundamental bug ???


This is recently changed. Initially the code had a similar behaviour as 
delphi. It became clear that only scrolling in win32 would work like the 
old way and that all other widgetsets had to add heaps of code.
So scrolling changed, however all widgetsets need to get adapted to the 
new situation.


Marc

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface #2

2008-01-30 Thread Luiz Americo Pereira Camara 

Andrey Gusev wrote:
* Mattias G#228;rtner [EMAIL PROTECTED] [Wed, 30 Jan 2008 
18:45:57 +0100]:

Zitat von Andrey Gusev [EMAIL PROTECTED]:

 --- interfaces/win32/win32callback.inc (revision 13905)
 +++ interfaces/win32/win32callback.inc (working copy)
  @@ -504,7 +504,7 @@
 if (ControlDC = 0) or not needParentPaint then
  begin
  DCIndex := Windows.SaveDC(PaintMsg.DC);
  - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
 + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
  {$ifdef DEBUG_DOUBLEBUFFER}
  Windows.GetClipBox(PaintMsg.DC, ClipBox);
 DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
 with
 clipping rect (',

 I can provide application that's confirm my rightfulness.
 But i don't wish to do it, until all child-control negative effects
will
 debugged (by me), it need to LazReport designer functionality.
 If wished, try to place oversized TPaintBox on TScrollBox and try it
to
 scroll (with above patch applied).

It might improve the situation, but I guess it will not fix the whole
problem.
See here:
http://wiki.lazarus.freepascal.org/Win32/64_Interface


It was said, about intermeditate layer, earlier (by You).
Also, it implementation started in win32wsfrorms, rudimentary state.
But observed, with above correction, child controls scrolls correctly, 
except
page and line messages processing, which brings some negative shift, 
for childs.
Undoubtedly, we can force to work existing variant, a few various 
methods can be invented

(twice MoveWindowOrg for example).
But pointed bug is nice explaination (and chance to eliminate) the 
strange opposite scrolling behaviour.

see http://bugs.freepascal.org/view.php?id=10400,
also observation, described in my #16900 reply, 
http://bugs.freepascal.org/view.php?id=10471,

correspond to pointed bug presence.


Hi, do you have one or two small proof of concept LCL application that 
shows the problem? (works in gtk fails in win32).

If you have please send me or post in the bugtracker/here.
I will take a look.

Luiz

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface #2

2008-01-30 Thread Andrey Gusev 
* Luiz Americo Pereira Camara [EMAIL PROTECTED] [Thu, 31 Jan 2008 
01:16:58 -0300]:

Andrey Gusev wrote:
 * Mattias G#228;rtner [EMAIL PROTECTED] [Wed, 30 Jan 2008
 18:45:57 +0100]:
 Zitat von Andrey Gusev [EMAIL PROTECTED]:

  --- interfaces/win32/win32callback.inc (revision 13905)
  +++ interfaces/win32/win32callback.inc (working copy)
   @@ -504,7 +504,7 @@
  if (ControlDC = 0) or not needParentPaint then
   begin
   DCIndex := Windows.SaveDC(PaintMsg.DC);
   - MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
  + MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
   {$ifdef DEBUG_DOUBLEBUFFER}
   Windows.GetClipBox(PaintMsg.DC, ClipBox);
  DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), '
  with
  clipping rect (',
 
  I can provide application that's confirm my rightfulness.
  But i don't wish to do it, until all child-control negative 

effects

 will
  debugged (by me), it need to LazReport designer functionality.
  If wished, try to place oversized TPaintBox on TScrollBox and try
it
 to
  scroll (with above patch applied).

 It might improve the situation, but I guess it will not fix the 

whole

 problem.
 See here:
 http://wiki.lazarus.freepascal.org/Win32/64_Interface

 It was said, about intermeditate layer, earlier (by You).
 Also, it implementation started in win32wsfrorms, rudimentary state.
 But observed, with above correction, child controls scrolls 

correctly,

 except
 page and line messages processing, which brings some negative shift,
 for childs.
 Undoubtedly, we can force to work existing variant, a few various
 methods can be invented
 (twice MoveWindowOrg for example).
 But pointed bug is nice explaination (and chance to eliminate) the
 strange opposite scrolling behaviour.
 see http://bugs.freepascal.org/view.php?id=10400,
 also observation, described in my #16900 reply,
 http://bugs.freepascal.org/view.php?id=10471,
 correspond to pointed bug presence.

Hi, do you have one or two small proof of concept LCL application that
shows the problem? (works in gtk fails in win32).
If you have please send me or post in the bugtracker/here.
I will take a look.


See attachement.
Form2  Form3 demonstrates problems with tabbed controls, that brings by 
above patch,

it implementations must be corrected, as i mean.



ttt.TGZ
Description: GNU Unix tar archive

Re: [lazarus] Found serious bug in win32 interface

2008-01-30 Thread Andrey Gusev 
* 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 
http://mail.rambler.ru/mail/mail.cgi?mode=obj;mbox=INBOX%26r%3D5f6a;what=6827, 
my post



 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, 
http://mail.rambler.ru/mail/mail.cgi?mode=obj;mbox=INBOX%26r%3D5f6a;what=4702

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] Found serious bug in win32 interface

2008-01-29 Thread Andrey Gusev 

That:
--- interfaces/win32/win32callback.inc  (revision 13905)
+++ interfaces/win32/win32callback.inc  (working copy)
@@ -504,7 +504,7 @@
  if (ControlDC = 0) or not needParentPaint then
  begin
DCIndex := Windows.SaveDC(PaintMsg.DC);
-MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
+MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
{$ifdef DEBUG_DOUBLEBUFFER}
Windows.GetClipBox(PaintMsg.DC, ClipBox);
DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), ' with 
clipping rect (',


With these changes TScroolBox behaviour is almost adequate.
Some problems with child controls positioning when scroll still exists.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Re: [lazarus] Found serious bug in win32 interface

2008-01-29 Thread Paul Ishenin 

Andrey Gusev wrote:

That:
--- interfaces/win32/win32callback.inc(revision 13905)
+++ interfaces/win32/win32callback.inc(working copy)
@@ -504,7 +504,7 @@
  if (ControlDC = 0) or not needParentPaint then
  begin
DCIndex := Windows.SaveDC(PaintMsg.DC);
-MoveWindowOrgEx(PaintMsg.DC, ORect.Left, ORect.Top);
+MoveWindowOrgEx(PaintMsg.DC, -ORect.Left, -ORect.Top);
{$ifdef DEBUG_DOUBLEBUFFER}
Windows.GetClipBox(PaintMsg.DC, ClipBox);
DebugLn('LCL Drawing in DC ', IntToHex(PaintMsg.DC, 8), ' with 
clipping rect (',
 


Please try to build ide with your changes and you'll see nice effects :)

Best regards,
Paul Ishenin.

_
To unsubscribe: mail [EMAIL PROTECTED] with
   unsubscribe as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives