Author Topic: WINDOWPOS  (Read 465 times)

jimg

  • Member
  • ***
  • Posts: 291
WINDOWPOS
« on: November 15, 2018, 04:26:46 AM »
Hutch-

Just of of curiosity, why did you use cy insted of ly in windows.inc for definition-

Code: [Select]
WINDOWPOS STRUCT
  hwnd              DWORD      ?
  hWndInsertAfter   DWORD      ?
  x                 DWORD      ?
  y                 DWORD      ?
  lx                DWORD      ?
  cy                DWORD      ?
  flags             DWORD      ?
WINDOWPOS ENDS

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5945
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: WINDOWPOS
« Reply #1 on: November 15, 2018, 09:38:32 AM »
 :biggrin:

Do you expect me to remember 1997 ? Usually back then it had to do with naming conflicts.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

sinsi

  • Member
  • *****
  • Posts: 1091
Re: WINDOWPOS
« Reply #2 on: November 15, 2018, 10:19:07 AM »
Ask the question another way and it answers itself

Just of of curiosity, why did you use lx insted of cx in windows.inc for definition-
I can walk on water but stagger on beer bourbon.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5945
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: WINDOWPOS
« Reply #3 on: November 15, 2018, 02:25:09 PM »
Urrrrgh, "cx" is a register.  :biggrin:
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin:

jj2007

  • Member
  • *****
  • Posts: 8896
  • Assembler is fun ;-)
    • MasmBasic
Re: WINDOWPOS
« Reply #4 on: November 15, 2018, 03:00:35 PM »
Yep. There are similar cases, and in general the choice was to prepend or append a "_", like this:
Code: [Select]
_cx equ <lx>

IMAGELISTDRADWORDS STRUCT
  cbSize            DWORD  ?
  himl              DWORD  ?
  i                 DWORD  ?
  hdcDst            DWORD  ?
  x                 DWORD  ?
  y                 DWORD  ?
  _cx               DWORD  ?
  cy                DWORD  ?
  xBitmap           DWORD  ?
  yBitmap           DWORD  ?
  rgbBk             DWORD  ?
  rgbFg             DWORD  ?
  fStyle            DWORD  ?
  dwRop             DWORD  ?
IMAGELISTDRADWORDS ENDS

And there are worse cases like this:
Code: [Select]
IMediaControl STRUCT
QueryInterface dd ?
AddRef dd ?
Release dd ?
GetTypeInfoCount dd ?
GetTypeInfo dd ?
GetIDsOfNames dd ?
Invoke_ dd ?
Run dd ?
Pause_ dd ?
Stop dd ?
GetState dd ?
RenderFile dd ?
AddSourceFilter dd ?
get_FilterCollection dd ?
get_RegFilterCollection dd ?
StopWhenReady dd ?
IMediaControl  ENDS

You can't avoid naming conflicts, compromises are needed, and "correcting" old errors would break existing code. It would have been great, of course, if over 20 years ago Hutch had been wise enough to establish a crystal clear Avoid Naming Conflicts Convention (ANCC). But he was a young man then, maybe we should pardon him ;)

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 5945
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: WINDOWPOS
« Reply #5 on: November 15, 2018, 04:54:18 PM »
You are right about the need for wisdom in hindsight, back when that file was first being written in 1997 the information was hard to get and all over the place like a mad woman's sewerage. If I could only share the joys of wading through megabytes of garbage to find enough constants to make an include file work noting that even slight errors brought it down around you like a ton of bricks.

I have always had a response to any who want to be critics in hindsight, feel free to write your own. We won't hear from you for a very long time.  :P
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :biggrin: