Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2018-09

Raw TBitmap objects vs LCL TBitmap properties inconsistencies

1 message · 1 person ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Giuliano Colla

Hi Lazarus experts,

I have noticed a number of apparent inconsistencies which make life a bit complicate if you need to play with visual properties of LCL components.

If you need a different canvas brush, you need to change a button glyph, or to dynamically change a TImage (just to make a few examples), you create your TBitmap, and with a simple assignment instruction you pass it to the component. It works and it's Ok.

But then you're faced with a problem: what to do with the TBimap object you have created?

Coming from Delphi I had assumed that a TBitmap is not copied on another one, but just the pointer to the underlying Handle is copied. This means that you should never free a TBitmap after copying.

But if you use heaptrc you discover that a number of your TBitmaps are still there after closing all the forms.

On the other hand, in some cases if you FreeAndNil a TBitmap which has just been copied to an LCL component you get a crash with an AV.

Up to now my solution has been to enable heap trace, let heaptrc tell me what I need to free, and do it just for those bitmaps.

Is there a better way? i.e. what is the logic behind some LCL components just taking the pointer of a TBitmap and some to create their own internal bitmap leaving the original TBitmap untouched?

Giuliano

Do not do to others as you would have them do to you.They might have different tastes.

Reply by email