[fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
Martin Schreiber
fpmse at bluewin.ch
Wed Jun 9 17:17:36 CEST 2010
On Wednesday 09 June 2010 15:31:27 Graeme Geldenhuys wrote:
> Op 2010-06-09 14:32, Martin Schreiber het geskryf:
> > TRect has been defined in order to communicate
> > rectangles to GDI routines (FillRect(),CreateRectRgnIndirect()...):
>
> And X11 (XLib) was intelligent enough to foresee the ambiguity and use X,
> Y, Width, Height in all drawing API's instead of Top,Left,Right,Bottom. We
> all know Microsoft is just as capable as everybody else to create sh*t
> software or APIs.
>
Agreed. ;-)
> Now I can argue once again that FPC is supposed to be a x-platform product,
> hence it should not JUST follow Microsoft to every single word, but also
> take other platforms (8+ at last count) into consideration. But then
> somebody would throw the "not delphi compatible" card at me. I seem to be
> stuck in a endless loop: I find a issue, report it, get told it's not
> delphi compatible, everybody ignores issue. Repeat.
>
I don't think the current Bounds() behaviour is stupid. Because of the way it
works the definition is the same for integer and float coordinates. Qt uses
your approach in QRect because of historical reasons:
http://doc.qt.nokia.com/4.6/qrect.html#bottom
and it seems they don't think that it is correct:
"
int QRect::bottom () const
Returns the y-coordinate of the rectangle's bottom edge.
Note that for historical reasons this function returns top() + height() - 1;
use y() + height() to retrieve the true y-coordinate.
"
and
"
There is a third constructor that creates a QRect using the top-left and
bottom-right coordinates, but we recommend that you avoid using it. The
rationale is that for historical reasons the values returned by the bottom()
and right() functions deviate from the true bottom-right corner of the
rectangle.
"
>
> I should also point out that you can (and least I know this is true in
> Xlib) adjust the pen cap attributes, which changes the behaviour you
> mentioned. At which point it can include the Right/Bottom pixels in
> rectangle, line drawing etc.
>
This applies for linendings only. XFillRectangle() with width or height = 0
paints nothing AFAIK.
>
> So maybe Marco's idea of a new "NOT delphi compatible" RTL is not so crazy
> after all. At least we will have the freedom of implementing better designs
> and something that works consistently across all FPC supported platforms.
> The red-tape will be so much less, but unfortunately the work involved to
> create a new RTL will be huge.
>
I am not sure if it is possible to design an "ideal" RTL which fulfils all
requirements, they are too different.
Martin
More information about the fpc-devel
mailing list