Moving the dialog

[Natter]

Hi,

If, when moving the dialog with the mouse, part of this dialog turned out to be a screen,
then returning the dialog to the screen will be associated with significant delays (depending on the number of controls on the dialog).
I understand that this is due to the constant call of the Refresh() method.
How do I make the Refresh() method work only when the left mouse button is not pressed ?

[Antonio Linares]

How many controls do you use in the dialog ?

[Natter]

For example, there is a main window (full screen). I open a TDialog (about 90% of the area of the main window).
xBrowse is located on this TDialog (about 90% of the TDialog area).

[Antonio Linares]

that should not slow down the painting...

Is the xbrowse very complex ? I mean the data you show, calculations, etc

[Natter]

No, xBrowser is simple - array, 10000 rows, 20 columns (if the xBrowser is small, everything is fine)

[Antonio Linares]

> if the xBrowser is small, everything is fine

what do you mean with "small" ?

[Natter]

1. How can I find out that part of the window is shifted behind the screen ?
2. How can I find out that the window update is caused by moving it to the screen ?

[Antonio Linares]

Dear Yuri,

when a window, dialog or control is painted, FWH evals oWnd:bPainted if defined from METHOD Paint() CLASS TWindow

Code: Select all  Expand view

     if ValType( ::bPainted ) == "B"
         uVal = Eval( ::bPainted, ::hDC, ::cPS, Self )
      endif

::cPS is initialized from METHOD _BeginPaint() and contains a PAINTSTRUCT:
https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-paintstruct

in such structure you have the area which is going to be updated

[Natter]

Thank you, Antonio! I'll try to figure it out. It was the code block :bPainted that caused delays when
pulling the window out from behind the screen. I needed an understanding of when to execute this block of code and when not to