|
Hi,
thanks for answer, but how to give a return only for dialog??
Can you show me a code-snippet??
In my case CTLCOLOR_DLG is never there!!
if(nCtlColor == CTLCOLOR_DLG)
{
return m_objMyBrush
}
.
.
.
regards
termal
|
|
|
|
|
Hi there,
I built a logger class to trace and debug my programs.
Now I have very real-time dependent programs here and the problem is, when I activate the logger´s 'log to file'-option the program gets too slow to be run properly. But I want/need the logger to be active in normal operation, as well ... so that I can have a look at the output if something went wrong (like a crash).
The time stealer seems to be the opening and closing of the file for every log entry. But I cannot simply open it once and never close it, because the log entrys are only put into the file with the close() call.
This is the logger (which works otherwise fine). Any help with speeding it up, restructuring it or whatever needs to be done is appreciated.
Logger::Logger(void)
{
m_iLogLevel = DEBUG;
m_bToConsole = true;
m_bToFile = false;
m_sFilename = "tts_dump.out";
m_sPath = "./";
m_bFirstWriteToFile = true;
}
Logger::~Logger(void)
{}
Logger* Logger::GetInstance()
{
if( m_pLogger == NULL )
{
m_pLogger = new Logger();
}
return m_pLogger;
}
void Logger::Out( int level, const char* pcszFormat, ... )
{
va_list ap;
va_start( ap, pcszFormat );
if( m_bToConsole )
{
if( pcszFormat && level <= m_iLogLevel )
{
vprintf( pcszFormat, ap );
}
}
if( m_bToFile )
{
if( pcszFormat && level <= m_iLogLevel )
{
string loc = m_sPath;
loc.append( m_sFilename );
if( m_bFirstWriteToFile )
{
m_oFile.open(loc.c_str(), ios::out);
m_bFirstWriteToFile = false;
}
else
{
m_oFile.open(loc.c_str(), ios::out|ios::app);
}
if( !m_oFile )
{
cerr << loc << " kann nicht geöffnet werden!\n";
}
char buffer[1024];
vsprintf_s( buffer, pcszFormat, ap );
m_oFile << buffer;
m_oFile.close();
}
}
va_end( ap );
}
void Logger::SetLogLevel( int level )
{
if( level >= 0 && level <= SYS_ERROR )
m_iLogLevel = level;
}
void Logger::SetConsoleOutput( bool on )
{
m_bToConsole = on;
}
void Logger::SetFileOutput( bool on, string filename, string path )
{
m_bToFile = on;
}
Cheers
Souldrift
|
|
|
|
|
I'd suggest rewriting it so that you don't need to close it to write items to the file - you've identified opening the file as the hotspot, so remove the sdcenario that means you have to open it so often. The std::basic_ostream::flush()[^] method could prove useful, to ensure the message is actually pushed to disk.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Souldrift wrote: The time stealer seems to be the opening and closing of the file for every log entry. But I cannot simply open it once and never close it, because the log entrys are only put into the file with the close() call.
Even when you flush the data to the file (calling the flush method) ?
|
|
|
|
|
Create a buffer in memory, for example a string array, collect your data in this array for a certain amount of time (or a certain number of entries) and then write the contents to the file in one go.
|
|
|
|
|
File I/O, especially opening, is very expensive. You may want to implement it in a separate thread so that the primary thread can run unimpeded.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Get rid of buffered I/O calls.
Use either purely native calls (CreateFile()) or at least the CRT open function.
If that's still too slow, using asynchronous writes (yes, they are tricky, but they do work.) Do understand that you may need a mechanism to throw away messages else you're logging could get permanently behind.
An alternative is to write log string to a buffer and when it passes 4k, do an asynchronous write.
|
|
|
|
|
The bad news is that if you are using a Logger Class to dump output somewhere in case your program crashes, then Open / Append / Close is the only way to make sure that critical "trace" messages are not left in memory at the crash. All the other suggestions, buffering, asynch I/O, can improve the speed at the expense of the exact reason to have a logger for debug tracing.
Bite the bullet and live with the slower code. Here's what I use which includes a timestamp in the output, modify it as you see fit. Also, since this is in a class derived from a synchornized object (which has a Lock/Unlock function), this is threadsafe.
void Logger::LogThis(CString Text)
{
SYSTEMTIME cur_time;
CString t1;
CString t2;
DWORD dwBytesWritten;
if (Folder.IsEmpty() || Prefix.IsEmpty())
{
TRACE("Log Location Not Set");
return;
}
Lock();
GetLocalTime(&cur_time);
t1.Format("%02d-%02d-%04d %02d:%02d:%02d : %.200s\r\n",
cur_time.wMonth, cur_time.wDay, cur_time.wYear,
cur_time.wHour, cur_time.wMinute, cur_time.wSecond, Text);
t2.Format("%s%s%04d%02d%02d.log", Folder, Prefix, cur_time.wYear, cur_time.wMonth, cur_time.wDay);
HANDLE hAppend = CreateFile(t2,
FILE_APPEND_DATA,
FILE_SHARE_READ,
NULL,
OPEN_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL);
if (hAppend != INVALID_HANDLE_VALUE)
{
SetFilePointer(hAppend, 0, NULL, FILE_END);
WriteFile(hAppend, (LPCTSTR)t1, t1.GetLength(), &dwBytesWritten, NULL);
CloseHandle(hAppend);
}
Unlock();
}
And it's created with:
TheLogFile = new Logger();
TheLogFile->SetFolder("Log\\");
TheLogFile->SetPrefix("UpdateProcess");
|
|
|
|
|
Thanks for all the answers (and the code).
I came up with the buffering idea, as well - and I´m using it now. I only buffer 10 messages, then write. Seems to be enough to get rid of my real-time problems. Problem is I cannot simply 'bite the bullet', since the project is about audio streaming. And the stream is very corrupted when the logger opens a file every time. I also already built a locking mechanism.
Now I´ll see about flushing the stream. If it doesn´t work I´ll have to live with the small buffer ... for now.
Btw, are CreateFile() and WriteFile() significantly different from what I do? Ofstream open() and '<<' ?
Thanks
Souldrift
|
|
|
|
|
Souldrift wrote: Btw, are CreateFile() and WriteFile() significantly different from what I do? Ofstream open() and '<<' ?
Using CreateFile() gives you all the control (Performance/Sharing/Security) the Win32 API has to offer.
|
|
|
|
|
Hi,
In my application I have created Listctrl on dialog with check box option.I need to handle check box selection or deselection events.Can anyone tell me which message handle I need to take.
Regards,
Rekha.
|
|
|
|
|
|
Thanks for your replay. But I need to get check box event selection message handler not whether check box is checked or not.
|
|
|
|
|
hemlat wrote: Thanks for your replay. But I need to get check box event selection message handler not whether check box is checked or not.
Doesn't matter whether you need it or not - Microsoft don't provide that.
What you do have is LVN_ITEMCHANGING[^] and LVN_ITEMCHANGED[^], which are sent when an item changes in any way - it's up to you to determine if that's because a check box has changed from checked to unchecked or unchecked to checked.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hi,
I have used both LVN_ITEMCHANGING and LVN_ITEMCHANGED . But these these are sent not only for check box selection but also for another events like adding items to Listctrl.
I have searched for this requirement but I did not get required result. I am not sure whether Microsoft provide this or not. I am new to MFC.
Thanks for your reply. I think I need to change logic of my code dependence on existing event handlers.
|
|
|
|
|
hemlat wrote: I have used both LVN_ITEMCHANGING and LVN_ITEMCHANGED . But these these are sent not only for check box selection but also for another events like adding items to Listctrl.
From MSDN [^]
Parameters
pnmv
Pointer to an NMLISTVIEW structure that identifies the item and specifies which of its attributes are changing.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks for your reply.I got it.
|
|
|
|
|
hemlat wrote: I have used both LVN_ITEMCHANGING and LVN_ITEMCHANGED . But these these are sent not only for check box selection but also for another events like adding items to Listctrl.
That's right. So you (YOU) need to add code to those handlers to determine whether or not an items check state has changed. Here's a hint - the checkbox is implemented as an state image overlay - look up LVIS_STATEIMAGEMASK in the list-view item state flags.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thanks for your reply. I got it.
|
|
|
|
|
Hi
I am a new comer in C++. I have an MFC application that using some header files and libraries. I set the 'additional library directories' and 'additional include directories' in project settings. But whenever I want to make an instance of one of those classes I get this error:
error C2259: cannot instantiate abstract class due to the following members: ....
It is wierd as it works in another project same as this one, and there are some other classes in the lib files as this class, but the error doesn't occur in those conditions.
I know the concept of abstract class. Please help me in advanse.
Thanks
|
|
|
|
|
Well, something must be different between your new application and the older ones - otherwise the error wouldn't occur. You need to identify what's different. Start with the error messages. What methods are they telling you aren't implemented? That tells you what to look for in the older projects where those things do work.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
|
hi all,
I m creating a Win32 smart device project. and using this code for message sending but i have got debug assertion failed in file atlcomcli.h at line 149 and 154.
HRESULT GetSMSMsgStore(const CComPtr<IMAPISession>& spSession, CComPtr<IMsgStore>& spMsgStore)
{
CComPtr<IMAPITable> spTable;
HRESULT hr = spSession->GetMsgStoresTable(MAPI_UNICODE, &spTable);
if (FAILED(hr))
{
AfxMessageBox(IDS_SMS_FAIL_MSGSTORE_TABLES);
return FALSE;
}
while (TRUE)
{
SRowSet* pRowSet = NULL;
hr = spTable->QueryRows(1, 0, &pRowSet);
if (FAILED(hr))
{
AfxMessageBox(IDS_SMS_FAILEDTABLE);
break;
}
if (pRowSet->cRows == 1)
{
ASSERT(pRowSet->aRow[0].lpProps->ulPropTag == PR_ENTRYID);
SBinary& blob = pRowSet->aRow[0].lpProps->Value.bin;
hr = spSession->OpenMsgStore(NULL, blob.cb, (LPENTRYID)blob.lpb, NULL, 0, &spMsgStore);
if (FAILED(hr))
AfxMessageBox(IDS_SMS_FAILED_OPENMSGSTORE);
}
else
{
AfxMessageBox(IDS_SMS_MSGSTORENOTFOUND);
hr = HRESULT_FROM_WIN32(ERROR_NOT_FOUND);
}
FreeProws(pRowSet);
if (FAILED(hr))
{
break;
}
SPropTagArray props;
props.cValues = 1;
props.aulPropTag[0] = PR_DISPLAY_NAME;
ULONG cValues;
SPropValue* pProps = NULL;
hr = spMsgStore->GetProps(&props, MAPI_UNICODE, &cValues, &pProps);
if (FAILED(hr) || cValues != 1)
{
AfxMessageBox(IDS_SMS_FAILED_GETNAME);
break;
}
if (_tcsicmp(pProps[0].Value.lpszW, _T("SMS")) == 0)
{
break;
}
}
if (FAILED(hr))
{
spMsgStore.Release();
}
return hr;
}
HRESULT GetSMSFolder(const CComPtr<IMsgStore>& spMsgStore, CComPtr<IMAPIFolder>& spFolder)
{
SPropTagArray propDefaultFolder;
propDefaultFolder.cValues = 1;
propDefaultFolder.aulPropTag[0] = PR_CE_IPM_DRAFTS_ENTRYID;
ULONG cValues;
LPSPropValue pPropVals;
HRESULT hr = spMsgStore->GetProps (&propDefaultFolder, MAPI_UNICODE, &cValues, &pPropVals);
if (FAILED(hr))
{
AfxMessageBox(IDS_SMS_FOLDERNOTFOUND);
return hr;
}
SBinary& eidDrafts = pPropVals->Value.bin;
hr = spMsgStore->OpenEntry(eidDrafts.cb, (LPENTRYID)eidDrafts.lpb, NULL, MAPI_MODIFY, NULL, (LPUNKNOWN*)&spFolder);
if (FAILED(hr))
{
AfxMessageBox(IDS_SMS_FOLDERNOTOPENED);
}
return hr;
}
HRESULT SendSMSMessage(const CComPtr<IMAPISession>& spSession, LPCTSTR lpszFrom, LPCTSTR lpszTo, LPCTSTR lpszMessage)
{
CComPtr<IMsgStore> spMsgStore;
HRESULT hr = GetSMSMsgStore(spSession, spMsgStore);
if (FAILED(hr))
{
return hr;
}
CComPtr<IMAPIFolder> spFolder;
hr = GetSMSFolder(spMsgStore, spFolder);
if (FAILED(hr))
{
return hr;
}
CComPtr<IMessage> spMessage;
hr = spFolder->CreateMessage(NULL, 0 ,&spMessage);
if (FAILED(hr))
{
AfxMessageBox(IDS_SMS_FAIL_CREATEMESSAGE);
return hr;
}
SPropValue propRecipient[3];
ZeroMemory(&propRecipient, sizeof(propRecipient));
propRecipient[0].ulPropTag = PR_RECIPIENT_TYPE;
propRecipient[0].Value.l = MAPI_TO;
propRecipient[1].ulPropTag = PR_ADDRTYPE;
propRecipient[1].Value.lpszW = _T("SMS");
propRecipient[2].ulPropTag = PR_EMAIL_ADDRESS;
propRecipient[2].Value.lpszW = (LPWSTR)lpszTo;
ADRLIST adrlist;
adrlist.cEntries = 1;
adrlist.aEntries[0].cValues = 3;
adrlist.aEntries[0].rgPropVals = (LPSPropValue)(&propRecipient);
hr = spMessage->ModifyRecipients(MODRECIP_ADD, &adrlist);
if (FAILED(hr))
{
AfxMessageBox(IDS_SMS_FAILED_ADDRECIPIENTS);
return hr;
}
else
;
SPropValue props[4];
ZeroMemory(&props, sizeof(props));
props[0].ulPropTag = PR_SUBJECT;
props[0].Value.lpszW = (LPWSTR)lpszMessage;
props[1].ulPropTag = PR_SENDER_EMAIL_ADDRESS;
props[1].Value.lpszW = (LPWSTR)lpszFrom;
props[2].ulPropTag = PR_MSG_STATUS;
props[2].Value.ul = MSGSTATUS_RECTYPE_SMS;
props[3].ulPropTag = PR_MESSAGE_FLAGS;
props[3].Value.ul = MSGFLAG_FROMME | MSGFLAG_UNSENT;
hr = spMessage->SetProps(sizeof(props) / sizeof(props[0]), (LPSPropValue)&props, NULL);
if (FAILED(hr))
{
AfxMessageBox(IDS_SMS_FAIL_SETPROPS);
return hr;
}
hr = spMessage->SubmitMessage(0);
if (FAILED(hr))
{
AfxMessageBox(IDS_SMS_FAIL_SUBMITMSG);
return hr;
}
return FALSE;
}
i m not able to debug because this error comes in Pocket pc emulator.
if i retry the message send successfully.
please help me to remove thease errors.
thanks in advance.
To accomplish great things, we must not only act, but also dream;
not only plan, but also believe.
|
|
|
|
|
but where in your ocde are the asserts happening. It can be that the objects arent ready to work.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
its comes here
hr = spSession->OpenMsgStore(NULL, blob.cb, (LPENTRYID)blob.lpb, NULL, 0, &spMsgStore);
To accomplish great things, we must not only act, but also dream;
not only plan, but also believe.
|
|
|
|
|