AfxGetApp() returned NULL - A possible solution.
in [MFC]
|
Prev: h2inc
Next: Process handle leakage
From: Marius on 18 Dec 2009 16:16 I had the problem too that AfxGetApp() returned NULL inside the function of a dll. The solution was to set the ?General?configuration prop of the exe ?Use of MFC? to the value ?Use MFC in a shared DLL?. (perhaps because the dll where it was called (and crashed) was build with that config property as well). Building the app / exe with statically linked MFC libs resulted in AfxGetApp() returning NULL. (I'm using MFC90) Ajay Kalra wrote: Also, Are you by any chance mixing various versions of MFC. 07-Dec-07 Also, Are you by any chance mixing various versions of MFC. That could happen if you havent migrated all projects to the newer version(thats likely if this is happening in an EXE and it worked in VS2003). --- Ajay "Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message news:9B30B7F4-9A15-4109-A6BD-55BED866AC5E(a)microsoft.com... Previous Posts In This Thread: On Friday, December 07, 2007 8:30 PM Ajay Kalra wrote: This would happen in a MFC Regular DLL if you havent use AFX_MANAGE_STATE This would happen in a MFC Regular DLL if you havent use AFX_MANAGE_STATE properly. Is this in a Regular DLL or in a Exe? --- Ajay On Friday, December 07, 2007 8:48 PM Ajay Kalra wrote: Also, Are you by any chance mixing various versions of MFC. Also, Are you by any chance mixing various versions of MFC. That could happen if you havent migrated all projects to the newer version(thats likely if this is happening in an EXE and it worked in VS2003). --- Ajay "Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message news:9B30B7F4-9A15-4109-A6BD-55BED866AC5E(a)microsoft.com... On Friday, December 07, 2007 9:33 PM Sheng Jiang[MVP] wrote: Put a breakpoint in your App's constructor (add one if you don't have it). Put a breakpoint in your App's constructor (add one if you don't have it). Run your application. If the error happens before your App's constructor is called, then you have a bug. Most likely you are trying to access the app in another global variable's constructor, and the sequence of constructing global variable is undefined. Redesign your applition so your global variables 's constructors don't rely on the existance of the app object. -- Sheng Jiang Microsoft MVP in VC++ "LogicMan" <garybell.home(a)gmail.com> wrote in message news:953f6a25-a0be-4803-8cdf-5e36b0cb4235(a)b15g2000hsa.googlegroups.com... On Friday, December 07, 2007 10:34 PM Ajay Kalra wrote: Re: AfxGetApp() returns NULL No, this should not impact the EXE. This should happen only in a MFC Regular DLL. You dont need this macro in a EXE. --- Ajay On Friday, December 07, 2007 10:37 PM Ajay Kalra wrote: Re: AfxGetApp() returns NULL "LogicMan" <garybell.home(a)gmail.com> wrote in message news:5eb6526f-f6d4-4a21-bc48-9340d2b2dc10(a)w40g2000hsb.googlegroups.com... Use DEPENDS.exe and see if you have multiple versions of MFC linked in your module. I suspect this to be the case. Make sure you rebuild all the projects when you build in VS2005. This also means all your module are either Debug or Release, include COM servers. --- Ajay On Friday, December 07, 2007 11:16 PM Joseph M. Newcomer wrote: Generally, the use of members of CWinApp-derived classes is a good Generally, the use of members of CWinApp-derived classes is a good illustration of exceptionally poor methodology. There's the "don't use global variables" rule, which is misinterpreted as "put those variables in the CWinApp class and they're not global", which is merely syntactic saccharine (not even as good as syntactic sugar) on marginal methodology. A good MFC program does not use the CWinApp class in any module except the implementation of the CWinApp class. Are you using threads? Is this happening when you call it from a thread? I've not had this problem, but I never use the CWinApp-derived class outside the CWinApp-derived implementation. If a variable is logically global, make it global, don't throw it in the CWinApp class to pretend it isn't global. The program gets simpler, the code gets simpler, and you remove every #include statement of the CWinApp class header file from every .cpp file EXCEPT the CWinApp-derived implementation file. So one thing I'd do (and I have done when confronted with AfxGetApp() overuse) is just move those variables out of the CWinApp class. Whenever I get a program, one metric of how bad the coding is can be obtained by how many times AfxGetApp() is cast to the CWinApp-derived class. Each use costs 10 points on the bad-style scale. Replacing AfxGetApp by thisApp increases it to 20 points each on the bad-style scale (reason: it adds a kludge to a bad design). joe On Fri, 7 Dec 2007 17:11:38 -0800 (PST), LogicMan <garybell.home(a)gmail.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Saturday, December 08, 2007 6:50 AM David Wilkinson wrote: Joseph M. Joseph M. Newcomer wrote: Joe: While I agree that the default inclusion of the application header in every class of the project is crazy, I do not see anything wrong with using the application class for settings common to the application as a whole (for example, the foreground and background color scheme used by all the views). And if you are going to do it, I think COLORREF backColor = theApp.BackColor(); is obviously better than COLORREF backColor = ((CMyApp*)AfxGetApp())->BackColor(); -- David Wilkinson Visual C++ MVP On Saturday, December 08, 2007 7:06 AM LogicMan wrote: AfxGetApp() returns NULL Hi, While I've been programming for a number of years I'm fairly new to MFC (and C++ for that matter). I have inherited a rather large MFC app that had been done in VS2003. I recently moved it to VS2005. While I was able to make it compile with much troubleI immediately ran into major problems running the application. They manifested as access violations and were all centered around calls to AfxGetApp() to access member variables of the main application object. It's not always the same place in the application, but it's always the same sequence. AfxGetApp() ends up calling the routine below. When the if(pState->m_pModuleState != NULL) is true then it ends up returning a NULL value. When it falls through to use the _afxBaseModuleTate.GetData() then all is well. This is all in the main app, not a DLL, although there are quite a few DLLs that get referenced (as in process COM objects). I'm a bit over my head on this. I've been able to make most problem go away by replacing any AfxGetApp()-> references with thisApp. references. but obviously there's stuff going on that Is there some direction I can take to help solve this? Is there something inherently different in VS2005 than VS2003 that I should be aware of as it pretains to how state is stored, etc? Any direction would be greatly appreciated. Thanks!! AFX_MODULE_STATE* AFXAPI AfxGetModuleState() { _AFX_THREAD_STATE* pState = _afxThreadState; ENSURE(pState); AFX_MODULE_STATE* pResult; if (pState->m_pModuleState != NULL) { // thread state's module state serves as override pResult = pState->m_pModuleState; } else { // otherwise, use global app state pResult = _afxBaseModuleState.GetData(); } ENSURE(pResult != NULL); return pResult; } On Saturday, December 08, 2007 7:06 AM LogicMan wrote: Thanks Ajay...This is happening in the main EXE itself. Thanks Ajay...This is happening in the main EXE itself. There are quite a few DLL's referenced as COM objects. From what I can tell the majority of the methods in the DLL's use the AFX_MANAGE_STATE macro. Is there something that could occur in the DLL's that might affect the main EXE? On Dec 7, 7:30 pm, "Ajay Kalra" <ajayka...(a)yahoo.com> wrote: On Saturday, December 08, 2007 7:06 AM LogicMan wrote: Thanks again for your help. I'm not sure you mix versions. Thanks again for your help. I am not sure you mix versions. Would it happen by linking against LIB files from a previous version? On Saturday, December 08, 2007 7:06 AM LogicMan wrote: Thanks Sheng. No, this happens well after the constructor is called. Thanks Sheng. No, this happens well after the constructor is called. On Saturday, December 08, 2007 7:58 AM Joseph M. Newcomer wrote: Actually, I'm more inclined to create a singleton class, ColorSettings, in Actually, I'm more inclined to create a singleton class, ColorSettings, in which I place all the color information that is global. This never appears in the application class, but instead anyone who needs it includes "ColorSettings.h" and therefore can get the color settings without reference to the CWinApp class. Or, alternatively, a ColorSettings object is view-relative, except that there is a singleton member which is the global default view or some other global color scheme, but then I can include it in each view, and reference both the local colors and the current default global color. In such a case, the constructor sets the local color to the default global color. Either is a cleaner solution than just dumping everything into the CWinApp class. joe On Sat, 08 Dec 2007 06:50:21 -0500, David Wilkinson <no-reply(a)effisols.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Saturday, December 08, 2007 10:30 AM Alexander Grigoriev wrote: Aren't they better belong to CMainFrame? Aren't they better belong to CMainFrame? Anyway, it's always a tricky question where you put all those little global settings (NOT state) that affect all your windows, and, more important, how you access them. In my opinion, that should be a singleton helper class (which is probably a member of CMyApp), and reference to a particular setting/option should be done by "string". The class should provide _static_ metods, so the clients don't have to carry its pointer around. "David Wilkinson" <no-reply(a)effisols.com> wrote in message news:O9IVECZOIHA.4712(a)TK2MSFTNGP04.phx.gbl... On Saturday, December 08, 2007 11:45 AM David Wilkinson wrote: Joseph M. Joseph M. Newcomer wrote: Joe: Yes, perhaps a singleton is a more elegant solution, but the only thing I really think is wrong with using the application object is that it introduces dependence on a potentially large header into other classes, thereby increasing compilation time. -- David Wilkinson Visual C++ MVP On Saturday, December 08, 2007 1:13 PM David Ching wrote: Re: AfxGetApp() returns NULL "David Wilkinson" <no-reply(a)effisols.com> wrote in message news:eUmBHnbOIHA.4752(a)TK2MSFTNGP05.phx.gbl... Whether or not you put the variables in the CWinApp class and include that header file, or in another one, it doesn't affect compile time since in both cases you need to include a header file to access the "global" variables. I don't think the header file for the CWinApp-derived class requires any additional dependencies, so it is no slower to include this header file than another one. This whole thing about where to put variables whose scope is the entire application is a matter of religion, and like other religious matters, generates a whole lot of fanatical noise over nothing. -- David On Saturday, December 08, 2007 5:11 PM Tom Serface wrote: I use theApp. method all the time and it works OK for me. I use theApp. method all the time and it works OK for me. When I've created objects (as Joe indicates) I usually end up putting them in theApp anyway and end up with something like: theApp.GetOrderQueue() which creates the singleton if necessary, but just returns a pointer to it if there is already a queue created. Kind of a mixture of both ideas. I'd rather not have global variables so I like assigning things that would have otherwise been global (including singletons) to theApp. Tom "David Wilkinson" <no-reply(a)effisols.com> wrote in message news:O9IVECZOIHA.4712(a)TK2MSFTNGP04.phx.gbl... On Saturday, December 08, 2007 11:10 PM Joseph M. Newcomer wrote: Key here is that if I use the "colors" file in three modules, those three, and Key here is that if I use the "colors" file in three modules, those three, and only those three, modules are candidates for recompilation if I change something about the colors. If I put it in the CWinApp class, due to the serious fundamental design flaw in how MFC generates program files, EVERY module will recompile. So it DOES change the compilation time, because I do not need to introduce gratuitous dependencies. This has been analyzed and proven to be the correct strategy; see Ellen Borison's PhD dissertation, "Program changes and the cost of selective recompilation", which demonstrates beyond any possible argument that "umbrella" include files and the clumping of unrelated objects results in much higher compilation times. She's done the study. The numbers are there. http://portal.acm.org/citation.cfm?coll=GUIDE&dl=GUIDE&id=916690 or google for "Borison selective recompilation". I was on Ellen's PhD committee, because I'd been saying this for years and she decided to prove it one way or the other, and I was the "outside" member. Note that the scope may be the entire program, but the DEPENDENCY is not! (Ellen gathered statistics on real, live programs, and when there are large include trees, any given module uses no more than about 4% of the symbols defined, but every change triggers massive recompilation). Do not confuse scope and dependency. Virtually NONE of the files require that data structure. My document would not care about colors; my FFT module wouldn't care, my process manager wouldn't care, my Internet connectivity modules wouldn't care, but due to slovenly thinking, Microsoft puts the dependency of the CWinApp file in EVERY ONE OF THESE generated files! Given that I can rip the dependency OUT of every file EXCEPT my CWinApp-derived class, and suffer no harm at all, putting it there is just foolish. Include only the headers you need, not one single one more. So there is no way I would include my "colors.h" header in every one of my 400 compilation units, just in the three that care about colors! joe On Sat, 08 Dec 2007 18:13:34 GMT, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Saturday, December 08, 2007 11:11 PM Joseph M. Newcomer wrote: No. No. The main frame would probably not care in the slightest about what colors the views wanted. They would belong in the mainframe only if the mainframe was the ONLY module that cared. joe On Sat, 8 Dec 2007 07:30:12 -0800, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Saturday, December 08, 2007 11:12 PM Joseph M. Newcomer wrote: The problem here is a confusion between the concept of syntactic global and The problem here is a confusion between the concept of syntactic global and the logical concept of global. The CWinApp gives the delusion that because it is a class, the variable isn't global, but it actually is. It is merely decorated with some silly syntax that satisfies some religious principle of globality, without actually changing the fundamental logical flaw of globalilty. joe On Sat, 8 Dec 2007 14:11:04 -0800, "Tom Serface" <tom.nospam(a)camaswood.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Saturday, December 08, 2007 11:18 PM Joseph M. Newcomer wrote: I will not be online until next weekend... I will not be online until next weekend...a week in Minneapolis teaching device drivers next week. joe On Sat, 08 Dec 2007 18:13:34 GMT, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Sunday, December 09, 2007 12:16 AM Tom Serface wrote: Fair enough. I confess it's all a matter of programmer's preference. Fair enough. I confess it's all a matter of programmer's preference. However, referencing the variable or function with "theApp" reminds me of where it resides so I don't have to wonder if it is local, global, or whatever. I do this with very few objects, but it's handy on occasion. Tom "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:dnqml3d8q3pgba8n44p86bckc4ftj2mm8n(a)4ax.com... On Sunday, December 09, 2007 12:16 AM Tom Serface wrote: Have a great trip. You will be missed. Have a great trip. You will be missed. We'll try to hold down the group Tom On Sunday, December 09, 2007 12:49 AM David Ching wrote: With precompiled headers, especially with the LEAN_AND_MEAN flag, the affected With precompiled headers, especially with the LEAN_AND_MEAN flag, the affected modules recompile so fast, I doubt it makes a difference. And I've never seen the "colors" global variables split out from other global variables like you have illustrated. Rather, all global variables are lumped into the same header file so they can persisted across sessions easily. -- David "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:j2qml3h8vsi4qmfjfdijg5u9vq5snekbn6(a)4ax.com... On Sunday, December 09, 2007 8:40 AM Joseph M. Newcomer wrote: I think that is because many people think of "the global variables" as a lump. I think that is because many people think of "the global variables" as a lump. I never do. If I have twenty unrelated global variables/singleton classes, I have twenty header files. It makes the dependencies obvious. I have not had a "global variable header file" in about 30 years. I find it nonsensical to have a single global header file, because it lumps a bunch of completely unrelated things together as if they have some relationship, which they rarely do. However, the chances I will have more than about five global variables is vanishingly small, so I will typically only have five header files. Just because a poor methodology is in common use doesn't make it a good methodology. joe On Sun, 09 Dec 2007 05:49:18 GMT, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Sunday, December 09, 2007 9:16 AM Joseph M. Newcomer wrote: Does anyone remember debugging from "cross-reference lists"? Does anyone remember debugging from "cross-reference lists"? These were required because you never knew which module might modify which variable, because all variables were global. The point of never using a single "globals.h" header file is that you know precisely which variables a module is likely to modify, or depend on, because those modules, and those modules alone, can access the variable, because no other module can even name the variable. If everything is lumped into a single globals.h header file, then every module can potentially modify every variable. This leads to either bad practice (they modify the variables) or confusion (which of the 400 modules that includes globals.h might actually modify the color variable?). If a variable is used in three modules, ONLY those modules can see it. joe On Sun, 09 Dec 2007 05:49:18 GMT, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Sunday, December 09, 2007 10:22 AM David Ching wrote: Re: AfxGetApp() returns NULL This is a moot point today, with the excellent browsers and reference lists instantly available in the IDE. Of course, you do not use the IDE so you would not have access to them. ;) -- David On Sunday, December 09, 2007 10:24 AM David Ching wrote: Re: AfxGetApp() returns NULL "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:qtrnl3pv9lba8f407df03kq597ttbvis33(a)4ax.com... The only global variables I use regularly are the user options (user preferences). Since the user preferences are set in one dialog or tabbed dialog, it makes sense to lump them together. Because then they can be displayed, edited, and saved to registry/disk together. And they need to be global because who knows where in the app they will be used. -- David On Sunday, December 09, 2007 8:30 PM LogicMan wrote: Appreciate the advice, unfortunately that's the least of this programsproblems Appreciate the advice, unfortunately that's the least of this programs problems right now :-) I am using threads and I added some TRACE macros to see what the thread ID was and it seems to always be the main thread. Is there something related to the module state that I should look out for with threads? Thanks again - Gary On Monday, December 10, 2007 2:21 PM Sheng Jiang[MVP] wrote: It might be an access violation bug that wiped out the current thread state. It might be an access violation bug that wiped out the current thread state. You can add ASSERT(AfxGetApp()!=NULL) all over the place to trap this error earlier, the earlier the better. -- Sheng Jiang Microsoft MVP in VC++ "LogicMan" <garybell.home(a)gmail.com> wrote in message news:2b54040d-264e-4682-9bb1-515497923f8d(a)w40g2000hsb.googlegroups.com... the implementation thread? On Wednesday, December 12, 2007 7:46 AM LogicMan wrote: Re: AfxGetApp() returns NULL I am thinking you may be on to something. I have tried the other suggestions and continue to have the problem. Thanks for the help. On Saturday, December 15, 2007 6:31 PM Joseph M. Newcomer wrote: The coder of the app knows which modules need them, and therefore would The coder of the app knows which modules need them, and therefore would include them only in the modules that need them. There is no reason to make them visible to every module in the system. Visibility is one of the issues:do not make a variable visible unless it is needed. joe On Sun, 09 Dec 2007 15:24:55 GMT, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Saturday, December 15, 2007 6:33 PM Joseph M. Newcomer wrote: Actually, I don't need access to the browsers and reference lists because I Actually, I don't need access to the browsers and reference lists because I don't do things that really require them. By choosing programming disciplines that obviate the need for them, their importance, or even existence, is moot. However, the arguments you just made also say that Hungarian Notation is now definitely irrelevant. joe On Sun, 09 Dec 2007 15:22:18 GMT, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm On Saturday, December 15, 2007 8:06 PM David Ching wrote: Re: AfxGetApp() returns NULL "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:juo8m3lv68u54mtpq1gm97ni2pd0ni9t3s(a)4ax.com... I'm just curious what "programming disciplines" will give you an instant list of all references to a function? Its usage is more optional now than ever. It's not in the .NET culture, although some still put the m_ prefix. -- David Submitted via EggHeadCafe - Software Developer Portal of Choice OWC Spreadsheet Component ASP.NET Calculations http://www.eggheadcafe.com/tutorials/aspnet/2adaa1e2-349d-400c-8966-574848f2e3f8/owc-spreadsheet-component.aspx
From: David Ching on 18 Dec 2009 17:43 "Marius Versteegen" wrote in message news:20091218161646bas.versteegen(a)gmail.com... > I had the problem too that AfxGetApp() returned NULL inside the function > of a dll. > > The solution was to set the ?General?configuration prop of the exe ?Use of > MFC? to the value ?Use MFC in a shared DLL?. (perhaps because the dll > where it was called (and crashed) was build with that config property as > well). > > Building the app / exe with statically linked MFC libs resulted in > AfxGetApp() returning NULL. > > (I'm using MFC90) > Statically linked MFC DLL's and dynamically linked Regular MFC DLL's need to call AFX_MANAGE_STATE (AfxGetStaticModuleState()); as the first line in every exported function. If you do this, perhaps AfxGetApp() will work. See http://msdn.microsoft.com/en-us/library/ft1t4bbc%28VS.80%29.aspx -- David
|
Pages: 1 Prev: h2inc Next: Process handle leakage |