I know that when an MFC application initialises, the function AfxGetThread() in thrdcore.cpp will be called. I was able to set a breakpoint on that function, without even opening the file. I chose Debug->New BreakPoint->Break at function-> enter function name as AfxGetThread() and set line and character as 1 each.
When I hit F5, the debugger opened thrdcore.cpp and broke at the beginning of AfxGetThread(). You might want to try it with the function of your interest located in wincore.cpp. The IDE will open the correct file (that it is using), and break at the location of your interest.
You might as well consider using "Advanced breakpoints" (just do a search).
It quickly becomes obvious that even though Visual Studio itself found and opened this file just a moment ago, it is not actually using the copy of Wincore.cpp that I am seeing as part of the build process. So, I can make garbage edits to it, do a "Rebuild All," and still get no errors. This seems completely wrong to me and provokes my ire at a very fundamental level. I mean, I guess Microsoft and I have different definitions of terms like "compile" and "source code."
I think that wincore.cpp is provided for debugging purposes only, MFC can't be compiled easily from the source. What your app links to is the debug versions of MFC dlls. As for VS finding the source that's probably because it is referenced in the dll or some pch file or some such.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
I just wanted to add some observations. You state in your message novel that the variable pMap is NULL. I recognize this variable name as possibly being the internel MFC CHandleMap. If this variable is NULL then you are incorrectly accessing MFC objects across a thread boundry.
I've recently moved my data base code into a worker thread, which works just fine unless the data base open fails. I currently have the thread wait 15 seconds, and then try the open again. This process repeats until the data base opens successfully or the application exits. The problem I'm having is that, when this logic is occurring, my UI thread will fail with an access violation some time later. It appears that having the CDatabase::OpenEx() call fail causes some sort of corruption to either the UI thread's MFC state or its stack, which is then exposed as the UI is navigated.
I'm using SQL Server 2005 Express, Service Pack 2.
I've tried the following to resolve this:
1. If I comment out the data base operations (OpenEx() ... Close()), the UI does not crash.
2. If I comment out the data base operations like in #1, and replace them with a AfxThrowDBException(...), the UI does not crash.
3. One suspect was the CDatabase::OpenEx() implementation, which does some hinky looking things trying to find a window handle. I overrode it and passed a NULL window handle to the ::SQLDriverConnect() call that does the real work of connecting to the data base. The UI still crashes.
From these results I can only conclude that there is some kind of problem here using CDatabase/CRecordset in a worker thread that isn't documented. I've searched on MSDN and Google'd several times, and only found claims of issues with specific ODBC drivers.
Anyone have any suggestions, or ideas that I've missed?
Apologies if this has been covered somewhere but I've not found anything related. I'm working on an idea which would require a long-running task to complete at the time the user logs off, I know it's possible to delay the logoff but I was hoping to find a way to run the task as part of the logoff, something like when Windows synchronises offline folders (not sure if that's exactly the right term as I am working from memory here).
Thanks for the reply, it is a user mode application and I know I can prevent shutdown by returning false for WM_QUERYENDSESSION but that keeps the logged in session alive, what I want to do is to run the code during the logoff, effectively after the user has been logged off.
For example, when you a running Windows XP on a domain and you have offline file enabled, you will see the synchronisation window appear during the logoff to sync any remaining files back to the domain controller, I'm trying to achieve something like this. The app does not have to remain a user mode app, it could quite easily become a service if that is required but preventing the logoff is not what I'm trying to achieve.
Thanks for the reply, it is a user mode application
Usermode applications are limited in their ability to delay/prevent shutdown. You are basically limited to what I described in my previous posts. I believe that you have 5 seconds to respond to the WM_QUERYENDSESSION so you might be able to perform some last-second tasks.
For example, when you a running Windows XP on a domain and you have offline file enabled, you will see the synchronisation window appear during the logoff to sync any remaining files back to the domain controller, I'm trying to achieve something like this.
Have you considered using Logon/Logoff[^] or Startup/Shutdown[^] scripts? This is typically what an administrator would use to execute something on shutdown/logoff.
Thanks for the tip, I'll have a look into the scripts and see if they can do what I need. I've just discovered SCM notifications which look promising although I haven't read enough about them to know if they can do what I want yet.
I have created a SDI application with having a LeftView and RightView.LeftView is inherited from CTreeCtrl class where as the rightview is inherited from CFormView class.Can anybody tell me how to split the rightview into 2 halves?
when i run this code , it run but not give me a error message. plz solve my error.
Assuming you mean the opposite of what you wrote - Why don't you just step through the code with the debugger and see where it fails?
Also, next time you post your code please embed it in the "code block" tags.
you can add a TabWnd to the Dialog.
Then you can add a CFormView to this TabWnd.
When you move/resize the TabWnd, you can "hide" the TabWnd and you only see the active CFormView.
Naturally you can switch the View into the TabWnd with another View...