Closed GoogleCodeExporter closed 9 years ago
Original comment by zexspect...@gmail.com
on 5 Jan 2012 at 8:28
BTW, I solved the different texts by following trick. I added following method
to extract different text based on the idx parameter:
CString Utility::GetINIString(LPCTSTR pszFile, LPCTSTR pszSection, LPCTSTR
pszName, UINT idx)
{
TCHAR szBuffer[2048] = _T("");
CString sTextRandom = _T("!@#$%^&*()jhqwhfs#@^%@!%^*(@#_)&(*&^%#@!)@#_)");
CString name;
name.Format(_T("%s_%d"), pszName, idx);
GetPrivateProfileString(pszSection, name, sTextRandom, szBuffer, 1024, pszFile);
if (sTextRandom == szBuffer)
// The indexed text was not found and has been initialized with the default value. Try the text field without the index.
GetPrivateProfileString(pszSection, pszName, sTextRandom, szBuffer, 1024, pszFile);
CString sResult = szBuffer;
sResult.Replace(_T("\\n"), _T("\n"));
return sResult;
}
Basically it will search for VariableName_idx first and if it does not find it,
then it looks for VariableName.
I then use the index to address the particular texts:
sHeading.Format(Utility::GetINIString(g_CrashInfo.m_sLangFileName, _T("MainDlg"), _T("HeaderText"), g_CrashInfo.m_nTextGroupID), g_CrashInfo.m_sAppName);
m_nTextGroupID is added to CRASH_DESCRIPTION and it is copied in
CCrashHandler::GenerateErrorReport() from CR_EXCEPTION_INFO. So by default the
index is set to 0, but when the user calls GenerateErrorReport(), he may opt to
override the index.
In the language file I then define multiple lines per dialog item:
HeaderText=%s has stopped working and will be closed.
HeaderText_1=%s has crashed internally and may not continue running reliably.
Save your work and restart the application.
HeaderText_2=User has triggered %s to generate manual crash report.
Thanks, Vojtech
Original comment by bubn...@gmail.com
on 5 Jan 2012 at 9:00
Not clear about your custom handler. What is this? As I imagine, there should
be the single centralized handler - CCrashHandler, so no custom handlers needed.
Not clear how you will determine when to close the app and when to continue its
execution. Can you clarify this?
Currently, CrashRpt has an ability to notify client app about crash through
crash callback. As I imagine it, CrashRpt should pass crash information to
crash callback function and the callback function will determine if to close
the app or not, based on crash information.
So, I need more information from you to better understand your needs.
Original comment by zexspect...@gmail.com
on 29 Aug 2012 at 7:32
Original comment by zexspect...@gmail.com
on 19 Sep 2012 at 4:21
I added a new-style crash callback replacing the obsolete LPGETLOGFILE()
callback.
Added PFNCRASHCALLBACK() callback function prototype, CR_CRASH_CALLBACK_INFO
structure and crAddCrashCallback() function.
Added an ability to continue program execution after crash. This can be
performed
through crash callback (see CR_CRASH_CALLBACK_INFO::bContinueExecution structure
member).
Hovewer, I did not implement changes related to different icon/text for
critical and non-critical errors. IMHO, it would be better if your application
display some dialog telling user about the crash and asking him/her to save the
work and exit the app.
Original comment by zexspect...@gmail.com
on 17 Oct 2012 at 3:57
This issue was closed by revision r1432.
Original comment by zexspect...@gmail.com
on 17 Oct 2012 at 3:58
Original issue reported on code.google.com by
bubn...@gmail.com
on 3 Jan 2012 at 12:04