how to pass a variable as a negative value in a winAPI call

[Rainstorm]

hi , how do i pass variables as negative values in windows API call ?

I tried putting a minus sign.. but the assembler doesn't seem to accept that. - like

Code Select Expand

               invoke OffsetRect, addr dlg_rect, -dlg_rect.left, -dlg_rect.top
I don't know how windows treats the variables either, cause i tried the neg instruction with the variable & then passed it in the call but it gave weird results.

t y

[Tedd]

NEG the values before you push them (or modify them in the dlg_rect struct then use the values, as you are.)

OffsetRect takes two int values for the offset, so they will be treated as 2's-complement dword values - what are the weird results you get?

[Rainstorm]

tedd, i was manipulating a rectangle & i said that about the weird results from what i saw on the screen, but probably it was my code too. -  i was basically trying to convert the screen co ordinates into dialog co ordinates as the GetWindowRect call returns values in screen coordinates. that is to get the left-top point to be 0,0.
GetWindowRect, would return the proper size of the dialogbox  - am able to do it without GetWindowRect, by just manually creating a rectangle the size of the dialogbox  & passing it to the ellipse creation function, but if i could figure out how to do it without GetWindowRect I think that would be a better way.

Code Select Expand

  invoke GetWindowRect, lParam, addr dlg_rect
  neg dlg_rect.left
  neg dlg_rect.left
  invoke OffsetRect, addr dlg_rect, dlg_rect.left, dlg_rect.top
  invoke CreateEllipticRgnIndirect, addr dlg_rect

i just tested & the values correct (175,175 before the Neg & -175,-175 after the Neg)
after the OffsetRect function they were -350,-350 . just doing what you said i realise now one mistake was doing the Neg on the  dlg_rect.left values itself, instead of doing it in a register & passing it to the OffsetRect Function.
i tested with this line before the neg, after the Neg & after the offsetRect call (with the pushad/pushfd)

Code Select Expand

    fn MessageBox, 0, sstr$(dlg_rect.left), "Left", MB_OK

I just don't want the units to get messed up when creating the ellipse..& while using GetWindowRect - all the diff units get confusing.

many thanks ! !

[Rainstorm]

I think i could just leave it in screen coordinates in this particular instance
just one question what's the client areal of a dialog ? - the whole dialog or the area of the dialog minus the caption ?

for what i was trying to do earlier maybe this code would be more in line ? (or i could just use the ScreenToClient function)

Code Select Expand

               mov edx, dlg_rect.right
               sub edx, dlg_rect.left           ; width/right coordinate
               mov dlg_rect.right, edx
               mov dlg_rect.right, 0            ; left
               
               mov ecx, dlg_rect.bottom         
               sub ecx, dlg_rect.top            ; height/bottom coordinate
               mov dlg_rect.bottom, ecx             
               mov dlg_rect.top, 0              ; top

thanks.

[kromag]

The client area, iirc, would be the latter of what you stated; The area inside blow the title and bounded by the frame.

Anything within that area. Accessing the other areas is usually referred to as Sub-Classing.
Hope that was helpful  :wink
---
William

[Rainstorm]

Thanks !

[Tedd]

ScreenToClient would be suitable, but you also need to convert into dialog units, which depend on the font size (use GetDialogBaseUnits.)
See also: MapDialogRect :wink

[Rainstorm]

yes, i thought i wouldn't have to do that.. but its being processed in the  WM_CTLCOLORDLG msg & that's sent before the dialog is drawn. -  (so GetWindowRect which gets the coordinates in pixels won't be any use ?)

[MichaelW]

In the attachment here, support.asm contains several procedures that convert from pixels to DTUs, and a procedure that sizes a window (or dialog window) so the client area will have the specified width and height in pixels. The file xmacros.asm includes two macro functions to do the conversion. Note the requirement that the dialog use the system font.

[Rainstorm]

Just downloaded the pack & was having a look at it,.. good stuff Michael  :U . - I had not come accross this post of yours before..
the conversion & applying the new size should usually be done after the dialog is created but before its displayed, is that right ?
the dialog box am using is modeless & doesn't have a parent, so when its displayed its coordinates are in screen co-ordinates. - the code am using sort of works, but this would be much more reliable.

thankyou.

[MichaelW]

the conversion & applying the new size should usually be done after the dialog is created but before its displayed, is that right ?

Yes, I do it when I process WM_INITDIALOG.