I'm fairly new to Win32 + MFC but it seems to me that using globals is virtually unavoidable.. with the WinProc and all.. or in MFC with different classes. Is there a solution to this problem I haven't come across yet in my learning? I never use global variables in my other programs, but it seems they must have to play a major part in Win32 or MFC programs.
In the wnd procs, just declare then static...they will then be there on the next call
In MFC, declare your simple variables in in the class declaration.....they will stay in scope as long as the class
If you want to access something in another class with MFC, there is a dirty way of using AfxGetApp () to get a pointer to your app....you might be able to access other classes through that depending on how you have built it......I dont like doing this much though
Last edited by Fordy; 07-19-2002 at 09:31 PM.
Mmm, I know how you feel. When I started programming with the Win32 API, I was disgusted. Global variables, static variables... petzolds book is purely C. It scared me. I haven't touched it in awhile... I'm looking for a book, or a refrence which deals with the Win32 API and Object Oriented concepts (Basically a book that teaches the Win32 API with C++)I'm fairly new to Win32 + MFC but it seems to me that using globals is virtually unavoidable.. with the WinProc and all.. or in MFC with different classes. Is there a solution to this problem I haven't come across yet in my learning? I never use global variables in my other programs, but it seems they must have to play a major part in Win32 or MFC programs.
Where can one find petzold's book?
Try Amazon.com or order from a ask your local bookstore for the phone numbers of sellers of "hard-to-find" books. I used to work at a bookstore and we had lists of suppliers.Where can one find petzold's book?
You too?I'm fairly new to Win32 + MFC but it seems to me that using globals is virtually unavoidable..
Yeah MS really made a mess of their API, an accident, I'm sure
Y'know, here I am, been programming for a year now, and at least 6 mos of that messing with Win32. What an occultish ritual THAT is! For one, there is little *solid* documentation of how functions are implemented, how they affect other areas of your app, etc. Worse yet, functions do not work as expected at times, as in: parameters that SHOULD be non-zero to work unexpectedly do, or vice versa! In fact, I just deleted my entire C Windows library. Too buggy. So I am rewriting it from scratch in - guess what? - C++ !!
So that would be my first suggestion. Second, work slowly, mastering each little piece till you have a stable framework.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
I don't know if this will help but here are some previous cprog->windows discussions:
http://www.cprogramming.com/cboard/s...static+wndproc
http://www.cprogramming.com/cboard/s...hlight=wndproc
guys, I'm a windows developer and there are only three types of globals I EVER have in my code.
WinMain() obviously
WndProcs() because that's our messages
and any Exported DLL functions. usually I only have one in my dll's to give me access to an object.
The deal is this...
1. Create an instance of your "Window" object in WinMain
2. Call CreateWindow() width an LPARAM of the pointer to the object
3. Handle WM_CREATE in the WndProc such that it does a SetWindowLong(hWnd, GWL_USERDATA, lParam); (of course the lParam means the item out of the CREATESTRUCT) This is your object
4. Each time into the callback, GetWindowLong(hWnd,GWL_USERDATA) to get the object pointer.
It's very simple, this provides a way of having NO GLOBAL DATA which is the way it should be.
I realize that you may not want to use classes also. My method works just fine for structs also. Put all data associated with that window in a struct and pass the pointer into createwindow as above
But - Why so against global varibles?
VC++ 6
Sounds fascist.Originally posted by Hershlag
It's very simple, this provides a way of having NO GLOBAL DATA which is the way it should be. [/B]
and ugly.
3. ...
SetWindowLong(hWnd, GWL_USERDATA, lParam);
Global data is widely regarded as sloppy. I don't see that as something that makes me fascist.A neat freak maybe but hardly fascist. Besides, any windows programmer should write code that is fairly thread-safe and globals are the anti-thread.
How is SetWindowLong ugly? it's a great way to associate data with a window in Win32. You have SetProp() also, but it requires a string search and is probably a bad alternative.
Thanks for all the help, I now see several solutions to this problem, and I also am glad to realize I'm not the only one faced with this issue.
But - Why so against global varibles?
Of course this comes from a man w/ the ID of VBProgrammer :P.. Here in C++ world they are generally regarded to be on the evil side. (no offense, the VB thing was just funny to me)
coz, you don't need to baby VB. He works with asm and is even writing his own OS.
ah ok, guess I just didn't expect that from the nick
I work with a guy that is probably much like VBProgrammer. We used to debate things like global variables until we realized something about programming. There are different levels of abstraction that programmers work in. Basically, the lower level coder you are, the more often you are reinventing the wheel. The world NEEDS people who are willing to reinvent the wheel so that we can come up with better and better wheels. But it also needs people at higher levels of abstraction to build things with those wheels.
The higher level of abstraction you work in, the more you should think about structure and design being readable. The lower you work in, the more you need to think about optimization for speed. Global variables are suitable to this low level but not higher levels. VBProgrammer has an ironic name in that he obviously thinks in this low level but you should understand that without us higher level thinkers we'd have great wheels but CRAPPY SOFTWARE!
