Annoying/incorrect type warning if type defined in seperate source

[Cliff3D]

As per the title, if I declare a type in library (or even just a second source) file I get warnings like:

Code (glbasic) Select Expand

*** Configuration: WIN32 ***
precompiling:
GPC - GLBasic Precompiler V.8.044 SN:1fd6eb1b - 2D, WIN32
"ReadOBJ.gbas"(0) warning : note : TYPE OBJModel is not declared

"ReadOBJ.gbas"(0) warning : note : TYPE OBJModel is not declared

"ReadOBJ.gbas"(136) warning : Demo mode: This command would require "GLBasic SDK premium"  : X_OBJSTART
Wordcount:472 commands
compiling:
IncrediBuild skips: ReadOBJ.gbas,

linking:
success

Even though the comiple completes and the program runs correctly, this is disconcerting - and I may overlook a "real" warning if those "false" warnings are there, not noticing a REAL problem

As you can see in the image below, the type IS declared... the main program relies heavily on it (it wouldn't work at all if the TYPE wasn't there)

I believe this is a "known issue", I just wanted to formerly report it.



[attachment deleted by admin]

[bigsofty]

Yep, this is an old one. In the way of a quick fix, you can declare your global container variable in the main listing ("GLOBAL myvar AS TMyType"). This will let you get up and running I think.

[Cliff3D]

Actually, in Main is where it used to be - but it was getting rather lengthy and untidy in there, so I split it out to a seperate source code to help me manage. The extended type definition has rather a lot in it, so it's just not really suited to being put in the main program (esp. as I intend to use it as a library for a number of small utilities, probably).

But thanks for the suggestion (it seems I have a knack for finding "issues" which haven't been squished quickly, or aren't going to be squished quickly )

[BlueSteel]

(it seems I have a knack for finding "issues" which haven't been squished quickly, or aren't going to be squished quickly )

your not the only one .. a lot of good programmers (mainly amatures like us.. who push the boundries and don't believe in limits) tend to find things that should work but don't .. in ANY language they try..

[Cliff3D]

Limits:- those things behind you!

[Moru]

Yep, we all bumped into those and learned to work around them, Cliff. There was many more problems when I started but Gernot fixed most of them and within days usually Try to keep down the negativism, it's getting tiresome and it's not making it easier for new people if all they see is "this doesn't work..."

All that is needed is a small examplecode of what isn't working, (short) description of what you expect to happen and what exactly happens.

[Cliff3D]

Try to keep down the negativism, it's getting tiresome

Ah, sorry - hadn't intened any. I thought I was trying to be helpful. Noted.

[Ian Price]

GLB isn't perfect, but there is no such thing as a perfect coding language. Besides, you should have seen GLB from the beginning [shudder!]

Fixes will be made over time, and  Gernot has his priorities. Report issues, but don't make a song a repeated song and dance about them - there are always workarounds or alternatives to problems.

Let's all just play nicely, shall we.