Re: How do you declare a Global Variable in VC++6
Joseph M. Newcomer wrote:
See below...
On Mon, 24 Mar 2008 07:42:18 GMT, Dan Bloomquist <public21@lakeweb.com> wrote:
****
theApp is about the UI.
****
No, it is only about the message pump. The UI is contained in the various CWnd-derived
classes.
Ok. Poor declaration on my part. It is the repository for the UI.
// Account types
............................................................
namespace StrTypeAccountTypes
{
AFX_STATIC_DATA const LPCTSTR accountTypesStrList[]= {
_T("(null)"),
_T("MMA"),
_T("CD"),
_T("LN"),
_T("SAV"),
_T("CH"),
NULL, //needed for simple list control
};
enum AccountTypes {
actTypeNull,
actTypeMMA,
actTypeCD,
actTypeLN,
actTypeSAV,
actTypeCH,
};
)
****
Note that I have always said that static data that has 'const' is an exception to the
"global variable" rule. They are "global constants". Although it is not clear why they
are not singleton classes...or why they need to actually be global. I would create a
module that held them, if they were needed in more than one class, and therefore the
actual data would not have any global scope whatsoever.
For example,
class AccountTypes {
public:
enum AccountTypes{...as above...};
CString GetAccountName(AccountTypes type);
protected:
static const AccountTypesStrList[];
};
I guess any time you start needing data for a feature you could/should
use a class for hiding. It gives you the ability to create methods that
go with the data. But here I was not ready to commit to the use. But...
or something similar (actually, I would put them in the STRINGTABLE so they could be
localized because while MMA might mean something as an English acronym, it might have no
mnemonic meaning to a German speaker, so I would separate concept from representation. If
I were doing a combobox, I would put the enum as the itemData component so it would be
language-independent, and similarly for a listbox)
I have been moving data to xml. So far, we only ship in English. It may
be a mistake but I feel much more comfortable by just changing data files.
Given the hundreds of thousands of lines I have delivered as products which used NO global
variables and NO CWinApp-derived member variables used outside the CWinApp-derived class,
I believe that using either of these is no longer justified.
And in practice, I have three basic globals. theApp, theProject,
theUserProfile.
****
I prefer to make theApp as stupid about what I'm doing as possible. When
I enhance theApp, it is in a generic way, applicable to any future
application. Only the top derivative, where like I implement doc
templates, does it become app sensitive. And if at all possible, only
the docs know about the specific app.
****
A document should not have the slightest knowledge of theApp or anything in it. If a
document cares about some policy object, then that policy object is a policy object and is
completely separate from and completely unrelated to theApp.
Here I am making a distinction between theApp and 'the app'. I'm sorry I
was not clear.
Everything a document needs to know comes from other sources. I make it a policy to rip
the #include of the CWinApp-derived class from EVERY module these days; it has always been
a fundamental design error of the MFC wizards to have put that header file into any class
but the CWinApp-derived class. I either remove it entirely or replace it with
#include "resource.h"
Likewise. If I need IDs, I include resource.h.
You are confusing scope (global) with extent (lifetime). Something can have "infinite"
extent (exist before execution starts and remain valid until execution ends) without
having global scope.
I guess it is semantics. I consider the above three objects global. They
have global scope in the application. I do include theProject
everywhere. It is all about that object. I don't for theApp. Instead I
have global declarations like:
AfxGetWinPos(...);
Globals are part of the mix even if compartmentalized. Registry keys are
globals, and there are a lot of them....
****
No, Registry keys are data. The data does not have to be global. You can read them as
needed without needing any global variable to hold them.
Yes, they are global in the spirit of accessible objects. Not the same
as a c++ global.
Best, Dan.