unknown type in line 76

[RitchieF]

Hi all,

since several days the compiler of IWBasic brings up the same red error message when I try to compile :

Unknown type in line 76

This happens with every program, even with those having an empty line 76 or are shorter than 76 lines .

Every program refuses to compile. I tried an reinstallation without success .

Any idea what there is going wrong ?

It's IWBasic 1.735 running on WinXP SP3

Thanks for any help

Richard

[LarryMc]

Is the error in the eba file or is it in an inc file that is common to those you are checking?

LarryMc

[RitchieF]

I don't know if it is in an inc file.
Here is an example which doesn't compile anymore (from Parker)
It has only 56 lines but brings the error

Richard

window win
openwindow win, 0, 0, 400, 400, @CAPTION | @SYSMENU | @HSCROLL | @VSCROLL, 0, "Window", &handler

declare import, CreateDC alias CreateDCA( drv:pointer, dev:pointer, out:pointer, pointer initData ),uint
declare import, CreateCompatibleDC( hdc:uint ),uint
declare import, CreateCompatibleBitmap( hdc:uint, width:int, height:int ),uint
declare import, DeleteObject( obj:uint ),int
declare import, APILoadImage alias LoadImageA( inst:uint, name:pointer, utype:uint, cx:int, cy:int, fuload:uint ),uint
declare import, DeleteDC( dc:uint ),int
declare import, SelectObject( hdc:uint, hgdiobj:uint ),uint
declare import, GetObject alias GetObjectA( hgdiobj:uint, cbBuffer:int, lpvObject:pointer ),int
declare import, APIGetPixel alias GetPixel( hdc:uint, xpos:int, ypos:int ),uint

const LR_LOADFROMFILE = 0x10
const LR_MONOCHROME = 0x1
const IMAGE_BITMAP = 0
const CLR_INVALID = 0xFFFFFFFF

type BITMAP
   int bmType
   int bmWidth
   int bmHeight
   int bmWidthBytes
   word bmPlanes
   word bmBitsPixel
   pointer bmBits
endtype

uint hdc, hbmp
uint hwindc
hwindc = GetHDC( win )
hdc = CreateCompatibleDC( hwindc ) 'CreateDC( 0, 0, 0, 0 )
ReleaseHDC( win, hwindc )
hbmp = APILoadImage( 0, "patterna4a.bmp", IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE | LR_MONOCHROME )
SelectObject( hdc, hbmp )

BITMAP bmp
GetObject( hbmp, len(BITMAP), bmp )
for i = 0 to bmp.bmWidth - 1
   for j = 0 to bmp.bmHeight - 1
      pset( win, i+15, j+15, APIGetPixel( hdc, i, j ) )
   next j
next i

DeleteObject( hbmp )
DeleteDC( hdc )

waituntil iswindowclosed(win)
end

sub handler
   select @MESSAGE
   case @IDCLOSEWINDOW
      closewindow *<WINDOW>@HITWINDOW
   endselect
endsub

[billhsln]

Compiles fine on my PC.

Bill

[LarryMc]

works fine for me but I'm running 1.737 so that doesn't prove anything.
But I see no reason why this sample wouldn't compile in older versions.

Have you had any other computer issues around the time this problem started?

Can you post a screen shot of the error message?


LarryMc

[RitchieF]

I can show a screenshot tomorrow.

No I didn't have any other computer issues around the time this problem started.

The weird thing is the error comes up with every program I try, even those I could compile before without trouble .

I can compile Parkers example on my pc at home without problem, too so I think IWBasic is missing something and can't tell it to me.

Richard

[Guilect]

Sometimes I load a single file program in, try to compile it, and it will fail.
That is because I had a project open that had an error in it.
Closing the project, then compiling the single file program will work.
Just a thought.

[sapero]

Richard,
it must be a bug in one of the incc files, in your /bin directory. If you have modified the incc files, or installed a control pak, try one of following solutions:

1. remove third-party incc files. The original files are: controlpak.incc, eb2d.incc, ebdb.incc, ebstd.incc, ebx3d.incc
2. rename file name extension in all incc files (to .txt) but keep ebstd.incc as is, or keep at least one incc file. Compile a program. If no error occurs, restore next incc file and compile again. Do it until the error comes back. so you will know which file has a bug.
3. remove all *.incc files form /bin directory, and reinstall the compiler over existing files.

If an incc file (A) uses datatype defined in another incc file B (for example WINDOW) - ensure the file name (A) is alphabetically "greater" than the file with the definition (B). The compiler is loading all the incc files in alphabetical order, using FindOpen+FindNext.

Example: in ebstd.incc we have a definition for WINRECT. If you have aaaa.incc file referencing to WINRECT, the compiler will throw an error because WINRECT is not yet defined. Rename aaaa to zzzz (or something greater than ebstd), and it will compile fine.

[Blue Steel]

f an incc file (A) uses datatype defined in another incc file B (for example WINDOW) - ensure the file name (A) is alphabetically "greater" than the file with the definition (B). The compiler is loading all the incc files in alphabetical order, using FindOpen+FindNext.

Wow never knew that.. stands to reason though as theres nothing there to state which order to include them in.. maybe thats a feature you could add .. to make it so that you can et the order.. eg: standard includes first .. then perhaps alphabetical or mayve renaming the standard ones so that they should appear first .. as those who use their own may want them called something that could appear first

[sapero]

I have checked it now and this is true: incc files are loaded alphabetically, but the file name reported in error messages is wrong, not initialized for incc files (fixed for next update).

[RitchieF]

Sapero you were right.

I deleted all *.incc files then did a reinstallation and everything works fine again 

Thanks

Richard