TBitBtn no longer shows glyphs in transparent.

[TRon]

Thank you for the heads up dsiders. I am aware.

For LCL I always seem to be faster using your docs instead of using the official ones and on top of that the darn search engines seem to be literally wasted with links to FPC/Lazarus wiki articles instead of direct links to the LCL documentation (I definitely most absolutely dislike that as it is a waste of time: you can manually add fpc and/or lazarus wiki to your search for that).

[dsiders]

For LCL I always seem to be faster using your docs instead of using the official ones...

I am glad they're useful. But remember, they're for the main branch and may not match the code in the last release or the fixes branch.

[jamie]

I don't report bugs often.  This one i am reporting.

I corrected my local sources and its correct now.

Thank you

[wp]

RequestTransparentColor [...] is called when the value tmFixed is assigned to the TransparentMode property.

RequestTransparentColor examines pixels in the raw image data to get the return value for the method. It gets the color for the pixel located at the bottom-left corner of the image (x = 0, y - Height-1).

These sentences are a bit confusing: Only when TransparentMode = tmAuto the transparent color is determine from the lower/left pixel. When TransparentMode = tmFixed the TransparentColor is used as specified.

The attached project shows one of the old Delphi bitmaps in two speedbuttons. The upper one has TransparentMode = tmAuto, and the transparent color is automatically determined from the pixel in the lower left corner. The lower one has TransparentMode = tmFixed and TransparentColor = clBlack - here only the border of the arrow is painted transparent.

[jamie]

Please examine the setter code i posted from the sources of 3.4
U can see its backwards.

I've notice lots of code in the sources use the mask procedure to set the color.

BTW. This is from 3.4 32bit windows

I didn't test others. This use to work .

[dsiders]

RequestTransparentColor [...] is called when the value tmFixed is assigned to the TransparentMode property.

RequestTransparentColor examines pixels in the raw image data to get the return value for the method. It gets the color for the pixel located at the bottom-left corner of the image (x = 0, y - Height-1).

These sentences are a bit confusing: Only when TransparentMode = tmAuto the transparent color is determine from the lower/left pixel. When TransparentMode = tmFixed the TransparentColor is used as specified.

The attached project shows one of the old Delphi bitmaps in two speedbuttons. The upper one has TransparentMode = tmAuto, and the transparent color is automatically determined from the pixel in the lower left corner. The lower one has TransparentMode = tmFixed and TransparentColor = clBlack - here only the border of the arrow is painted transparent.

Noted. I'll revisit the topic. That's why I appreciate feedback.

[dsiders]

I have a patch for the topic which contains:

Code: Text  [Select][+][-]

1. Gets the color used to represent transparent pixels in the image.
2.  
3. RequestTransparentColor is a TColor function used to resolve the color
4. value for transparent pixels in the image. It is used to translate the
5. value clDefault in the TransparentColor property to an actual color value.
6.  
7. When TransparentColor is set to clDefault, the return value for the method is
8. used as the color for transparent pixels. The return value is the pixel color
9. stored at the bottom-left corner of the image (x = 0, y = Height-1).
10.  
11. If TransparentColor contains a different TColor value, it is used in its
12. unmodified form.
13.  
14. When Empty returns True, raw image data is not available and the return
15. value is set to clNone.
16.  
17. RequestTransparentColor is also called when the value in TransparentMode is
18. changed to tmAuto. If TransparentMode is set to tmFixed, the TransparentColor
19. is used as specified.
20.  

Let me know if this sounds a little more coherent.

--
Don

[jamie]

No, sorry try again.
There was nothing wrong with the description as it was before.
Code isn't correct, that's the issue.

When TransparentColor is set to clDefault, the return value for the method is
used as the color for transparent pixels. The return value is the pixel color
stored at the bottom-left corner of the image (x = 0, y = Height-1).

That is incorrect.
  Only setting the TransparentMode  to tmAuto will fetch the color at the lower left.
 Transparent color otherwise will be cldefault for  tmFixed  or when user code sets it directly to something else using the
TransparentColor property.

RequestTransparentColor is also called when the value in TransparentMode is
changed to tmAuto. If TransparentMode is set to tmFixed, the TransparentColor
is used as specified.
 

