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?