Paint issue after resizing window.

[MShark67]

It looks like a repaint or invalidate is missing when handling wm_size messages. To see the issue resize the window such that the top of the editor changes while the width or height also changes. In my sample case where I see the issue I have a top aligned toolbar area that changes height as the width of the main window changes and this will move the editor window up and down during the resize, which shows the issue clearly. I believe this is a new issue.

[pyscripter]

resize the window such that the top of the editor changes

How do you do that? The topline does not change during resize.

[MShark67]

Apologies, I should have worded that better! Just make a form with a client aligned SynEdit full of text and then resize it smaller and then bigger. It should show the issue clearly. Note that wordwrap must be off.

[MShark67]

Looking at procedure TCustomSynEdit.SizeOrFontChanged, it looks like all paths have an invalidate except for the "change size only" path. I think it needs one there, or a catch all one at the bottom. Alternately (or possibly in addition to) UpdateScrollbars maybe needs an "if fPaintLock = 0 then invalidate" instead of the existing "update;" statement.

[pyscripter]

Does moving the call to Invalidate to the end of the SizeOrFontChanged procedure so that it is always called resolve this issue?
I think it makes sense to always Invalidate.

[pyscripter]

Let me also add that I cannot reproduce this with the SynEdit demo.

I am decreasing and increasing the form size with the mouse and it paints OK. And in fact there is no flicker at all while resizing.

[pyscripter]

I know remember. When resizing the Window you do not want to invalidate everything, That causes a lot of flicker while resizing the form. The areas that need to be repainted are automatically invalidated by Windows (or Delphi not sure) and repainted as needed.

As I said I cannot reproduce the issue here. Any thoughts.

[pyscripter]

I am reading the issue description more carefully. You are experiencing the issue if while resizing the toolbar area changes in height say by wrapping the toolbars, which results in the size of Synedit changing and then the painting error occurs.

• When you are not resizing and say you hide your toolbars is the resized SynEdit repainting properly?
• Could you produce a little demo that reproduces the use case you are describing?

[MShark67]

Sorry again. I've found a good and simple way to cause it. With that Simple SDI demo you show above, change the SynEdit from Client Aligned, to bottom aligned. Then drag the top border of the SynEdit halfway down the form (so it takes up the lower half of the area.) Then run it, load a text file and resize the window left to right, top to bottom, etc. You should see crazy painting issues. Sorry about the red herring above, I use the TSbTBXDock and toolbars on most of my apps and they instantly show the issue on resize even if the SynEdit is client aligned (it seems to be related to the top border moving up and down on the form and since the TSbTBXDock does its toolbar autocollapse/resizing thing, it shows the issue instantly.

[pyscripter]

Ok. I can now reproduce the issue.

[pyscripter]

Do you get the error if you set the SynEdit BorderStyle to bsNone?

[MShark67]

It looks like setting BorderStyle to none fixes it! Interesting!

[pyscripter]

These two lines in CreateParams seem to cause the problem:

  if not (csDesigning in ComponentState) and CheckWin32Version(5, 1) then
    ExStyle := ExStyle or WS_EX_COMPOSITED;

Can you test by removing them and using the bsSingle border style?

[pyscripter]

Also could you please provide some feedback on #97 and #98

[MShark67]

Using bsSingle and removing WS_EX_COMPOSTED works to fix the issue. Alternately putting back CS_VREDRAW and CS_HREDRAW and leaving WS_EX_COMPOSTED on also fixed the issue. I'm no expert on flickering issues, so I just mention that as I saw a few stack overflow answers related to it. I don't see any flicker with either method, but it could be that my tests are simple. I'm also testing on Windows 11, so that could have some affect.

[pyscripter]

@MShark67 Thanks for the help.
CS_HREDRAW and CS_VREDRAW is exactly what we should avoid. They invalidate the whole window even for a tiny change in size.
WS_EX_COMPOSITED does double buffering which is known to be slow. Delphi has its own double buffering which one can manually activate. I will remove WS_EX_COMPOSITED since it this does not appear to cause flicker and should lead to faster redraw.

However, please do keep an open eye for similar issues or flicker issues.