|
Hello,
i found many responses for this issue, but i like to use this function:
SetDialogBkColor();
in :
BOOL CMyDialogApp::InitInstance()
but this don't take any changes, is this obsolete in VS 8, i my projects with VS6 this works fine??
About my project: is tabbed with many child dialogs, each tab have his own CDialog.
Is this possible to solve with this function above?
thanks for any help!
termal
|
|
|
|
|
termal wrote: is this obsolete in VS 8
read here[^]
This page clearly states
CWinApp::SetDialogBkColor
This function is obsolete.
Remarks
To set the background color of the dialog box, you must handle WM_CTLCOLOR. This message changes the color of the specified dialog box only.
Regards,
Sandip.
|
|
|
|
|
|
You're returning the handle to the brush for all the controls. That is why all controls change color.
You must return the required brush handle only for CTLCOLOR_DLG.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
