Window painting

That would be very difficult.  The only way I can think of would be to subclass the window, catch these messages (maybe more):

WM_DISPLAYCHANGE
WM_ERASEBKGND
WM_ICONERASEBKGND
WM_NCPAINT
WM_PAINT
WM_PAINTICON
WM_PRINT
WM_PRINTCLIENT
WM_SETREDRAW

pass control back to the old handlers & assume that the time inbetween the window is painting.

Perhaps there is another method, depending on what, exactly, it is you need to do.  Perhaps you could explain a little more?

GL
Mike

Well, if I got you right, todsawat, then you want to get notified whenever a window in the whole starts and stops painting, right? Sorry to give you a negative answer but this is alsmost impossible with Delphi. You could hook each and every window using a global hook and you would get notified about a paint action, but this would not give you a hint when painting is finished. Additionally it could become extremely difficult to create and maintain the system wide hook and to manage the various paint events, depending on what you want with the notifications.

At least for Win9x there is another option. You can create a GDI hook which records all painting actions. But this hook must be in a 16bit dll. So you see it's going very difficult.

Ciao, mike

So this makes it impossible to create a new "window-manager-decoration-theme" for windows, right? That sucks.



/m

It haven't command to wait WM_PAINT event or check TIME_OUT of WM_PAINT Message ?? Ex. Mutex, Semophore......... (I don't understand) :-D

I'm sorry to say it but your English is very confusing, I don't think you can get any real help before you have learnt some more English words and grammar. No offens.


/m

I'm so sorry about my confusing in english. For the last question, I want to ask what's the command to tell me when WM_PAINT is finished. I don't sure my idea is work, It's sending message WM_PAINT  to windows again and wait for respond. If windows don't process my WM_PAINT message in time, I 'll sure that windows is processing WM_PAINT message which isn't mine. For example command , mutex or Semophore or WaitForSingleObject... I'm not sure.

Thanks a lot for your answer. I really hope that it isn't confuse like the old one.

I think I understood you most of the time :-) For the paint: when you send a WM_PAINT message using SendMessage the call is blocked until the target window has processed the message. This way you know exactly when the paint cycle you initiated is over. But of courses it is no indication about further paint cycles cause be other applications or internally.

Ciao, Mike

Lischke : Thanks a lot for your answer. But I think I also have a little confuse. Would you mind sending some source about it ?

Regards, Todsawat..

Lischke : Thanks a lot for your answer. But I think I also have a little confuse. Would you mind sending some source about it ?

Regards, Todsawat..

No problem. What would you like to see?

Please show me the sample source code about your method. And please explain to me again.

Regards, Todsawat.
                       

Please show me the sample source code about your method. And please explain to me again.

Regards, Todsawat.
                       

todsawat, please don't use the refresh button of your browser to refresh the page as this will resend all formular data. There is a link titled "Reload Question" at the top. Use this for refreshing.

Ciao, Mike

Lischke, Please show me the sample source code about your method. And please explain to me again.

Regards, Todsawat.

Hi, repainting the window is done by the main thread in response to the WM_PAINT message. In the case of a form Delphi will fire the OnPaint event. However, the form may be completely covered with contained windows (the ones from MS Windows, most likely TWinCOntrol descendands;). In the case no repainting has to be done on the form itself because repainting will be done be the contained windows. Control over repainting these windows depends on published events and subtyping. However, if you just want to ensure the windows are not updating while you do something special you have to keep in mind that message processing is done by the main thread. So if youre in the main thread and the painting methods never call the code section youre thinking of youre safe. If thats not the problem feel free to ask back,

May I friendly lead your attention to an important issue? Here in Experts-Exchange it is common practice to lock questions
with an answer only if you are the first expert in the thread, or if all other comments are evidently wrong. Otherwise it is
usual to post a *comment* only. This way the questioner can later easily choose which expert helped most. Additionally,
using comments only is more polite because:
 
- the question can easily be deleted if necessary
- it cannot happen that an answer is accidentally accepted
- you show that you acknowledge the work already done
- you give other experts a chance to post a better answer
 
Please, be so kind and use the option "withdraw answer" to convert your answer to a normal comment.
 
