News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Wm_size Edit flicker

Started by ragdog, February 04, 2019, 03:00:45 AM

Previous topic - Next topic

ragdog

Hello

I have a problem and have allready google to find a solution.

I use a dialog from resource and add to this dialog WS_CLIPCHILDREN & WS_EX_LAYERED to reduce flicker problem
and to the edit control WS_CLIPCHILDREN too.

but the edit has a flicker problem with wm_size if the edit has a text.


.data?
uDeferFlags dd ?
.code
DlgProc proc hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
LOCAL lpRect:RECT
LOCAL hDwp:HANDLE

.if uMsg==WM_INITDIALOG

.elseif uMsg==WM_SIZE;WM_WINDOWPOSCHANGED
invoke BeginDeferWindowPos,1 ;-- need WS_CLIPCHILDREN & WS_EX_LAYERED style flag in the dialog. for flicker
.if (eax)
mov hDwp,eax
mov uDeferFlags,SWP_NOZORDER or SWP_NOOWNERZORDER or SWP_NOACTIVATE

invoke GetClientRect,hWnd, addr lpRect
invoke GetDlgItem,hWnd,1003
mov edi,eax
mov eax,lpRect.right
sub eax,18
mov ebx,lpRect.bottom
mov edx,39 ;-- top
shl edx,1
sub ebx,edx
invoke DeferWindowPos,hDwp,edi, NULL,9,39, eax, ebx,uDeferFlags
;-- Resize all windows at the same time.
invoke EndDeferWindowPos,hDwp
.endif


Has any a solution?

kind regards,

dedndave

the flicker is likely caused by the WM_PAINT code
for a dialog box, you may not have much control over that

my solution would be to use a regular window, and do away with the dialog box
because you want a sizable window, you have probably gone beyond the intended use of a dialog box

ragdog

Hello Dave

Thank you but there is no other solution?

sinsi

Have you looked at WM_SETREDRAW?

TimoVJL

To freeze control sizeing, example C code case WM_ENTERSIZEMOVE:
SendMessage(hEdit, WM_SETREDRAW, 0, 0);
return TRUE;
case WM_EXITSIZEMOVE: {
SendMessage(hEdit, WM_SETREDRAW, 1, 0);
RedrawWindow(hwndDlg, NULL, NULL, RDW_INVALIDATE | RDW_ERASE);
}
return TRUE;
That effect was used in Windows 3 era ?
May the source be with you

ragdog

Hi

WM_SETREDRAW, 0  disable this control and WM_SETREDRAW, 1 enable after resizing.
This is not a good option, i have only this problem, if the edit box is multiline.

Ok i have a little reduce the problem if the dialog have WS_CLIPCHILDREN.

The problem by redraw the window is the first WM_ERASEBKGND

Quote
Then a WM_ERASEBKGND message is being sent and a reply returned. Then a WM_PAINT message is being sent which in turn sends a WM_ERASEBKGND message which returns a reply and then finally a reply is sent for the WM_PAINT message. So, when we resize the window, the background is erased not once but twice, although I am certain the second erase does not actually repaint the window (getting technical, the update region will be empty, as the first WM_ERASEBKGND will have done the job). The flicker comes from the fact that the first WM_ERASEBKGND will paint the entire window white, erasing all the black text. Then some time later (and who knows what that gap in time is), we receive a paint message to draw the black text. This period of time between erasure and drawing is often more than enough to be seen, We see white background then we see black text.

I think a way is subclass this edit and handle this messages or have any other idea?

Greets,

ragdog

Hello

I have it figured out, but i use a rich edit this works without any flicker.

By a normal regular window  (without dialogboxes) CreateWindowEx and  multiline edit control is this same problem.

If one still has an idea, it is always welcome.

regards,


hutch--

You get flickering from having the same area updated more than once at a time. If you can work out how to do it, turn off the updated screen area under the control and the flickering will stop. You can go the route of double buffering but you then have to work out how to display controls in the client area.

ragdog

Hello hutch

This was a normal multiline edit control in a dialog box with wm_size and this edit have a long text.
the problem is my quote text.

QuoteThen a WM_ERASEBKGND message is being sent and a reply returned. Then a WM_PAINT message is being sent which in turn sends a WM_ERASEBKGND message which returns a reply and then finally a reply is sent for the WM_PAINT message. So, when we resize the window, the background is erased not once but twice, although I am certain the second erase does not actually repaint the window (getting technical, the update region will be empty, as the first WM_ERASEBKGND will have done the job). The flicker comes from the fact that the first WM_ERASEBKGND will paint the entire window white, erasing all the black text. Then some time later (and who knows what that gap in time is), we receive a paint message to draw the black text. This period of time between erasure and drawing is often more than enough to be seen, We see white background then we see black text.

I have try WM_SETREDRAW ..... but is not nice

@LiaoMi

Thank you for your time

I have some experience with double buffering, but i use a standart control not costum and paint all self.