Just testing out some of the new LiteC features, using an array of PANEL*:

// DEFINES FOR PANEL INDICES...
#define NEW_OR_LOAD 0
#define GAME_OPTIONS 1
#define INVENTORY 2
...
// Array to hold PANEL* handles...
var panelList[ LIST_SZ ];

...

function createPanelList(var* panels)
{
PANEL* selection1 = {
pos_x = 0; pos_y = 0;
digits(10,10,1,*,1,1);
flags = VISIBLE;
}

PANEL* selection2 = {
pos_x = 0; pos_y = 0;
digits(10,10,1,*,1,2);
flags = VISIBLE;
}

PANEL* selection3 = {
pos_x = 0; pos_y = 0;
digits(10,10,1,*,1,3);
flags = VISIBLE;
}

// Hide last 2 panels...
toggle(selection2,VISIBLE);
toggle(selection3,VISIBLE);

// Fill array with PANEL* objects ...
panels[ NEW_OR_LOAD ] = handle( selection1 );
panels[ GAME_OPTIONS ] = handle( selection2 );
panels[ INVENTORY ] = handle( selection3 );
}

function main()
{
...
createPanelList( panelList );
...
}

The point here is, I really like to avoid needless globals... sure they're easy to work with, but can cause problems later. In the above example, only the array containing the PANEL*s is global, while all the details of the actual PANEL* objects are only visible where needed. Without the LiteC array features this wouldn't be possible.

However, I did realize something else. It seems the engine types (PANEL*, BMAP*, etc.) are different than vars, in the sense that they are brought into existence in the engine, thus don't loose there scope like vars. If they did loose scope, then even the above code would not work, because the PANEL handles stored in the array would no longer point to valid objects (PANEL*s) after leaving createPanelList().

function createPanelList(var* panels)
{
PANEL* selection1 = {
pos_x = 0; pos_y = 0;
digits(10,10,1,*,1,1);
flags = VISIBLE;
}

This won't work - you can not declare global objects in a function. Only local and static variables or pointers can be declared within a function. See the manual for the difference between local and global variables:

http://manual.conitec.net/aarray.htm

What would work is:

PANEL* selection = pan_create(...);

This can be called in a function. PANEL* name = { ... } however is a global declaration.

But, it does work I originally had my panel statements global, at the top of my listing. Then, just as a test, I decide to move them to the location specified in my code. However, they are stored in a global array, which is part of the reason it would work.

None the less, I'm as surprised as you, but will double check my code to make sure it doesn't just look like it works. If you'd like I could share the whole listing.

EDIT: Don't see any loop holes that would make it look like its working, when it really isn't. Also, techically speaking, the panels are not stored in the array, but rather the "handles". This is the fact that lead me to believed it works because the engine has already registered them (because I can get the handles). It would be interesting to try this with other built in types.

Now, stranger things have happened... I could add some other code that's actually game related and it could stop working and start complaining

In fact the panels are created, but static and not local. This has many side effects, f.i. your panels are not removed after leaving the function, and are not created again when you call the function anew. Because of this confusing behavior and because it does not make sense to declare engine objects in a function, we've just written in the manual that engine objects must not be local.

Is this really such a bad thing, really? My createPanelList() is not meant to be called numerous times. The function is not meant for "reuse" within the app inself, but to keep the global code cleaner as a logic block that's a little more maintainable... especially in a larger more complex app, where globals will abound. I do agree, however, that care must be taken and that it may not be a general practice.

Though I didn't mention it, I did wonder about the possibility of "static", as this was stated about array creation/initialization in another post I read... though one is not explicitly creating the array as static, it is made static when initialized at creation time; i.e., "int a[3] = {1,2,3};".

I do think it odd that such arrays, panels (and whatever other variables) are implicitely made static if initialized at creation time. I just don't recall variables being implicitly made static in C. I think they are always explicitly requested via the "static" modifier. I like the availability of "static" when it makes sense, but implied statics are dangerous.

ADDITION: I thought some more on what you said and my own intent in the implementation. I could reach the same goal by placing all the panels related code in their own .h and .c to meet the same ends. I did think about the use of pan_create(). If I used pan_create's, instead of the PANEL* definitions, would this make sense to you?