how to correct this

[RHL]

Hello people
I'm write instruction on the WM_paint event ,I use RadAsm with the DialogApp template and I can accomplish what I need, but
but the CPU is accelerates much, reaches 50%! :|

for example this simple instructions:

Code Select Expand

.elseif eax==WM_PAINT
push eax
mov eax,05
pop eax

accelerates the cpu to 50%, means it runs and runs...
how to can fix that?

I have thought maybe the structure of the program, maybe I should use other template...
thanks people  :bg

I can post the DialogAp template if they want : P

[jj2007]

No need to post anything. What does the documentation say about handling the WM_PAINT message?

[dedndave]

WM_PAINT is no simple thing

http://msdn.microsoft.com/en-us/library/dd162759%28v=vs.85%29.aspx

if you go through all the sub-sections, there is a LOT of reading   :P
the code in masm32\examples and posted on the forum can help
once you have that memorized, you will want to learn about compatible DC's, Dib Sections, and BitBlt

anyways, you should return 0 when done

you aren't thinking...

Code Select Expand

    .elseif eax==WM_PAINT
        push eax
        mov eax,05
        pop eax
:red

[RHL]

no no, that code is only like example lol
ok ok thanks guys I will read the example and read the link

[dedndave]

 :bg

well - if the CPU is at 50%, it usually means you are doing something wrong - especially in GUI apps
in console apps, it happens quite often
in 16-bit console apps, it is sometimes unavoidable   ::)

attach your code, and we will criticize it immensely :bdg

[RHL]

but should run only when needed repainting?.
on the other hand is always executed :|


and no dedndave, I have not only was testing  :red lol

[qWord]

handle WM_PAINT correct or let DefWindowProc do the job.

a common configuration is:

Code Select Expand


.[else]if uMsg == WM_PAINT
    invoke BeginPaint,ADDR ps
    ; draw according to window/control's current status
    invoke EndPaint,ADDR ps
    xor eax,eax
    ret
.else[if] ...

[jj2007]

for example this simple instructions:

Code Select Expand

.elseif eax==WM_PAINT
push eax
mov eax,05
pop eax

accelerates the cpu to 50%, means it runs and runs...

The folder \masm32\examples has 46 *.asm files that contain the term BeginPaint. And you come along and say "ok, let's put something completely senseless into the WM_PAINT handler, and see how Windows reacts". Here is a valuable hint:

Code Select Expand

.elseif eax==WM_PAINT
push eax
mov eax, 05
mov eax, [eax]
pop eax
is equally senseless but at least it gives Windows an occasion to introduce you to your debugger.

[dedndave]

Campus, Jochen
no pickin on the new guys   :P

[NoCforMe]

Let me add my 2 cents worth without jumping on the new person (remember, we were all newbies once!).

Others should have asked this question: what else are you doing in your WM_PAINT handler?

Are you using BeginPaint() -- EndPaint()?

How are you exiting the window proc after responding to WM_PAINT? What are you setting EAX (the return value) to?

Normally, if your window proc actually handles WM_PAINT, you exit with EAX set to zero:

Code Select Expand


XOR EAX, EAX
RET

Give us a few more clues and someone here can probably help you with this perplexing problem.

[jj2007]

Yeah, sorry, maybe I have been a bit too harsh. If RHL posts his complete code, we'll try to help him, promised.

[RHL]

hey qWord thanks , ur code solved my problem, returning EAX to zero functioning normally
thanks all

why this happens? : P

[qWord]

why this happens?

The system charged your handler to draw and validate a given region, but this isn't done. This cause your threads message queue to resend WM_PAINT again and again ...

[NoCforMe]

Yes. Or to put it another way, when you receive a WM_PAINT message, you have basically two choices: either handle it, or let someone/something else handle it.

The difference (from the Windows GDI point of view) is what you return in the handler (that is, what EAX is  set to when you RETurn).

If you set it to zero, that tells the GDI "OK, I did what I want to do--the WM_PAINT message is dealt with, don't send it again!".

Otherwise, the GDI assumes it hasn't been handled, which means it will continue sending it again, and again, and again ... which is why you saw your CPU usage shooting up.

If you choose not to handle WM_PAINT, then you should send the message on down the chain by calling DefWindowProc(), as you should do with any message that your window procedure intercepts but doesn't handle.

The moral of story: Know what you are supposed to do with any WM_xxxx message, and what you're supposed to return when you handle it (and when you don't). This is an important point, and it's also about half of the battle when learning how to deal with Windows messages.

Note: As qWord implied, this all has to do with window (or region) validation. The way to get something drawn in a Windows program is (usually) through calling InvalidateRect() or InvalidateRegion(), which marks the rectangle, region or the entire window as being "invalid". (This also happens if the user minimizes the window and then restores it, or moves another window in front of it.)  Now, Windows will do everything it can to get that rectangle/region/window "validated". Normally, this is done through the calls to BeginPaint() -- EndPaint(). At the end of that sequence, the area that was marked as invalid (through InvalidateXXXX() ) will now be marked as valid.

In order for this to happen, and for Windows to stop bugging you about an invalidated area, it's essential for you to handle the WM_PAINT message and return zero after doing so.

Does this make more sense now?

[MichaelW]

If you choose not to handle WM_PAINT, then you should send the message on down the chain by calling DefWindowProc(), as you should do with any message that your window procedure intercepts but doesn't handle.

One small point, a dialog box procedure is a window procedure, but it must not call either DefWindowProc or DefDlgProc. The system dialog box class automatically provides default processing for any message that the dialog box procedure returns as FALSE.