error msg?

[shankle]

Hi Guys,
To wjr,
mov D[wc.style], CS_BYTEALIGNWINDOW gives a compile error.
That is why I changed it to D[wd.style], addr stylied.
IDI_APPLICATION is also in WNDCLASSEX and making a zero string made
the compile error go away. FF_ROMAN is used in "CREATEFONT" and a
a zero based string made that error go away. Whether this is correct or
not I do not know but it eliminated the compile errors.
There is no resource file used in the program.
In reference to: doci DOCINFO <sizeof(Docinfo), Appname, NULL, NULL,0>
gave this error:  unexpected material <sizeof Docinfo), Appname, NULL, NULL, 0>
This also didn't work if I changed DOCINFO to DOCINFOA. 

To Dave,
I think I have my headers defined correctly of which one is winuser.h but as stated
above it gives compile errors in WNDCLASSEX. Both CS_BYTESALIGNWINDOW and
IDI_APPLICATION are defined in winuser.h. Question is why isn't it being picked up?

[dedndave]

typically, i use IDI_APPLICATION like this

Code: [Select]

        INVOKE  LoadCursor,NULL,IDI_APPLICATION
        mov     hIcon,eax                               ;optional
        mov     wc.hIcon,eax
        mov     wc.hIconSm,eax
that's MASM syntax, of course   :P

it seems to me that LINKFILES should be defined, then windows.h should be included first

Code: [Select]

  #define  LINKFILES
  #include windows.h
  #include winuser.h

[shankle]

Hi Dave,
I ASSUMED that LINKFILES brought in all the header files.
I compiled with: #INCLUDE windows.h and #INCLUDE winuser.h.
That gave an error. So I took out #INCLUDE winuser.h and that gave
a clean compile.
If I insert IDI_APPLICATION and CS_BYTEALIGNWINDOW in WNDCLASSEX
the linker rejects it. Had to put back "applid" and "styleid" to get it to work.
Don't understand why this is not picked up from "windows.h"

I know this goes against what you suggested prior but that suggestion gave
errors. To get around the errors my directory/folder setup is as follows:
  g:\codejps  - this contains GoAsm, GoLink, and all the header files.
So since GoAsm and the header files are all in the same folder it should be
able to access them. But I've been wrong before :(
 

[wjr]

If the symbol LINKFILES is defined before including windows.h, the header files then use #dynamiclinkfile to place the names of system DLLs to import from into a "directive" section of the OBJ file for use by GoLink so that you do not need to specify these on the GoLink command line.

Including windows.h should be sufficient as it should include winuser.h and wingdi.h. However, the above DOCINFO unexpected material error (and FF_ROMAN) would seem to indicate that wingdi.h also is not getting included.

Yes, all in the same folder should work. If you do not get any "Could not open file:- #include FileName.h" errors, then perhaps a long shot, but make sure that you have not defined NOUSER and NOGDI before including windows.h.  Also, although those other changes are incorrect, if there are no compile errors, what do you get, if any, as GoLink errors?

[shankle]

Thank you for replying WJR.
This is how LINKFILES is defined in MyProg:
  #define LINKFILES
  #include windows.h
  #define codejps

DOCINFO and FF_ROMAN seem to be behaving themselves now.
I do not have "NOUSER OR NOGDI" in the program.
I have changed CS_BYTEALIGNWINDOW and IDI_APPLICATION back
to the way they should be.

I can get a clean compile.
The linker blesses me with this error:
  The following symbols were not defined in the object file or files:-
  CS_BYTEALIGNWINDOW        IDI_APPLICATION

[dedndave]

This is how LINKFILES is defined in MyProg:
  #define LINKFILES
  #define windows.h

shouldn't that be
  #define  LINKFILES
  #include windows.h

[shankle]

Hi Dave,
Looks like I can't get away with anything
Yes, will fix it.
Thanks

[wjr]

If WinUser.h was somehow not being included, then you would have other errors (for example with WNDCLASSEX, RegisterClassEx, and WM_CREATE). So if it is just those two, check to see if they actually get defined in your WinUser.h file.

