After having moved from TStringList over TStringGrid (which both cannot be shifted right to make long text visible) I now use TMemo. But again I have another issue with this component: If there are more rows than can be displayed in the window and I change the text in the last row (Lines.Count-1) rapidly then the whole display flickers. This OnClick event demonstrates it:

-------------------------------------------------------
with Memo1 do
    begin
    for i := 1 to 40 do
       begin
       if odd(i) then
Append('\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\')
       else
Append('+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++');
       end;
    for i := 1 to 1000 do
       begin
       Lines[Lines.Count-1] := '#### LAST LINE ---'+IntToStr(i)+'-----------------------------------------------------------';
       Application.Processmessages;
       end;
    Memo1.Lines[Lines.Count-1] := '#### READY #### ';
    end;
-------------------------------------------------------

When you click on the memo (so that the routine runs) and the window is small enough then all lines are shifted down for a short time and then are shifted up again when writing to Memo1.Lines[Lines.Count-1]. This flicker is quite disturbing and it does not happen when there are only a few lines (which fit in the window). Is this a known bug?

Have you tried wrapping your writes in memo1.Lines.BeginUpdate and memo1.Lines.BeginUpdate?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130429/8c02ad11/attachment.html>

That should have been Endupdate...
From:
To:
Subject: RE: [Lazarus] TMemo flicker
Date: Mon, 29 Apr 2013 16:38:17 +0000

Have you tried wrapping your writes in

memo1.Lines.BeginUpdate and memo1.Lines.BeginUpdate?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130429/b29d2f5c/attachment.html>

K. P. wrote

Have you tried wrapping your writes in memo1.Lines.BeginUpdate and memo1.Lines.BeginUpdate?

I have tried it now but it doesn't change anything. -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130429/7e0ff2b6/attachment.html>

Hi,

you can try

TForm1.FormCreate(Sender:TObject);
begin
   Memo1.DoubleBuffered:=True;
end;

In addition to wrapping the writes within BeginUpdate/EndUpdate simply remove the Application.ProcessMessages call that is repeated within your loop. It is completely unnecessary and serves only to produce the flicker.

This is not true. I added this only later to be able to exit from the program within the loop. It does *not* change anything regarding flicker. Also Begin/endUpdate does not change it. These would only apply if I do *massive* changes and I only want to make the result visible. But I only change one single line (the last one) and it already flickers.

It doesn't change anything either.

Be aware that it flickers when writing/changing one single line of the TMemo component. And there is text in this line before and after the change so there should be no shift or any other change in display except the text in this line. So it has to be a bug in the display routine.

Maybe someone can just try my example program.

The problem seems related to the fact that TMemo tries to keep an empty de TMemo problem, as far as logging goes you'd better use TSynEdit ;-)

Best regards,
Fl?vio

K. P. wrote

Have you tried wrapping your writes in memo1.Lines.BeginUpdate and memo1.Lines.BeginUpdate?

On the contrary. I would expect Begin/EndUpdate to increase flickering, because they'll usually trigger a full repaint. They are only useful to speed up when you're are changing several lines.

Best regards,
Fl?vio

They're usefull whenever you do bulk load, since Begin/EndUpdate should guarantee in any widgetset:
1.No painting
2.No scrolling

They should reduce flickering to minimum.You see flickering because of scrollbar moving up/down when you use Application.Processmessages inside line loading loop.

z.

J?rgen Hestermann wrote

Maybe someone can just try my example program.

what sample program? i've only seen a portion of a routine (onclick??) you've posted... but no sample program...

J?rgen Hestermann wrote

Maybe someone can just try my example program.

OK, now I've tested a bit and BeginUpdate/EndUpdate works for me (Win7 x64, FPC and Laz Trunk):

procedure TForm1.Button1Click(Sender: TObject);
var i:Integer;
begin
   Memo1.Clear;
   for i := 1 to 40 do
   begin
     if odd(i) then
Memo1.Append('\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\')
     else
Memo1.Append('+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++');
   end;
   for i := 1 to 1000 do
   begin
     memo1.Lines.BeginUpdate;
     Memo1.Lines[Memo1.Lines.Count-1] := '#### LAST LINE
---'+IntToStr(i)+'-----------------------------------------------------------';
     memo1.Lines.EndUpdate;
     Application.Processmessages;
   end;
   Memo1.Lines[memo1.Lines.Count-1] := '#### READY #### ';
end;

It should be
   memo1.Lines.BeginUpdate;
   for i := 1 to 1000 do
     Memo1.Lines.Add('#### LAST LINE  ---'+IntToStr(i)+'-----------------------------------------------------------');
   memo1.Lines.EndUpdate;
   Application.Processmessages;

What you did makes no sense whatsoever.
The whole point of beginupdate/endupdate is to mark a list of changes, and to prevent the UI from updating while you do the changes.

The use of Add() is easier to understand.

Michael.

But this way you wouldn't see the progress.

Including only
Memo1.Lines[Memo1.Lines.Count-1] := '#### LAST LINE ---'+IntToStr(i)+'-----------------------------------------------------------'; will also include all calculations of TMemo so you prevent flickering and see the progress. This makes sense to me.

Your solution of course is mutch faster but I thought seeing the progress is important for J?rgen.

Ingo

In that case the beginupdate/endupdate is a total waste of CPU.

Michael.

El 30/04/2013 10:31, Michael Van Canneyt escribi?:

> Your solution of course is mutch faster but I thought seeing the > progress is important for J?rgen. In that case the beginupdate/endupdate is a total waste of CPU.

Hello,

The problem is that the behavior changes with the use of begin/end update, at least on Windows platform. Run attached code to test. Just create a form and add a button and a Memo and link the button OnClick with this code (better visible with a quite big Memo):

-------------------------------

procedure TForm1.Button1Click(Sender: TObject);
const
   TestMode=3; //CHANGE to 1..3 to run different tests
var
    i: integer;
begin
   for i := 1 to 40 do begin
     Memo1.Lines.add('Some lines at the beginning to watch the up/down
flicker effect.');
   end;
   if TestMode=1 then begin
     for i := 1 to 1000 do begin
       Memo1.Lines[Memo1.lines.Count-1]:='#### '+IntToStr(i);
     end;
   end else if TestMode=2 then begin
     for i := 1 to 1000 do begin
       Memo1.Lines.BeginUpdate;
       Memo1.Lines[Memo1.lines.Count-1]:='#### '+IntToStr(i);
       Memo1.Lines.EndUpdate;
     end;
   end else if TestMode=3 then begin
     for i := 1 to 1000 do begin
       Memo1.Lines.BeginUpdate;
       Memo1.Lines[Memo1.lines.Count-1]:='#### '+IntToStr(i);
       Memo1.Lines.EndUpdate;
       Application.ProcessMessages;
     end;
   end;
end;
--------------------------------

If Begin/End update is being used the vertical scroll bar position is not updated, I do not know if this is expected :-?

This i cannot say.

What I can say is that, given the purpose of beginupdate/endupdate, in the above code, using beginupdate/endupdate is totally pointless.

Not to mention that you should always use try/finally with beginupdate/endupdate

BeginUpdate;
try
   // Do your thing
finally
   EndUpdate;
end;

Michael.

Michael Van Canneyt wrote

What I can say is that, given the purpose of beginupdate/endupdate, in the above code, using beginupdate/endupdate is totally pointless.

Indeed. BeginUpdate/EndUpdate should be outside the loop.

Regards,
- Graeme -

(code sample)

Jos? is indeed right. BeginUpdate fixes the back-and-forth scrolling in Windows. Not sure whether I should take back my previous comment or just say this is unexpected ;-)
On a side note, for displaying immediate changes in a control I'd argue that "MyControl.Update()" is the correct thing to do (instead of ProcessMessage). Not sure it works on all platforms though...

-Fl?vio

Fl?vio Etrusco wrote

Jos? is indeed right. BeginUpdate fixes the back-and-forth scrolling in Windows.

Yes, I now see this too. In my first quick test in a hurry I surrounded the wrong code line with Begin/EndUpdaste. ;-( I must admit that I did not pay very much attention because as I said I was in a hurry and I also did not expect any change so my expectations were complied. ;-)

Not sure whether I should take back my previous comment or just say this is unexpected ;-)

Yes, I also didn't expect this change because I only had a single (atomic) assignment. If the assignment leads to multiple commands internally I would have expected that the Begin/EndUpdate would also be applied internally.

On a side note, for displaying immediate changes in a control I'd argue that "MyControl.Update()" is the correct thing to do (instead of ProcessMessage).

I only added ProcessMessages because I wanted to be able to close my program within the loop. It was not for updating anything.

Yes, from a programmers point of view this is completely pointless if you surround a single assignment with these commands.

But it seems that internally a lot more is done which is *not* embraced with these commands. That's realy tricky because (again) you need to know about the internals to do the right thing. Of course, if you do many changes to TMemo and each would raise Begin/EndUpdate pairs internally it would slow down everything significantly I think. So if you know all this it makes sense. But this information should be written to the TMemo doku at http://lazarus-ccr.sourceforge.net/docs/lcl/stdctrls/tmemo.html .

J?rgen Hestermann wrote

embraced with these commands. That's realy tricky because (again) you need to know about the internals to do the right thing. Of course, if you do many changes to TMemo and each would raise Begin/EndUpdate pairs internally it would slow down everything significantly I think.

If that is the case, then it is a bug in LCL. Even if there are nested Begin/EndUpdate calls, that should make no difference. As long as those calls are in pairs, and as soon as the last EndUpdate is called, then the whole component should refresh/repaint - that includes contents, scrollbar adjustment etc.

That's how it works in Delphi's VCL and in fpGUI. Nothing complicated or tricky. Before you populate any GUI component with large amounts of data, call BeginUpdate before and EndUpdate after.

Regards,
- Graeme -

Yes, after thinking about it a bit more there should be an internal Begin/EndUpdate somewhere in the corresponding LCL routine. I first thought that each Begin/EndUpdate pair causes code generation but actually it is the opposite (if nesting is allowed).

That's how it works in Delphi's VCL and in fpGUI. Nothing complicated or tricky. Before you populate any GUI component with large amounts of data, call BeginUpdate before and EndUpdate after.

Yes, if the *programmer* does multiple things to a GUI component. But here it was only a single assignment which should not require Begin/EndUpdate but this assignment seems to cause multiple things internally which make it flicker .

El 01/05/2013 12:16, J?rgen Hestermann escribi?:

Hello,

Before looking inside the LCL code the effect could be explained as TMemo text property is completly erased and rewritten each time something change in the text, so when the last line is changed, internally the whole content is erased and replaced by the new one. When the OS component receives the new text it seems to send some messages to itself to adjust scrollbars (which begin/end update will block), the first one remove scrollbars, the next one fill the text, as the text is larger than visible part scrollbar goes to the bottom (this will not happend with begin/end update).

The strange thing is that this behavior should produce high CPU usage but not a up/down one line effect, so something is wrong either in LCL or in the Memo Windows control.

Unlike a ListBox, a Memo has a current character position. When that position is not set properly, the "current" line may change with every update.

DoDi

El 01/05/2013 13:45, Hans-Peter Diettrich escribi?:

Unlike a ListBox, a Memo has a current character position. When that position is not set properly, the "current" line may change with every update.

Hello,

I know, but the problem seems to be located in the Windows Memo, after a few tests it behaves different if WM_SETREDRAW is involved and the back and forth for the text happends because to add text the code must select a line (or a new empty line to add new text) and replace it. This replace effect removes the line, adjusts the memo and then replace its position with the new line and add a carriage return and adjust again the memo. So lines goes up and down for each new line added.

From my point of view this is a Windows memo bug.

Using Memo.Lines should work better, if should split the text into lines, update the lines, then pass the new text back to the memo.

DoDi

El 01/05/2013 15:59, Hans-Peter Diettrich escribi?:

Using Memo.Lines should work better, if should split the text into lines, update the lines, then pass the new text back to the memo.

Hello,

I understand that your suggest is to replace allways the whole text in the visual widget ? That will involve completly redraw of the component which, quite sure, will be even worst and the fact that you loose your caret position.

I had tested it and the effect is visually the same as surrounding the code with begin/end update but slower.