ScaleRichView 9.0.3 memory leaks and painting issues

[GoranBru]

Hi,
I am in process of switching all TcxRichEdit to TScaleRichView or TRichView components and with TScaleRichView I have found issues that should be fixed somehow. The first is memory leak when users switches display layout, e.g. from Draft to Print/Web. Actually it is enough that user only opens the form with TScaleRichView on it and closes, then MadExcept returns memory leak errors with TBitmap.
The thing is that I am now working with the biggest and most important form when user can create medical reports in a form with TScaleRichView. I basically copied the components and quite some code from the demo that uses TScaleRichView and actions and then implemented some modifications, also using the demo with editor without actions (for Layout views). The base form for writing these documents has embedded form on which is the actual editor with TScaleRichView. I don't like to use frames so I used embedded form. When user just opens the base form and closes, then memory leak appears in MadExcept on TBitmap. Slight investigation to the code show that the problem is in unit SRVToolBar.DrawButton as imgTemp does not frees. Yes, I have TActionList, all the images for the HMenu and VMenu as well as images for toolbars (I use Dev express bar manager) are in TImageLIst but looks like imgTemp is not freed at the end of procedure SRVToolBar.DrawButton. At the moment I added the code

Code: Select all

    if Assigned(imgtmp) then
      imgtmp.Free;

before last two end's in the procedure and seems this solves the problem.

The other issue is with painting. Switching between layouts produces black scrollbars as well as zoom panel, HMenu and VMenu. Just moving mouse over them shows the blackened components. I do not use skins in the software but I have changed the colours of components as we don't use clBtnFace but rather a bit bluish panels, buttons and so on. Unfortunatelly I can't trace the source of this problem and I do not have any idea how to resolve this. At least I can say it is annoying and if there is a solution for this I would be glad to use it.

Oh and speaking of the color, if one changes the properties

Code: Select all

TSRichViewEdit.BackgroundProperty.ColorBegin := clBtnFace
TSRichViewEdit.BackgroundProperty.Visible := False

the form crashes. As the value for clBtnFace is negative then conversion to Red/Blue/Green produces negative values and as RGB < 0 is not valid produces Range check error in SRVZoomPanel.GetColorOff.

Best regards,
Goran

[Sergey Tkachenko]

Thank you for the bug report!

1. Yes, you can change the code like this to remove the leak. The better solution is creating imgtmp only if ScaledImage = True.
(this bug was added in a recent version when support for multi-resolution Lazarus image list was added).

2. In SRVZoomPanel.GetColorOff, color must be converted by ColorToRGB function before calculating R,G,B, like this:

Code: Select all

var Clr: TColor;
    ...
    Clr := ColorToRGB(SRV.BackgroundProperty.ColorBegin);
    curColorR := round(GetRValue(Clr) * Value);
    curColorG := round(GetGValue(Clr) * Value);
    curColorB := round(GetBValue(Clr) * Value);
    ...

3. As for the black scrollbar.
Which version of Delphi/Lazarus do you use? Do you use third-party components, like TMS:
Try compile your project with the compiler $define SRVNOGROUPSCROLLBARREPAINT

[GoranBru]

Hi Sergey,
at the moment I modified the code as I wrote in my post that the application is working okay. I hope it will be useful for the next version when You shall publsih it.
Sorry for not writting down the Delphi version. I am using Windows 10 Enterprise in full Slovenian translation, Delphi is Delphi 10.1 Berlin with Update 2. In the application we use DevExpress components almost exclusively, currently version 18.2.11. We do use inheritance also with forms a lot thus non of the forms is not on general TForm but rather their descendants for normal form and for modal form. The base form thus have some innocent things like general font on form, setting doublebuffered to true to all TPanels and so on. But looking at the code, somebody has added the following code which might influence somehow:

Code: Select all

interface
uses
....
private
...
   procedure WMDpiChanged(var Message: TMessage); message WM_DPICHANGED;
..
end;

const
  WM_THEMECHANGED = $031A;
  WM_DPICHANGED = 736; // 0x02E0
...

