WM_PAINT Selectivity

[allynm]

Hi everyone-

I have a beginner question on WM_PAINT.  It is a sort of general question.  I could send code if this would help clarify the matter, but let me try first just raising the question in a sort of "canonical" fashioin.

Let us suppose I have a desire to paint repeatedly, but paint different stuff (various TextOuts, bitmaps, what-have-you).  The program calculates various items and paints differently depending upon what gets computed.

My novice solution to this is to use something like the following code:

  .if uMsg == WM_PAINT && BOOLVAR1 == TRUE
      INVOKE BeginPaint, etc.

.ELSEIF
     uMsg == WM_PAINT && BOOLVAR2 == TRUE
       INVOKE BeginPaint, etc.

My question for you folks is whether this is the appropriate way to handle the problem or just the crummy, clumsy invention of a novice.  I'd like to code using best practices.

Thanks much,
Mark Allyn

[jj2007]

Mark,
Assembly is flexible, choose what suits you. Keep it simple and clear. For example, you might choose

Code Select Expand

.if uMsg == WM_PAINT
      invoke MyPaintProc, BoolVar
.elseif uMsg == ...

....

MyPaintProc MyChoice
      INVOKE BeginPaint, ...
      Switch MyChoice
      Case 1
      call PaintARect
      Case 2
      call PaintACircle
      Endsw
      INVOKE EndPaint, ...
      ret
MyPaintProc endp

[allynm]

Hello JJ-

Your code is very elegant.  I will adopt this general form. 

Thank you,
Mark

[Slugsnack]

oh btw :

.IF eax != 0 is equal to .IF eax

similarly, .IF eax == 0 is same as .IF !eax

[jj2007]

.IF eax != 0 is equal to .IF eax

Yes, in general simpler code is also easier to read and maintain. Indentation is important:

Code Select Expand

MyPaintProc MyChoice
      invoke BeginPaint, ...
      Switch MyChoice
      Case 1
         call PaintARect
      Case 2
         call PaintACircle
      Endsw
      invoke EndPaint, ...
      ret
MyPaintProc endp

What I see often and find horrible is this:

Code Select Expand

sub                                 esp,1Ch
push                                esi
mov                                 esi,0FFFFFFFFh
Compare to

Code Select Expand

sub esp, 1Ch
push esi
mov esi, 0FFFFFFFFh
Much friendlier to the human eye :8)
In the upper case, the eye reads sub push mov then esp,1Ch esi esi,0FFFFFFFFh (the latter being -1 btw, but the author probably wanted to demonstrate that brains of Real Men^TM work in HEX).

I also try to avoid UPPERCASE, IT JUST MEANS SHOUTING, AND WE KNOW ANYWAY WHAT INVOKE IS, RIGHT?

And, of course, colour...

   sub esp, 28   ; 7*4 is easier to read than 1Ch
   push esi      ; push and pop marked red
   mov esi, -1
   mov byte ptr [esi], 0
   if MyDebug   ; conditional assembly marked blue
      movaps xmm0, xmmword ptr [ecx]
      movaps xmm1, xmm0
   else
      movaps xmm0, xmmword ptr [ecx]
      movaps xmm1, xmm0
   endif
   mulps xmm1, xmm0
   movaps xmmword ptr [esp+10h], xmm1   ; how much time to you need to decipher 10h as 16=4*4?
   fld dword ptr [esp+16]
   fadd dword ptr [esp+24]
   pop esi
   fadd dword ptr [esp+16]
   fstp dword ptr [esp+12]

All that is very subjective, and if everybody applied a strongly idiosyncratic style, communication might even be worse. Nonetheless, a bit of good taste and some rules would not hurt :bg

[Ghandi]

.if eax != 0 is equal to .if eax

similarly, .if eax == 0 is same as .if !eax

Yes and no, without being too pedantic. They will have the same effect on the flow of code testing for a zero condition.

For instance:

Code Select Expand

.if eax

Results in:

Code Select Expand


test eax,eax
jz @foo

;code to execute if zero flag isn't set

@foo:

Which can be encoded: 85 C0 75 XX


Whereas:

Code Select Expand

.if eax != 0

Results in:

Code Select Expand


cmp eax,0
jz @foo

;code to execute if eax isn't 0

@foo:

Which can be encoded: 83 F8 00 75 XX

Of course, this is being too general, because there can be different ways to encode the same instructions and a long jump will be encoded differently than a short jump, etc. Once again, im not trying to be anal about this. :)

HR,
Ghandi