|
Hi!
I've developed a MFC application. It was running fine. Suddenl it stopped running. I didn't change any code. I could not run setup file and from IDE as
well. If I try to run in release mode:
'flash_mfc.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.MFCLOC_1fc8b3b9a1e18e3b_9.0.30729.4148_x-ww_15fc9313\mfc90enu.dll',
Binary was not built with debug information.
is displayed in the output window.
If I run in debug mode, application crashes and breaks at
ASSERT(IsWindow(pTemp->m_hWnd));
in the file occcont.cpp.
CreateDlgControls failed during dialog init. Detected memory leaks!
CoCreateInstance of OLE control {D27CDB6E-AE6D-11CF-96B8-444553540000} failed.
Result code: 0x80040154
Is the control is properly registered?
is displayed in the output window. Why it has happened suddenly(without no change in code)? Is this due to ServicePack? I 'm developing using Visual
Studio 2008 under Windows XP. The same project output runs fine at target systems. Here's the debug CallStack:
> mfc90ud.dll!COleControlContainer::FillListSitesOrWnds(_AFX_OCC_DIALOG_INFO * pOccDlgInfo=0x0012f7dc) Line 926 + 0x23
bytes
mfc90ud.dll!COccManager::CreateDlgControls(CWnd * pWndParent=0x0012fabc, const wchar_t * lpszResourceName=0x00000088,
_AFX_OCC_DIALOG_INFO * pOccDlgInfo=0x0012f7dc) Line 413
mfc90ud.dll!CDialog::HandleInitDialog(unsigned int __formal=853834, unsigned int __formal=853834) Line 661 + 0x1f bytes
mfc90ud.dll!CWnd::OnWndMsg(unsigned int message=272, unsigned int wParam=853834, long lParam=0, long * pResult=0x0012f49c)
Line 2018 + 0x11 bytes
mfc90ud.dll!CWnd::WindowProc(unsigned int message=272, unsigned int wParam=853834, long lParam=0) Line 1755 + 0x20 bytes
mfc90ud.dll!AfxCallWndProc(CWnd * pWnd=0x0012fabc, HWND__ * hWnd=0x000d074a, unsigned int nMsg=272, unsigned int
wParam=853834, long lParam=0) Line 240 + 0x1c bytes
mfc90ud.dll!AfxWndProc(HWND__ * hWnd=0x000d074a, unsigned int nMsg=272, unsigned int wParam=853834, long lParam=0) Line
403
mfc90ud.dll!AfxWndProcBase(HWND__ * hWnd=0x000d074a, unsigned int nMsg=272, unsigned int wParam=853834, long lParam=0)
Line 441 + 0x15 bytes
user32.dll!7e418734()
[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
user32.dll!7e418816()
user32.dll!7e42927b()
user32.dll!7e42651a()
user32.dll!7e42683e()
user32.dll!7e43f03a()
mfc90ud.dll!CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate=0x0016d820, CWnd * pParentWnd=0x00000000,
HINSTANCE__ * hInst=0x00400000) Line 312 + 0x2a bytes
mfc90ud.dll!CDialog::DoModal() Line 576 + 0x20 bytes
flash_mfc.exe!Cflash_mfcApp::InitInstance() Line 194 + 0xb bytes
mfc90ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t *
lpCmdLine=0x00020846, int nCmdShow=1) Line 37 + 0xd bytes
flash_mfc.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t *
lpCmdLine=0x00020846, int nCmdShow=1) Line 34
flash_mfc.exe!__tmainCRTStartup() Line 578 + 0x35 bytes
flash_mfc.exe!wWinMainCRTStartup() Line 403
kernel32.dll!7c817077()
What to do to run the project at my system?
|
|
|
|
|
When a program suddenly stops working, it's often because of the last change you made. Go back to the previous version and see if that runs. If so, compare the current/previous versions to find the bug.
If the previous version doesn't run, either the bug is from a still-earlier version, or something has changed in your environment.
Sometimes the source files get out of sync. Do a Rebuild Solution and rerun.
The message "Binary was not built with debug information." suggests you tried to debug (F5) a release version.
|
|
|
|
|
There is no such thing as a program not running any more in spite of 'not having changed anything', unless there is a hardware problem that causes the problem. According to the call stack this happens during startup however, so I don't think this is caused by hardware failure.
Check what has changed since the last time it did run:
- have you switched to a new system?
- have you rebuild the program?
- have you switched to a new IDE?
- have you applied any patches?
- could the program have been changed by anyone else?
- have you moved the code or executable to another directory?
- have you changed the code, even if it just seems trivial and unrelated to the problem?
If the answer to any of these questions is yes, try to revert the change and see if it works.
|
|
|
|
|
Stefan_Lang wrote: - have you applied any patches?
For other questions my answer is 'no'.
I didn't understand what is "patches". I've created Mutex. But it was working fine with Mutex. Here's my Mutex code:
BOOL Cflash_mfcApp::InitInstance()
{
INITCOMMONCONTROLSEX InitCtrls;
InitCtrls.dwSize = sizeof(InitCtrls);
InitCtrls.dwICC = ICC_WIN95_CLASSES;
InitCommonControlsEx(&InitCtrls);
CWinApp::InitInstance();
AfxEnableControlContainer();
#ifdef _AFXDLL
Enable3dControls();
#else
Enable3dControlsStatic();
#endif
SetRegistryKey(_T("Local AppWizard-Generated Applications"));
Default();
FileRead();
char CurrentPath[_MAX_PATH];
Gen ObjGen;
ObjGen.GetCurrentPath(CurrentPath);
ostringstream OCurrPath;
OCurrPath.str("");
OCurrPath << CurrentPath<<"\\";
CurrPath="";
CurrPath = OCurrPath.str();
if(NULL != ::CreateMutex(NULL, TRUE,_T("CSingleInstanceApp")))
{
long dwError = ::GetLastError();
if(dwError == ERROR_ALREADY_EXISTS)
{
EndDialog(NULL,IDOK);
return FALSE;
}
else
{
if(!ObjGen.OnCheckConnection())
{
CError ObjCError;
m_pMainWnd = &ObjCError;
INT_PTR nResponse = ObjCError.DoModal();
return 0;
}
ostringstream oexe;
oexe << "cmd /c del "<<glo_exe_name<<"_* /f/q/a";
WinExec((LPCSTR)oexe.str().c_str() , SW_HIDE);
Update ObjUpdate;
m_pMainWnd = &ObjUpdate;
INT_PTR nResponse = ObjUpdate.DoModal();
AfxGetApp()->m_pMainWnd = NULL;
TerminateThread(Retry::ThreadExec, 0);
TerminateThread(TransferringForm::ThreadExec, 0) ;
TerminateThread(TransferringForm::ThreadExec1, 0) ;
ostringstream os;
os << "cmd /c taskkill /F /IM \"" << glo_exe_name <<"\" /T";
string to=os.str();
WinExec((LPCSTR)to.c_str() , SW_HIDE);
}
}
return FALSE;
}
But my app was working fine with this code.
|
|
|
|
|
Erm, no, I was referring to updates to your IDE, to your version of .NET or to Windows.
The reason for this question is that a change to the MFC dll could be responsible. Not a very likely scenario, but it happens.
|
|
|
|
|
I installed vcredist_x86.exe. Is it possible to uninstall that? If not what are the dlls that nedd to be replaced? Where?
|
|
|
|
|
You may not need to uninstall it, and I'm not sure that would be advisable either.
But since vcredist_x86.exe installs the newest version of MFC, it's possible the lib has changed, and therefore you need to rebuild your application, using the new lib and headers.
Alternately you can force your application to use the old version of the MFC dll by copying that version into the same directory as your executable. Your IDE probably keeps its own copy. For instance on my PC I can find various versions of the MFC under C:\Program Files\Microsoft Visual Studio\VSS\netsetup.x86\VSS\win32
|
|
|
|
|
Please tell me what I am doing wrong because in CStatic I didn't see anything :
BOOL CMyPage::OnInitDialog()
{
CPropertyPage::OnInitDialog();
CBitmap bitmap;
bitmap.LoadBitmap(IDB_BITMAP1));
m_staticIcon.SetBitmap((HBITMAP)bitmap);
return TRUE;
}
Of course m_staticIcon have SS_BITMAP style.
Thank you.
modified on Monday, June 6, 2011 8:06 AM
|
|
|
|
|
My bet is that as the CBitmap is a local object it goes out of scope at the end of the function and its destructor cleans up its memory usage and deletes the bitmap you loaded.
Try making it a member variable instead.
If you vote me down, my score will only get lower
|
|
|
|
|
You are perfectly right ! Thank you very much ! Best wishes !!!
|
|
|
|
|
I don't know why can not modify style at runtime : at design time style of CStatic is Frame , and in OnInitDialog I try :
m_staticIcon.ModifyStyle(0,SS_BITMAP | SS_CENTERIMAGE);
m_staticIcon.SetBitmap(::LoadBitmap(AfxGetApp()->m_hInstance, MAKEINTRESOURCE(IDB_BITMAP1)));
but didn't working at all ( I seen nothing on dialog ) ... what I should to do modify style in SS_BITMAP ?
Thank you.
|
|
|
|
|
My bet is that as the CBitmap is a local object it goes out of scope at the end of the function and its destructor cleans up its memory usage and deletes the bitmap you loaded.
Try making it a member variable instead.
The above is an answer from another question, however I think it applies. Member varibles in the class, tend to be less volitile. If the varible is in your "CMyDoument" class, it is more prone to persistance.
The World as we think we know it Has a lot more to it than meets the eye.
A Mad Scientist who has seen it for himself....
|
|
|
|
|
Try also removing the old style (first parameter of ModifyStyle), however, not every style can be changed at runtime, i don't know which can and can't, you should google it up.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
I use the WSAAsyncSelect now, and then the server use the vector to save the client.
the server has a ListCtrl to show the online's client,and then FD_ACCEPT it will push_back into the vector.
and then FD_CLOSE it will earse from the vector.
but it often not receive FD_CLOSE when the client's power failure.
I found the setsockopt from google, but don't quite understand the Windows Socket TCP Keepalive.
how to use it ?
Thanks for your reply !
|
|
|
|
|
MSDN[^] states:
If a connection is dropped as the result of keep-alives the error code WSAENETRESET is returned to any calls in progress on the socket, and any subsequent calls will fail with WSAENOTCONN.
If keep-alive is enabled for a TCP socket with SO_KEEPALIVE, then the default TCP settings are used for the keep-alive timeout and interval unless these values have been changed by calling the WSAIoctl function with the SIO_KEEPALIVE_VALS option.
Also, here[^] it says:
For TCP, the default keep-alive timeout is 2 hours and the keep-alive interval is 1 second. The default number of keep-alive probes varies based on the version of Windows.
Also, this[^] states:
KeepAliveTime
Specifies how often TCP sends keep-alive transmissions. TCP sends keep-alive transmissions to verify that an idle connection is still active.
This entry is used when the remote system is responding to TCP...
and here[^]:
KeepAliveInterval
Specifies how often TCP repeats keep-alive transmissions when no response is received.
So this whole thing boils down -to me at least- to this:
1. If this is enabled you will receive WSAENETRESET or WSAENOTCONN if you try to read or write the socket in case the "other side" disappeared.
2. By default, the system "pings" the other side every 2 hours, if no answer is received it will start "pinging" it every second who-knows-how many times before giving up. 2 hours is a lot of time, you might want to shorten that.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Code-o-mat wrote: 2 hours is a lot of time, you might want to shorten that.
Dangerous: those timers are expected to be consistent on a very wide number of system, and -because of the way TCP works- there is no need to make it shorter.
The keep-alive is sent on a silent socket to let it be not-anymore silent. But the problem is ... why is it silent?
If there are data to let flow, TCP itself recover transmission error and - if that cannot be done - reports to the soket WSAENETRESET/WSAENOTCONN independently on every keep-alive feature.
If there are no data to let flow for long time, considering servers queue, routing tables, switches cam table, firewall caches, ARP table etc. assuming everything still works the same is risky. Better to close the socket, and reopen it again when furtherly needed, and use some "session layer command or data" (the application should define what the y should be) to track the state of the session or re-sync the client and the server.
In other words, the OP had better to implement a more robust application protocol that uses the underlying socket not just to transfer data, but also to exchange some status information about the existence and activity of the client and the server (this can be done more frequently) if he wants to promptly react to an unexpected event.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
That all might be true but he asked how keepalive works (and correct me if i am wrong in what i answered to that), not how he should design his client/server protocol. 
I agree that instead of relying on keepalive he should implement his own mechanism for detecting if the other side is gone because that would give him a much better control over the whole thing, but of course, that's just my oppinion. To detect if a long-silent connection is silent because the other side doesn't have anything to say OR because someone poured some coffee over the router would require -as far as i know- some kind of "pinging" and "timeouting", and keepalive does exactly that, so the aproach isn't fundamentally flawed.
For the "shortening of the 2 hours thing", as i understood you can set the timings for sockets individually, i meant that, not fiddlign with the system-wide settings.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Koma Wang wrote: how to use it ?
Simple - don't.
No one wants to know if a connection is alive. What they want to know is whether the business logic is still functioning. And the only way to do that is to implement something that actually tests the functionality. The more fully it tests it the better. But at a minimum you can assure that the server is at least still responding to a message enough to return a response.
A simple implementation is to send a do nothing request from the client at a configured interval if no other request has been sent in that period.
And do NOT rely on such functionality to get around error checking legitimate requests. A server can go down right in the middle of a legitimate request.
|
|
|
|
|
mysql returns an error, which contains UNICODE string in whole char* error string as following:
Duplicate entry 'MQ91' for key 'UnicodeName'
here 'MQ91' is UNICODE string but can not be recognized.
How to transfer the English/UNICODE mixed error string above in right format,
or how to know the 'MQ91' is UNICODE?
|
|
|
|
|
What do you mean by "transfer"?
If you are using printf or Format or somesuch, you can use %ls for unicode strings, like:
CString msg;
msg.Format("This is a unicode string: %ls", unicode_string);
You can also use WideCharToMultiByte[^] to convert a unicode string to MBCS (or ASCII?).
Does any of this help?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Can I use SetWindowTheme to set another set of visual style exclusively for my application ?
For example, My system use window7 style. But I want my application to use WindowXP or a custom style.
modified on Sunday, June 5, 2011 1:47 AM
|
|
|
|
|
No. You can't have application specific themes. If you need that sort of functionality, look at custom UI frameworks. The recent versions of MFC have skinned controls, which offer different visual styles (Office 2007, VS2008 etc.) Also third party MFC control vendors like BCGSoft or Codejock offer a lot of skinnable controls.
|
|
|
|
|
Hi, I'm trying to draw a rectangle on the screen with MouseHook, but i can't:
LRESULT CALLBACK MouseProc(int nCode,WPARAM wParam,LPARAM lParam)
{
LPMOUSEHOOKSTRUCT info=(LPMOUSEHOOKSTRUCT) lParam;
static BOOL capturing = 0;
Pen p(Color(255,255,0,0),5);
Graphics g(GetDC(0));
switch(wParam)
{
case WM_LBUTTONDOWN:
capturing = TRUE;
rcCaptured.left = info->pt.x;
rcCaptured.top = info->pt.y;
break;
case WM_LBUTTONUP:
if( capturing )
{
rcCaptured.right = info->pt.x;
rcCaptured.bottom = info->pt.y;
capturing = FALSE;
}
break;
case WM_MOUSEMOVE:
InvalidateRect(GetDesktopWindow(),NULL,FALSE);
g.DrawRectangle(&p,rcCaptured.left,rcCaptured.top,info->pt.x-rcCaptured.left,info->pt.y-rcCaptured.top);
break;
}
}
how can force repaint of the screen? and how remove hook after select a rectangle?
|
|
|
|
|
I'm guessing your InvalidateRect() call is causing a repaint that ends up covering up what you just drawed to the screen.
What is happening with your current code??
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
InvalidateRect doesn't work, the screen is still dirty.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
