2 bugs in TMS Component pack

Running version:

1) TAdvOfficeColorSelector has some drawing bug and loses transparency. This is not a new bug but it has been here for years (unless I missed something)!

Note that when the color is chosen (or when the SelectedColor propery is set to some color), the associated image loses transparency as shown above (aliased edges of the circle). Before the color is selected the image is smooth.The "Transparent" property is set to true.

Also, the "Automatic" has a weird line drawn over it. This happens when drop-down is clicked then mouse is moved over "Automatic" and then moved more to some of the colors. When the mouse is out of the "Automatic" the line appears. I managed to reproduce this on WinXP and the same thing on Win7 did not cause such line. Any possible explanations?

2) second bug is something related to TAdvMemoUndo action. I have a project which compiles fine with (2018-06-19) release of the component pack. The installation goes through fine. Upon the compilation the error is reported - E2303 Type name expected for TAdvMemoUndo        *Act_AdvMemoUndo; line. It seems that there has been some change regarding that. However, I managed to avoid the problem by adding #include "AdvMemoActions.hpp" line in the header. It seems that older version did not insert or need this header. So this is not a problem and it works after adding the header but I wanted to point out that this could potentially cause issues with older project.

Also 2 related questions:

A) is it possible to change the names "Automatic" and "More Colors..." for localization purposes

B) is it possible to customize the above color dialog by replacing with one's own colors or maybe even expanding the dialog with more colors, larger color boxes and similar.

Thank you in advance.

Ignore the question A and question B about replacing colors. I found the
Tools property. Only the question is it possible to make the color
boxes larger (customize width/height)?

Ignore all the questions, I found ButtonsPerRow property as well. Only the bug (1) remains.

Comment about the TAdvOfficeColorSelector drawing bug and transpareny issue please?

What kind of picture image format do you use? I have retested this here with a transparent PNG and I could not see a problem with the drawing of the picture on the control.

I use transparent PNG as well (24 + 8 bits for alpha channel). Actually, I assigned standard TImageList to it and then set the ImageIndex. But the problem doesn't occur until you set the color. Before the color is set it looks fine:

I now noticed also another problem with this.

The picture on the left is before the color is selected. Transparent PNG is shown fine. The same appears if you load it from TImageList and use ImageIndex or if you use Picture property to load it. Same result, picture is shown centered and transparency is good.

The middle picture is using TImageList and ImageIndex as a source for the image. When a color is selected the picture stays vertically in the same position (as it is supposed to) and gets overlay color but adding the overlay color destroys the transparency. That is likely the problem here. TImageList is also loaded from 32bit PNG (24+alpha).

The right picture is using Picture property (picture is assigned at design time). Has same problem like the middle one which uses TImageList but moves the icon 4 pixels up (which I assume is not what should be happening, picture should stay in the same spot with overlay drawn over it).

So this is 2-in-1 bug actually.
The icon I used for testing is from famfamfam set - http://www.famfamfam.com/lab/icons/silk/
(color_wheel icon)

We've seen this issue when using an imagelist with PNG images.
A immediate solution is to assign the PNG directly to TAdvOfficeColorSelector.Picture instead. 

We'll further investigate the transparency handling related to a PNG used in an imagelist but it does not look to be a trivial issue.
I have to disagree Bruno and sorry to say, what you suggest is not the solution, it makes the problem even worse.

Have you read my post, posted at 12:16am? I have already tried to apply the PNG to the "Picture" property and that only makes the problem worse as already explained 3 posts above this one (picture on the right) that the image moves up and does not get covered by the overlay color as it should (middle picture) and in addition to that also loses the alpha-transparency when the color is selected.

So using Picture property is not the solution, it makes the problem worse as I've already shown above.

Additionally, PNG is not applied to TImageList. TImageList cannot really store images. What I do is load PNG into TPngImage and then do CopyRect into Graphics::TBitmap created at runtime (the 32-bit TBitmap) and then finally copy such images into the TImage list (cd32Bit) with:         bmp->AlphaFormat = afIgnored;
ImageList->Add(bmp.get(), NULL);

