passing parameters within the same Frame

[shankle]

8-21-2012

WndProc:
        FRAME hWnd,uMsg,wParam,lParam
other code

;                                             Vert1  Vert2  Horz3  Horz5         
       invoke LineMove, [hdcPrn],150,   2000,  598,    598 
other code

LineMove:
        invoke MoveToEx, [hdcPrn],[Vert1],[Horz3],NULL   
        invoke LineTo,[hdcPrn],[Vert2],[Horz5] 
        retn
other code
       
    ENDF             ; end of WndProc
   
for a 32-bit program
Reason for LineMove: is that it is repeated a lot.
I would think the parameters in "MoveToEx and LineTo
would get mixed up
hdcPrn,Vert1,Horz3,Vert2 and Horz5 have all been
defined as double words
Yes, I read the help file about passing parameters
when in the same Frame and am still confused.
 
 
   

[jj2007]

Shouldn't be a problem. What do you see in Olly?
I am a bit surprised that invoke works for a simple label. Does it crash? If yes, try a retn 5*4.

[shankle]

Thank you JJ for responding.
Bought GoBug. Haven't used it to solve this problem.
The program doesn't crash for that reason but other
reasons.
If I am correct GoAsm only has RET and RETN.
That's all I can find in the docs.

[Ryan]

Where are your dwords defined?  Passing parameters with invoke pushes new values onto the stack.  If you don't revert the stack pointer to the correct position, the ret will fail.  Is there a reason you aren't using a separate proc?  Call pushes a return address onto the stack to tell it where to jump back.

[shankle]

Thank you for responding Ryan.
Dbl words are defined in the data section.
I tried that with the Frame statement and seemed to have trouble with it.

[dedndave]

return will work, but things are left on the stack   :P
some compilers use that as a "feature"

[wjr]

You do not need to define those in the data section for both of the following fixes. A seperate procedure may be easier to understand:

Code: [Select]

LineMove:
FRAME hdcPrn, Vert1, Vert2, Horz3, Horz5
invoke MoveToEx,[hdcPrn],[Vert1],[Horz3],NULL   
invoke LineTo,[hdcPrn],[Vert2],[Horz5]
ret
ENDF

However, since I take it that your hdcPrn is LOCAL, I think the following is what you were trying to do:

Code: [Select]


        invoke LineMove, 150, 2000, 598, 598 
;other code
ret
LineMove:
        invoke MoveToEx, [hdcPrn],[esp+0Ch],[esp+10h],NULL   
        invoke LineTo,   [hdcPrn],[esp+0Ch],[esp+10h] 
        retn 16

Note that your invoke LineMove in this case does not require hdcPrn passed as an argument.

[shankle]

Thank you WJR for responding.
I think your 2nd suggestion is what I need to do.
Since the invoke is local I assume hdcPrn is local.
However each of the values in "invoke linemove" can
be different, I think the following is needed:
esp+04h  598 (horz5)
esp+08h  598 (horz3)
esp+och  2000 (vert2
esp+10h 150 (vert1)
                          vert1  vert2  horz3  horz5
Invoke linemove, 150,   2000,  598,   598 corresponds to these values. 
so....
invoke MoveToEx, [esp+10h],[esp+08h],NULL   
invoke LineTo, [esp+0ch],[esp+04h] 

[wjr]

I corrected the above with retn 16 for one less parameter. My esp offsets are correct though. INVOKE pushes the arguments from right to left, so it is the other way around to start:
esp+04h  150 (vert1)
esp+08h  2000 (vert2)
esp+0Ch  598 (horz3)
esp+10h 598 (horz5)

However, when you get to invoke MoveToEx and LineTo, keep in mind that pushing those arguments changes esp, so you need to compensate on the offsets. A good exercise to follow through on GoBug (using different invoke values like 1,2,3,4).