Open HLampke opened 1 year ago
Do you have a fix for this?
Not yet. As a hot fix for our progam I just commented out the call of ResizeGlyph. Today I'll examine the behaviour/display of the table checkbox without the R88 change on high dpi monitors respectively on systems with display scaling. I'll report the results, that means whether scaling is needed, and when it is needed, I'll try to develop a working solution.
I have tested different monitor types and scalings. My application was compiled with option "AppDPIAwarenessMode = PerMonitorV2". Due to the lack of ResizeGlyph, all optical results where correct:
I think the methodes ResizeGlyph and therefore TOvcTCCustomGlyph.Loaded are obsolete and can be removed - respectively must be removed because of the described error. In TOvcTCBaseBitMap.tcPaint the painting is done, and there you can see that the destination rectangle is calculated and that TableCanvas.BrushCopy(DestRect, ...) does the scaling.
In R88, TOvcTCCustomGlyph.ResizeGlyph was added for high DPI support. It scales the given bitmap if screen resolution is higher than 150 percent respectively 144 dpi. The methode is called in TOvcTCCustomGlyph.Loaded. The problem is, that every instance (!) of TOvcTCCustomGlyph, e.g. TOvcTCCheckBox, calls the methode with the common (!) CellGlyphs.BitMap, so that the bitmap grows and grows, up to the moment it is too big, which leads to an EOutOufResources exception in Vcl.Graphics.CopyBitmap. The error is reproduceable by first setting the windows scaling of fonts and apps to 175 % or more and then multiple open and close a Dialog with an orpheus table containing at least one TOvcTCCheckBox.