>For starters, the compile time concern is baseless. My apps usually compile into APP's or EXE's in only a minute or so, and even if it took longer - who cares? Most client have no idea what 'Compiling' is and probable would'n't care anyway.

True enough.

>Secondly, you would advicate using a public variable in an object oriented application?

It's not OOP, but sometimes ya gotta KISS...

>Third, what if my class was a stand alone custom class that needed to retrieve some static info? Would you instantiate an object just to get that info?

Why create a class to retrieve external, static info? Why not just store the static info in the class? And no, if reusability were a concern, I'd store the static information in a form or application subclass.

>Take for example a custom class that I might want to create as a DLL. This DLL would not be part of any specific application and will need to know a number of subfolders names off a given directory. The subfolder names list is static. Why not put them into an include file, and include the file in the custom class? This would be an excellent example for defining an array in an include file.

See above.

>Since I might have any number of DLL's that use this same array of info, all I need to do is include the header file and I have access to the info I need. Much less work than creating an object I dont need, and in addition, you then wont have some unrelated object compiled into the DLL.

Creating "any number of DLL's" that do the same thing is not OOP, either. 8^)
But that doesn't matter. Do the application in the manner you deem best for your needs. I think this discussion got carried away because those who responded weren't sure *why* you were trying to simultaneously DEFINE an array and assign values to it. There are a lot of ways to do what you want to do, some of them are more elegant but none of them are wrong.