Override the Paint method and draw on the Canvas property.
"Bob Richardson" <bo...@pleasenospam.whidbey.com> wrote in message
news:udb97i8...@corp.supernews.com...
The TColorBtn component uses
DrawText(Handle, PChar(Caption), Length(Caption), TRC, DT_CENTER or
DT_VCENTER or BiDiFlags);
to actually draw the text, and that seems to be under the control of
Windoze.
I want to control the drawing, in the same manner that I can in a
StringGrid, using ownerdrawcell.
In particular, I write software for bridge programs. Often I want to show a
bid or contract, using the standard symbols for club, diamond, heart or
spade (which are found in the Symbol font file) and I also want to print
those symbols in red or black, while the rest of the label will be in the
color selected for the Font.
The above DrawText doesn't give me the control I need. In a StringGrid, I
can get this contgrol with TextOut commands.
>
I dion't quite understand - setting color with
Canvas.Font.Color;
...isn't that what you do when OwnerDraw'ing grid cells, too ?
--
Bjørge Sæther
bjorge@hahaha_itte.no
I want part of the label in one color, and part in another color...all with
one label. I also want to use 2 different fonts with the same label.
Perhaps my problem is not knowing the correct message and message structure
for a TLabel. In TColorButton, this is used:
procedure CNDrawItem(var Message : TWMDrawItem);
But CNDrawItem is not a method of TLabel.
I'm guessing that = I need to know what message = of TLabel will trigger a
Draw or Paint. Better yet, I would like to see the actual Delphi coding
that writes on TLabel's canvas.
>> > > a terrible kludge. There must be a better way.
>> > > Is there something like a ownerdraw capability for a tlabel?
There is. TGraphicControl.Paint is virtual.
(Paint is introduced independently in TGraphicControl and
TCustomControl, instead of their common ancestor TControl.
The reason for this is presumably that the class between
TCustomControl and TControl, TWinControl, is meant as a
wrapper base class for Windows controls that, obviously,
Windows knows how to draw. Thanks for making me look that
up. Now the $64,000 question: why didn't you look that up?)
Groetjes,
Maarten Wiltink
Thanks for finding this Maarten.
I was looking for methods under TLabel and it didn't occur to me to look
under TGraphicControl. I too learned a lot in the process.
I'll be quite satisfied when all you learned was something as
simple as checking method lists for ancestor classes, and will
not hold it against people when they don't think of it.
Although I can see the reasons for it (in hindsight), this seems
to me a shortcoming of the hierarchical VCL reference: sometimes
methods fall out of classes that _were_ described in superclasses.
The reasons are three, I think: protected methods aren't accessible
in instantiations of subclasses; methods may be hidden; methods may
be overridden. The first results in dropping the method from the
subclass's list, the other two replace the previous description.
Hiding existing methods is especially problematic; overridden virtual
methods are usually marked as such.
(There's another problem with hiding methods: it makes a complete
mess of method resolution when an object of a derived class is used
as a value declared to be of an ancestor class. I'm not convinced
this is useful at all (counterexamples gratefully received) and have
taken to declaring all methods except private ones virtual. And most
constructors, which may be of some significance, but I don't see it.)
Groetjes,
Maarten Wiltink