22:28
Aan: lazarus@miraclec.com
Onderwerp: Re: [lazarus] Trying to make TScrollingWinControl more
useful...
Mattias Gaertner schreef:
On Tue, 12 Dec 2006 19:12:41 +0100
Pieter Valentijn [EMAIL PROTECTED] wrote:
I ment for that panel to be inside the scroll box.
That way theres only one
Onderwerp: Re: [lazarus] Trying to make TScrollingWinControl more
useful...
Pieter Valentijn wrote:
Why not place all controls on a panel and adjust that ?
I'm not maintaining that code anymore. My point was, that others may
have done the same as me, so there might be more people depending
Mattias Gaertner schreef:
On Tue, 12 Dec 2006 19:12:41 +0100
Pieter Valentijn [EMAIL PROTECTED] wrote:
I ment for that panel to be inside the scroll box.
That way theres only one control to think about.
If your code does the job then theres no need to maintain it :-)
The panel idea will
Mattias Gaertner wrote:
Which Delphi apps/components depend on this?
I guess not many, because
Hmm. From what I remember when I made a TScrollBox with dynamically
created controls in it, I needed to adjust for the
Horz/VertScrollBar.Position a lot. Therefore, I'm almost certain that
code would
Onderwerp: Re: [lazarus] Trying to make TScrollingWinControl more
useful...
Mattias Gaertner wrote:
Which Delphi apps/components depend on this?
I guess not many, because
Hmm. From what I remember when I made a TScrollBox with dynamically
created controls in it, I needed to adjust for the
Horz
Pieter Valentijn wrote:
Why not place all controls on a panel and adjust that ?
I'm not maintaining that code anymore. My point was, that others may
have done the same as me, so there might be more people depending on it
than Mattias suggests. But I have no concrete figures either. Maybe some
of
On Fri, 08 Dec 2006 11:33:41 +0100
Vincent Snijders [EMAIL PROTECTED] wrote:
Mattias Gaertner schreef:
On Sun, 3 Sep 2006 22:01:27 -0300
Flávio Etrusco [EMAIL PROTECTED] wrote:
Maybe I read wrong, forms.pp:
@@ -113,7 +112,6 @@
procedure SetSize(const AValue: integer);
Mattias Gaertner schreef:
On Sun, 3 Sep 2006 22:01:27 -0300
Flávio Etrusco [EMAIL PROTECTED] wrote:
Maybe I read wrong, forms.pp:
@@ -113,7 +112,6 @@
procedure SetSize(const AValue: integer); virtual;
procedure SetSmooth(const Value: Boolean); virtual;
procedure
On Sun, 3 Sep 2006 22:01:27 -0300
Flávio Etrusco [EMAIL PROTECTED] wrote:
Maybe I read wrong, forms.pp:
@@ -113,7 +112,6 @@
procedure SetSize(const AValue: integer); virtual;
procedure SetSmooth(const Value: Boolean); virtual;
procedure SetVisible(const Value:
Flávio Etrusco wrote:
I'm at work yet (those modifications are at home), so let me try a
last argument. If you don't buy it I'll make the new patch ;-)
My main point is TWinControls (wrappers around external controls)
shouldn't have to manipulate the control scrollbars in the LCL so
having
I don't understand your reasoning here. Yes, TWinControls shouldn't need
to control the scrollbars (because that's done by the widgetset), and
that is the reason why TScrollingWinControl descends from TWinControl,
to separate that functionality to another class.
I'm saying that there's no use
Flávio Etrusco wrote:
TForm already has almost the same behaviour as if it inherited from
TCustomControl, so we're losing nothing from it.
TCustomControl exposes its canvas while TCustomForm doesn't, IIRC ?
It does. Remember, TForm even has OnPaint event ;-)
Hmm, just looked,
On Fri, 01 Sep 2006 09:21:46 +0200
Micha Nelissen [EMAIL PROTECTED] wrote:
Flávio Etrusco wrote:
TForm already has almost the same behaviour as if it inherited
from TCustomControl, so we're losing nothing from it.
TCustomControl exposes its canvas while TCustomForm doesn't, IIRC ?
Mattias Gaertner wrote:
About the name of TScrollingWinControl:
The VCL version does not provide a canvas. That's an LCL special.
Ah, that explains.
We could derive TScrollingWinControl from TCustomControl to save
some lines of code.
Initial patch seems to do that, but I still am not sure
On Fri, 01 Sep 2006 11:25:39 +0200
Micha Nelissen [EMAIL PROTECTED] wrote:
Mattias Gaertner wrote:
About the name of TScrollingWinControl:
The VCL version does not provide a canvas. That's an LCL special.
Ah, that explains.
We could derive TScrollingWinControl from TCustomControl to
Ok, I've just noticed that in VCL the Canvas is only provided by
TCustomForm and not TScrollingWinControl...
Don't know. Flavio is right, that at the moment only
TScrollingWinControl uses TControlScrollBar and so the code *could* be
moved to save a 'with'. Is there another gain?
Although I
On Fri, 2006-09-01 at 12:49 -0300, Flvio Etrusco wrote:
Again, I can't see any use for overriding/inheriting from
TControlScrollbar... One would have to inherit the control from
TScrollingWinControl and use quite some hacks to be able to change the
instance of the scrollbars to new one...
On Fri, 01 Sep 2006 12:24:20 -0400
Tony Maro [EMAIL PROTECTED] wrote:
On Fri, 2006-09-01 at 12:49 -0300, Flávio Etrusco wrote:
Again, I can't see any use for overriding/inheriting from
TControlScrollbar... One would have to inherit the control from
TScrollingWinControl and use quite
On Fri, 2006-09-01 at 19:19 +0200, Mattias Gaertner wrote:
I've done that... inherit from TScrollingWinControl that is. The
check register component in CheckBook Tracker used that method. I
needed a scrolling win control, but needed the scrollbar to handle
many thousands of entries,
Flávio Etrusco wrote:
Hi all,
the objective of this patch is to create an easy and efficient way to
have scrollbars in custom-controls.
For this purpose it makes TScrollingWinControl inherit from
TCustomControl and moves/separates the routine which 'compute' the
Isn't it more logical to
Isn't it more logical to let TCustomControl descend from
TScrollingWinControl then ? The idea is that none of the 'standard'
widgets in the LCL descend from TCustomControl, because those are
supposed to be user-drawn.
Well, I guess that's an option, too ;-)
But the fact is, most code from
Flávio Etrusco wrote:
Isn't it more logical to let TCustomControl descend from
TScrollingWinControl then ? The idea is that none of the 'standard'
widgets in the LCL descend from TCustomControl, because those are
supposed to be user-drawn.
Well, I guess that's an option, too ;-)
So ...
22 matches
Mail list logo