This is correct however, currently implementation of code is backwards so the two modes tmAuto and tmFixed are switched.
That is the bug!!!!!!!!!!!!


 

[dsiders]

When TransparentColor is set to clDefault, the return value for the method is
used as the color for transparent pixels. The return value is the pixel color
stored at the bottom-left corner of the image (x = 0, y = Height-1).

That is incorrect.
  Only setting the TransparentMode  to tmAuto will fetch the color at the lower left.

I don't think so. The existing code calls the method for tmFixed:

Code: Pascal  [Select][+][-]

1. procedure TRasterImage.SetTransparentMode(AValue: TTransparentMode);
2. begin
3.   if AValue = TransparentMode then exit;
4.   FTransparentMode := AValue;
5.  
6.   if AValue = tmAuto
7.   then TransparentColor := clDefault
8.   else TransparentColor := RequestTransparentColor;
9. end;
10.  

It also calls the method when setting the TransparentColor:

Code: Pascal  [Select][+][-]

1. function TRasterImage.GetTransparentColor: TColor;
2. begin
3.   if FTransparentColor = clDefault
4.   then Result := RequestTransparentColor
5.   else Result := FTransparentColor;
6. end;
7.  

I can only document what currently exists. I get it that you think the implementation is wrong. File a bug report. When committed, I'll revise the docs again.

[Awesome Programmer]

This still doesn't work on Lazarus 3.8. I recently downloaded and installed Lazarus 3.8 and re-doing/cleaning/updating my program's windows just like Jamie. This TBitBtn feature won't work. Is there any updates on Lazarus in this regards?

[jamie]

This still doesn't work on Lazarus 3.8. I recently downloaded and installed Lazarus 3.8 and re-doing/cleaning/updating my program's windows just like Jamie. This TBitBtn feature won't work. Is there any updates on Lazarus in this regards?

Good luck in trying to convince them that is wrong!

To stay compatible between Delphi and here I use a lot of if thens,  in line.

The logic currently is backwards incorrectly implemented!

Have a good day.

[wp]

Good luck in trying to convince them that is wrong!

Is there a bug report for it? You mentioned above that you wanted to write one, but I did not find it. Not every developer reads the forum.

I agree with your observation that the behaviour is confusing. But I disagree that it is a regression, I checked the code in reply #9 with versions back to Laz 1.4.4, the oldest version that I have on my disk, and they all have the same behaviour the we see today: Bitmap color transparency is working only when the TranparentColor is set explicitly and when Transparent := true is the last instruction. In other words: It NEVER worked as it should...

[jamie]

I could be wrong, but I believe the problem is actually Tbitmap operations.  This control just happens to be taking a hit from it.

Jamie

[wp]

I found a solution by commenting out the "property-change-detection" lines in TRasterImage.SetTransparentMode and .SetTransparentColor:

Code: Pascal  [Select][+][-]

1. procedure TRasterImage.SetTransparentMode(AValue: TTransparentMode);
2. begin
3. //  if AValue = TransparentMode then exit;
4.   FTransparentMode := AValue;
5. ....
6.  
7. procedure TRasterImage.SetTransparentColor(AValue: TColor);
8. begin
9. //  if FTransparentColor = AValue then exit;
10.   FTransparentColor := AValue;
11. ...

But that's not the whole story. It is not clear at all why setting Transparent to true cannot be alone (TransparentMode=tmAuto is default), and why it must be the last operation in this sequence (unlike in Delphi).

[jamie]

The last time I looked at that I believe the logic is too early when the transparent property is set to true, it goes out and defines the colors then.

 What should be happening is prior to drawing the image, it should check the Transparent property and then go out and get the color needed via the transparent mode which by this time should have already been set. So, if it's in auto, it will get the color from the lower left of the image, otherwise it will get it from the color field, whatever it is at the moment.

As you have seen, the Transparent property must be last because that is when it goes out and sets up the color values, it shouldn't be setting nothing but the Transparent flag and that's it.

 As I said, prior to drawing, is when these fields need to be examined and setup and allowing other properties to be set in any order.


  It's a confusing mess and I have no idea how long it's been there.

  Jamie.