ScaleRichView 9.0.3 memory leaks and painting issues

ScaleRichView support and discussion (TRichView add-on for WYSIWYG editing)
Post Reply
GoranBru
Posts: 8
Joined: Wed Jan 22, 2020 2:26 pm

ScaleRichView 9.0.3 memory leaks and painting issues

Post by 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
Site Admin
Posts: 14897
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Re: ScaleRichView 9.0.3 memory leaks and painting issues

Post by 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
Posts: 8
Joined: Wed Jan 22, 2020 2:26 pm

Re: ScaleRichView 9.0.3 memory leaks and painting issues

Post by 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
Site Admin
Posts: 14897
Joined: Sat Aug 27, 2005 10:28 am
Contact:

Re: ScaleRichView 9.0.3 memory leaks and painting issues

Post by 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.

Post Reply