Thank you for listening...   (-:

I want to ask what's the command to tell me when WM_PAINT is finished. I don't sure my idea is work, It's sending message WM_PAINT  to windows again and wait for respond. If windows don't process my WM_PAINT message in time, I 'll sure that windows is processing WM_PAINT message which isn't mine. For example command , mutex or Semophore or WaitForSingleObject... I'm not sure.

I want to ask what's the command to tell me when WM_PAINT is finished. I don't sure my idea is work, It's sending message WM_PAINT  to windows again and wait for respond. If windows don't process my WM_PAINT message in time, I 'll sure that windows is processing WM_PAINT message which isn't mine. For example command , mutex or Semophore or WaitForSingleObject... I'm not sure.

If you want to know when WM_PAINT processing has finished you can just override it:

type
  TMyForm = class(TForm)
  protected
    procedure WMPaint(var Msg:TWMPaint); message WM_PAINT;

[...]

procedure TMyForm.WMPaint(var Msg:TWMPaint);
begin
 inherited;
 // Place your code here
end;

timschat, please read the entire discussion and particularly the question. We do not talk about windows in our own application (for which a solution is trivial).

todsawat, I think you don't have understood yet how the painting works. When you send the WM_PAINT message (as shown in my example) then you *don't* need a notification about whether it is finished because whenever SendMessage returns the target window has finished its painting. There is however a special version (SendMessageTimout) which waits a specific amount of time and returns a state whether the message was correctly processed or not. E.g.:

  if not SendMessageTimeout(Target, WM_PAINT, 0, 0, SMTO_BLOCK, 500) then
  // message has not been processed

But you cannot generally assume that an unprocessed paint message means the target window is currently processing another paint message. Where did you get this funny idea from? It is rather so that your paint message is placed into the message queue of your target window, regardless whether it is currently painting or not, and when it has time it will process your paint message.

Ciao, Mike

Hi Lischke, if you would read more carefully you could notice that todsawat asked it:
"I want to ask what's the command to tell me when WM_PAINT is finished"
Using a timeout is no correct behaviour.
Message processing must always take place within the same thread to avoid side effects. Usually this is the applications main thread. This thread will either process the WM_PAINT messages or no one does. So placing the notification in the WM_PAINT handling is both logical and correct. Your conclusions from my writings are incorrect anyway.

> ...if you would read more carefully
:-) *you* tell *me* to read more carefully, funny, I made most of this thread here :-D

> "I want to ask what's the command to tell me when WM_PAINT is finished"
I'm trying a while already to show that there is no command or something like that. WM_PAINT is a message which can be sent and processed. That's it.

>Using a timeout is no correct behaviour.
Have basically understood what I'm talking about?

> Message processing must always take place within the same thread to avoid side effects. Usually this is the applications main thread. This thread will either process the WM_PAINT messages or no one does.
This depends on the creator of the window which gets the WM_PAINT message. There can well be something else than the main thread which paints a window. But...., we don't talk about this as it belongs to your own application. We talk about other applications like the ddesktop, explorer, IE etc.

>Your conclusions from my writings are incorrect anyway.
Oops, did I get you so wrong? I doubt it, but if you did not meant your own application what else?

Again, we do not talk about processing of or reacting to a WM_PAINT message but to send it a know when it is done.

Ciao, Mike

Lischke, You're Right. But iwhat's the command to check timeout of RedrawWindow (Function) ?? :-D

Mmh, never heard about such a timeout. You should keep in mind that we are talking about time slices in milliseconds (usually). Today a program is no longer accepted if it takes a couple of seconds to update its display. Even all those 3D/fractal progs do maintain backbuffers to speed up display.

With RedrawWindow it is the same as sending WM_PAINT. Once it is returned you can be assured painting has been done. This is all guarantee you will get from Windows.

Ciao, Mike

Hmm, isn't the difference between PostMessage() and SendMessage() that one of them is async without return value, and the other one is sync with return value? Then would we not be able to use the sync one to post WM_PAINT and then our program would not continue (resume after the proc) until the painting where actually done?

Just a thought.



/m

This is true, requiem. By suggesting SendMessageTimeout(Target, WM_PAINT, 0, 0, SMTO_BLOCK, 500) or SendMessage(Target, WM_PAINT, 0, 0) I wanted to show exactly this fact.

Ciao, Mike

Oh, I didn't read all the jabber above, sorry. But would not SendMessage() be perfectly enough then? Or, where is the problem, todsawat?


/m