[shankle]

Thank you WJR for responding.
In winuser.h I found:
    #define IDI_APPLICATION 32512 and  #define CS_BYTEALIGNWINDOW  0x2000
These switches are in winuser.h. Is it possible that winuser.h is not fully compatible
with Windows 7 Pro 32-bit?

My Wndclassex code:
   mov   D[wc.cbSize], SIZEOF WNDCLASSEX
   mov   D[wc.style], addr CS_BYTEALIGNWINDOW
   mov   D[wc.lpfnWndProc], OFFSET WndProc
   mov   D[wc.cbClsExtra], NULL
   mov   D[wc.cbWndExtra], NULL
   push  [hInst]
   pop   [wc.hInstance]
   invoke LoadIconA, NULL,addr IDI_APPLICATION
   mov   D[wc.hIcon], eax
    invoke LoadCursorA, NULL,[IDC_ARROW]
   mov   D[wc.hCursor], eax
   invoke CreateSolidBrush, [colorbk]          ; background color
    mov   D[hBrush], eax
   mov   D[wc.hbrBackground], eax
   mov   D[wc.lpszMenuName], NULL
   mov   D[wc.lpszClassName], OFFSET szDisplayName
   mov   D[wc.hIconSm], 0

LoadIcon     IDI_APPLICATION is defined in winuser.h but gives an error
Loadcursor  IDI_ARROW is NOT defined in winuser.h but gives NO error :(
mov   D[wc.style], addr CS_BYTEALIGNWINDOW is defined in winuser.h but gives an error.

Switches used in winuser.h
WINNT4 = Used only with Windows NT version 4 (note: may not be compatible with other versions)
WIN9X = Used only with Windows 95/98/ME (note: may not be compatible with other versions)
WINCE = Used only with Windows CE (note: may not be compatible with other versions)
WIN64 = For use only with a 64 bit Windows
UNICODE = Use UNICODE versions

All the structs have been found but one.
In winuser.h the RECT struct is defined as follows:
     #IFNDEF  RECT STRUCT  left dd ?  top dd  ?  right dd ?   bottom dd ? ENDS  rc RECT
I had to code this in MY Progie to get rid of errors.
 

[wjr]

The header files have been around for a while on the 32-bit side, so I would say no compatibility issues. Ahhh, that would do it... you do seem to have the header files working now, so if you have difficulties that you can not resolve on your own, posting a bit source code will make things Go much quicker. Corrected lines follow:

mov   D[wc.style], CS_BYTEALIGNWINDOW
invoke LoadIcon, NULL, IDI_APPLICATION
invoke LoadCursor, NULL, IDC_ARROW

Also, the header files take care of the ANSI / UNICODE API naming, so you usually do not need to specify the A version.

[shankle]

Thanks WJR,
The errors in the WNDCLASSEX struct are now history.

Still have the RECT struct coded in the program.
Without it I get errors.

Working on some other link errors which I am trying to solve.

[shankle]

Down to 3 errors at link time.
  rc,  dwvalue and hInst

 RC with RECT
 dwValue with dwtoa

I have the RECT struct defined in the program and it is giving an error
RC.dll not found. It doesn't seem to call any headers.
If I take the RECT Struct  of the program I get errors.

[dedndave]

Down to 3 errors at link time.
  rc,  dwvalue and hInst

 RC with RECT
 dwValue with dwtoa

dwvalue is not the same as dwValue   :P

RC.dll may be the resource compiler - not the RECT struct

WJR = Wayne J. Radburn   :t

[wjr]

Let the header files define RECT. There would appear to be an "RC.dll" in your source (not the same as rc.dll), but dll is not a member of RECT, so that should be easy to find and fix.

[shankle]

To Dave,
Yep - a typo - dwValue

To WJR,
I let the header files reference RECT.
I have included in the program "windows.h and Mr. Hansen's header files".
There is NO reference in the program to "RC.DLL".
Here is the error I am getting at link time:
   Could not open an input file (RCC.DLL) needed for forced dll or  import
    by ordinal.
Thanks fellows