Hi Tom
You do great work!
Here is a symptom which might be related (or not). Am only mentioning it because
this also had an invisible font issue. Am busy in Win32 right now, and will
trace the issue further (if it still exists) when I can get back to carbon in a
few weeks.
I had four TPaintBoxes in a TPanel, which are graphic views for an audio wave
display, a location timestrip, a chord strip, and a piano-roll note strip.
Not all paintboxes are erased to the same background color at the start of their
OnPaint procs. The drawing in all paintboxes is a mixture of lines, rectangles,
and text, of various colors. Some Text drawing used transparent mode, and some
did not.
This multiple TPaintBox in a TPanel would draw correctly in Win32.
On Carbon, it appeared that PaintBox canvas properties were somehow 'leaking'
into the parent TPanel canvas, and affecting other TPaintBox OnPaints. The
symptom was that some text would draw with the canvas background color (of some
other paintbox) rather than the current paintbox Font color. This happened even
if I would explicitly set TFont properties before each and every TextOut, in
each OnPaint proc.
If the background of all the TPaintBoxes had been the same, it would have been
completely invisible text. But since the background of the most problematic
paintbox was clButtonFace, and some other TPaintBoxes had a clWhite background,
I was getting white-on-gray text, rather than the desired black-on-gray text.
It may have had something to do with the transparent property leaking between
canvases. Dunno.
I 'fixed' it on the carbon target, by calling Application.processmessages
between each of the TCanvas OnPaint procedures. I think this was flushing the
screen after each OnPaint and avoiding transparency or some other property from
'leaking' between canvases. But the gratuitous calling of ProcessMessages slows
donw the screen update, so it is just a temporary hack.
When I can get back to carbon, will send a bug report with example, if the issue
remains.
Tobias' reported issue seemed similar, I just thought this example might be
related.
====
Here is another 'invisible text' issue--
The default size of Win32 TLabel seems vertically smaller by a pixel or two,
than the text rectangle which Carbon likes to draw into. If the TLabel has a
default background color and font color, it draws the TLabel correctly in spite
of the size discrepancy. In that mode, apparently a TLabel is able to 'overdraw'
the control bounds and successfully put un-clipped text onscreen.
But for instance if the TLabel Color is black, and the TLabel Font color is
green (any non-default color combination would probably show the same bug), then
all you get is a black square with no text, if the TLabel is not tall enough to
fully contain the text.
The fix for that issue was to make the TLabel a few pixels taller than the
default size for Win32, and then it draws green on black just fine.
That is a minor issue. It may be that carbon refuses to draw any text at all in
certain modes, if the destination rectangle isn't tall enough.
So there may not be a realistic fix. Perhaps if a fix was attempted, it would
involve automatically growing the TLabel (or shrinking the TFont) if the Label
is too small to contain the text.
It is just that such minor issues take time to diagnose/fix, and makes the thing
a little less 'cross platform'. But since carbon likes to draw controls more
'spread out' than Win32, it might be that manual form re-spacing is unavoidable
labor when moving code from Win32 to carbon. The minor labor of re-spacing a
form is so much less than 'writing from scratch' when moving between platforms.
jcjr
----- Original Message -----
From: "Tom Gregorovic" <[EMAIL PROTECTED]>
On Nov 18, 2007 12:15 AM, Tobias Giesen <[EMAIL PROTECTED]> wrote:
Hello,
some change made since last week caused my TMemo to use the same color
for the font that is used for the background. Only selected text can be
seen. It does not matter which colors I choose for foreground or
background.
My quick fix is to comment out the body of TCarbonMemo.SetFont in
CarbonEdits.pp. But the actual cause is not in this function, since
CarbonEdits.pp has not changed lately.
Any ideas?
Sorry, that was probably caused by my changes and I have not noticed
such a bug. Look at CarbonCanvas.pp:
procedure TCarbonControlContext.Reset;
begin
inherited Reset;
if CGContext <> nil then
if CurrentBrush <> nil then // apply control background color
begin
if FOwner.LCLObject.Color <> clBtnFace then
CurrentBrush.SetColor(FOwner.LCLObject.Color, True)
else
CurrentBrush.SetColor(FOwner.LCLObject.Color, False);
CurrentBrush.Apply(Self, False);
end;
if FOwner.LCLObject.Font.Handle <> 0 then
CurrentFont := TCarbonFont(FOwner.LCLObject.Font.Handle);
end;
And try commenting last lines. I have not access to Mac at the moment
but I will repair it as soon as I can.
Tom
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