procedure TFADXForm.WMDpiChanged(var Message: TMessage);
{$IFDEF DELPHI_STYLE_SCALING}
  function FontHeightAtDpi(aDPI, aFontSize: integer): integer;
  var
    tmpCanvas: TCanvas;
  begin
    tmpCanvas := TCanvas.Create;
    try
      tmpCanvas.Handle := GetDC(0);
      tmpCanvas.Font.Assign(self.Font);
      tmpCanvas.Font.PixelsPerInch := aDPI; //must be set BEFORE size
      tmpCanvas.Font.size := aFontSize;
      result := tmpCanvas.TextHeight('0');
    finally
      tmpCanvas.free;
    end;
  end;
{$ENDIF}
begin
  inherited;
  {$IFDEF DELPHI_STYLE_SCALING}
  ChangeScale(FontHeightAtDpi(LOWORD(Message.wParam), self.Font.Size),
  FontHeightAtDpi(self.PixelsPerInch, self.Font.Size));
  {$ELSE}
  ChangeScale(LOWORD(Message.wParam), self.PixelsPerInch);
  {$ENDIF}
  self.PixelsPerInch := LOWORD(Message.wParam);
end;

I can't even track how long this code is in so I believe it is from time when we used Delphi XE or even Delphi 2006. I remember that there were some issues with "large fonts" under Windows Vista and Windows 7. Maybe this could help?

[Sergey Tkachenko]

This code is executed if "per monitor" DPI support is enabled in manifest. This message is sent when the user changes the system DPI, or when a window is moved to a monitor having different DPI. It should not be called otherwise.

[GoranBru]

Hello,
I had a lot of work from the past message so I couldn't answer. I still have painting issues with the TScaleRichView component even though I added {$define SRVNOGROUPSCROLLBARREPAINT} in DPR file.
Here is screenshot of same window with problematic painting:

Here zoom panel, horizontal bar and vertical bars are in black:

Moving mouse aboive these three elements paints them as tey should be.

Also horizontal scrollbar can be black...

Usually it paints in black when Zoom is less than 100% and moving mouse over it does not repaint it in proper colours. It doesn't matter if the view is Draft, Web or Print....

And finaly a rare view when everything is okay...


As I wrote before the O/S is Windows 10 Enterprise bld 1909, development is in HyperZ Win 10 bld 1909 (completely in slovenian language), Delphi 10.1.2 Berlin. Our application has Main form which opens many modal forms and the editor with TScaleRIchView component is placed on yet another form which is embedded on larger form. The menus are from DevExpress (version 18.2.11 at the moment), all printing is made using ReportBuilder 20.02. Any ideas how to resolve this ugly painting?

[Sergey Tkachenko]

Maybe Devexpress somehow interfere to scrollbar painting... Please wait for the next update (planned later in this week). In this update, TSRVScrollBar will not be based on a standard scrollbar anymore.

[GoranBru]

Hello,
thank You for this news. I'll test it as soon as possible then and will get back to You. It might be something on it, Your demos do work okay.

[Sergey Tkachenko]

We just uploaded TRichView 18.3 + ScaleRichView 9.1.

This update fixes the toolbar leak and the zooming panel drawing procedure.
TSRVScrollBar is not inherited from TScrollBar anymore, please check if this change fixed the blackout problem.

[GoranBru]

Hello Sergey,

thank You for the news but... painting problems are now better but still, the horizontal menu, vertical menu and zoom panel still have blackouts. Vertical scrollbar so far looks okay. Zooming now works but really, I had to go to project options and in compiler options add the directive RVKERNELWINVERCHECK. It's a pitty that
{$define RVKERNELWINVERCHECK}
in DPR does not work.

Best regards,
Goran

[GoranBru]

One more thing which may help You. When the slider on horizontal scrollbar is smaller than the space, then horizontal scrollbar is okay. When the slider occupies whole space, then it goes black. The easiest way to reproduce the problem is CTRL+mouse scroller on print view.

Best regards,
Goran

[Sergey Tkachenko]

Sorry for delays, I am currently in a hospital, nothing serious, but I'll be here for a couple of days. Can you meanwhile prepare a simple project reproducing this problem?

[Sergey Tkachenko]

Finally, it seems I found a solution for the problem of black scrollbars and panels when TSRichViewEdit is used together with TMS components.
Assign False to SRichViewEdit.DoubleBuffered.
This setting will be default in the next update.