So the TImageList contains the 32-bit alpha bitmap and not the PNG. PNG is not the issue.

Additionally, it works fine - until the layer of color is applied on top of the bitmap which destroys the alpha transparency. So it works fine until the 4x16 block of selected color is added on the top of the icon - which should preserve the transparency, but it doesn't.

As I said already, this problem has been around for a few years now. It might not be trivial issue, I understand, but does it take a few years to get fixed?

We have applied an improvement that will make the button draw better with transparency.
this improvement will be included in the next update.

Thank you for the prompt reply, looking forward to test it.

Unfortunately, the problem with alpha transparency is still not solved. Basically, nothing has been done.

It has been now 4 months since I originally reported it. Please offer a specific date when you plan to address this bug?

Additionally, there is a problem with the height of the color line. It is of 4 pixels in Height. Which is fine if the icon is 16x16. But in above case, icons are 64x64 to ensure good visibility on HighDPI screen. The color line is tiny on such a display - it should be 16 pixels height (proportionally sized).
Even further, there is another bug with high DPI:

Clicking the area pointed to by left arrow clicks the button (does not open the color popup). Only clicking the right arrow part opens the color popup.

Also, the drop-down indicator arrow is clearly not centered all of which indicating a problem with DPI calculation.

We traced & fixed both issues. These will be addressed in the next release.

I am very disappointed!

In the latest release you've finally fixed the rough edges (not using the alpha channel) of the button TAdvOfficeColorSelector - but now the color selection is ENTIRELY GONE!

Very, very, very, very disappointed! Your quality control is almost non-existent. I've requested fixing bugs countless times just to have more bugs introduced with each new "fix". You spread yourselves thin between too many components and the ones which I use always have some bugs.

The worst thing, I cannot now go back and I am now held hostage to your next release as I discovered the problem after replacing the installed version of TMS component pack and it is quite complicated to install old version back and adjust all the rest of the code.

Please fix the new problem and missing color ASAP (without again introducing the alpha channel bug)!!!!

  1. If you overlooked to make a backup, contact us by email for a previous version
    2) Contact us by email if you need an incremental source update. The color bar issue could only be seen here when an imagelist image was used for the button. It works when the image is set via the Picture property
This is the result I get when I load your custom Picture format from TMemoryStream.

TAdvOfficeColorSelector* c = static_cast<TAdvOfficeColorSelector*>(myadvofficecolorbutton);
c->Caption = "mycaption-irrelevant";
c->Hint = "myhint-irrelevant";
// c->ImageIndex    = 0; // removed because it doesn't work now!
//c->Images = MyImageListPtr; // removed because unnecessary
c->Transparent = true;
c->Height = 16; // or 64 in example 2
c->Width = 16;  // or 64 in example 2

boost::scoped_ptr<Graphics::TBitmap> bmpSrc(new Graphics::TBitmap);
boost::scoped_ptr<TMemoryStream> ms(new TMemoryStream);
MyImageListPtr->GetBitmap(0, bmpSrc.get());
ms->Position = 0;




So again 3 bugs (2 new, 1 old)

- new: the offset appears for the color bar

- new: the color bar doesn't work for TImageList imageindex like it used to work

- old: the bar is fixed 4 pixels height, instead of 25% of the button. The point of the use of larger button is for 4K screens and to see the color bar of the appropriate size, not the tiny "2 pixel" line which is how it looks on a 4K screen. The correct solution would be to use 25% of the button size, that is 4 pixels on 16x16 and 16 pixels on 64x64 (shown above).
And now I also noticed that the total height is 17 pixels, and not 16 (drawn lines to show the problem). So add that as another bug to the list...

Another test, with picture loaded from file, instead.


The used picture is this (16x16 with 4x4 squares):

The result, enlarged:

What is going on is that the color is centered to the width of the button, not just the image on the left side.... if drop-down is introduced, the color bar moves to the right. That is the reason for faulty centering. I'll leave you to your bug-fixing.