How to declare Global Variable [modified]
-
How to declare "Global Variable" that whole class in the project(MFC) can see this variable. Where's to declare it? Please Help.
modified on Thursday, November 19, 2009 12:37 AM
If you need a variable visible to all classes of your project, an option maybe a
staticmember variable of yourCWinApp-derived class. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
If you need a variable visible to all classes of your project, an option maybe a
staticmember variable of yourCWinApp-derived class. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Doesn't need to be static. Presumably, there's only one instance of the app and it's there for the duration. But I like the placement. :)
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
-
How to declare "Global Variable" that whole class in the project(MFC) can see this variable. Where's to declare it? Please Help.
modified on Thursday, November 19, 2009 12:37 AM
Out of curiosity, why do you need a global variable that can be accessed by "whole class in the project"? I think that a singleton class would be the best option, but I'd like to know the reason first...
“Follow your bliss.” – Joseph Campbell
-
Doesn't need to be static. Presumably, there's only one instance of the app and it's there for the duration. But I like the placement. :)
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
Doesn't need to be static? The OP said he needs it 'everywhere'. For instance, think of those classes that are his own (and have no access to the CWinApp derivative). They won't be able to touch the variable unless it is static. The fact that I consider a singleton class instead of a global variable a better option is aside though.
“Follow your bliss.” – Joseph Campbell
-
Doesn't need to be static? The OP said he needs it 'everywhere'. For instance, think of those classes that are his own (and have no access to the CWinApp derivative). They won't be able to touch the variable unless it is static. The fact that I consider a singleton class instead of a global variable a better option is aside though.
“Follow your bliss.” – Joseph Campbell
You have access to the instance of the CWinApp derived class anywhere you include the .h file with extern AppClass the App. There is only one of them. The member of that class he wants is NOT static but a regular memeber. There is, presumably, still only one of them and it's available anywhere through the app instance, theApp.theVarible or theApp.GetVariable() depending on how anal you are about accessor functions. I fall into the anal category. ;P
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
-
You have access to the instance of the CWinApp derived class anywhere you include the .h file with extern AppClass the App. There is only one of them. The member of that class he wants is NOT static but a regular memeber. There is, presumably, still only one of them and it's available anywhere through the app instance, theApp.theVarible or theApp.GetVariable() depending on how anal you are about accessor functions. I fall into the anal category. ;P
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
Never mind, I actually got your comment wrong. I fall into your category as well. :)
“Follow your bliss.” – Joseph Campbell
-
You have access to the instance of the CWinApp derived class anywhere you include the .h file with extern AppClass the App. There is only one of them. The member of that class he wants is NOT static but a regular memeber. There is, presumably, still only one of them and it's available anywhere through the app instance, theApp.theVarible or theApp.GetVariable() depending on how anal you are about accessor functions. I fall into the anal category. ;P
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
Tim Craig wrote:
You have access to the instance of the CWinApp derived class anywhere you include the .h file with extern AppClass the App.
There's no need to expose the application object anywhere you need just one variable. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Tim Craig wrote:
You have access to the instance of the CWinApp derived class anywhere you include the .h file with extern AppClass the App.
There's no need to expose the application object anywhere you need just one variable. :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]True, but then there's no technical reason we need object oriented code either. ;P But if a variable needs to be seen by the whole application, then encapsulating it in the app class seems the perfect place for it.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
-
True, but then there's no technical reason we need object oriented code either. ;P But if a variable needs to be seen by the whole application, then encapsulating it in the app class seems the perfect place for it.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
Tim Craig wrote:
But if a variable needs to be seen by the whole application, then encapsulating it in the app class seems the perfect place for it.
Nah. If you need just one variable, granting access to other members of
CWinAppmake no sense (if we've a reason to keepOOPalive: you know, information hiding ;P ;P . If the OP needs, for instance, a global counter, then you grant him access tom_hInstance,m_pActiveWndand so on?). :-DIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Tim Craig wrote:
But if a variable needs to be seen by the whole application, then encapsulating it in the app class seems the perfect place for it.
Nah. If you need just one variable, granting access to other members of
CWinAppmake no sense (if we've a reason to keepOOPalive: you know, information hiding ;P ;P . If the OP needs, for instance, a global counter, then you grant him access tom_hInstance,m_pActiveWndand so on?). :-DIf the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Gee, seeing as how theApp is global anyhow, I'd say he has access to them whenever he wants. Of course, I seem to remember getting smacked around in some forum here when I said sealed classes were a stupid idea but maybe that was just some C# twits who happened to be wandering by. :rolleyes:
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.