C / C++ / MFC Discussion Boards

Hadi Dayvary1-Jul-09 5:16

1-Jul-09 5:16

My code is completly multithread,
As I said I have tested some other example (like the one in MSDN) and they have this problem too.

www.logicsims.ir

Re: MFC CSocket class!

led mike1-Jul-09 5:39

led mike

1-Jul-09 5:39

Ok, good luck.

Re: MFC CSocket class! [modified]

Moak18-Jul-09 4:36

Moak

18-Jul-09 4:36

Consider using CAsyncSocket if it has to be MFC based, do not use CSocket. Also see http://tangentsoft.net/wskfaq/articles/csocket.html[^] and for some more low-level background Beej's Guide to Network Programming[^]

/M

My webchat in Europe Java | [Coffee]

modified on Saturday, July 18, 2009 10:42 AM

Re: MFC CSocket class!

Hadi Dayvary18-Jul-09 5:14

Hadi Dayvary

18-Jul-09 5:14

Thank you so much

www.logicsims.ir

Change dialog bg-color?

bosfan1-Jul-09 3:35

bosfan

1-Jul-09 3:35

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

Re: Change dialog bg-color?

SandipG 1-Jul-09 4:15

SandipG

1-Jul-09 4:15

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.

Re: Change dialog bg-color? [modified]

bosfan1-Jul-09 4:35

bosfan

1-Jul-09 4:35

Ok thanks for answer!!! Smile | :)

But i have a question, when i use WM_CTLCOLOR new color ist set for all controls on dialog, e.g. CEdit CStatic CComboBox etc., but not for dialog it self??
I can't find why?? Frown | :(

Here is source code:

HBRUSH CMyDialog::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
	//*
	//** No need to do this!
	//**
	//** HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
	//*/
	//
	//*
	//** Return the white brush.
	//*/
	switch(nCtlColor)
	{
	case CTLCOLOR_BTN:
		Sleep( 10); //Button control
		break;
	case CTLCOLOR_DLG:
		Sleep(10); //Dialog box newer stop here? :(
	case CTLCOLOR_EDIT:
		Sleep(10); // Edit control
		break;
	case CTLCOLOR_LISTBOX:
		Sleep(10); // List-box control
		break;
	case CTLCOLOR_MSGBOX:
		Sleep(10);
		break; //Message box
	case CTLCOLOR_SCROLLBAR:
		Sleep(19); //Scroll-bar control
		break;
	case CTLCOLOR_STATIC:
		Sleep(10); //Static control
		break;
	}	

	
	return m_objMyBrush; // in dialog  defined CBrush
}

Any idea here Smile | :)

regards
termal

modified on Wednesday, July 1, 2009 11:34 AM

Re: Change dialog bg-color?

«_Superman_»1-Jul-09 16:46

«_Superman_»

1-Jul-09 16:46

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.

Re: Change dialog bg-color?

bosfan1-Jul-09 21:33

bosfan

1-Jul-09 21:33

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!! Frown | :(

// sometings like this??
if(nCtlColor == CTLCOLOR_DLG)
{
   return m_objMyBrush // my program run never here in :(
}
// else do nothing??
.
.
.

regards
termal

Logger class -> write to file too slow

Souldrift1-Jul-09 3:30

Souldrift

1-Jul-09 3:30

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. Smile | :)

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

Re: Logger class -> write to file too slow

Stuart Dootson1-Jul-09 3:34

Stuart Dootson

1-Jul-09 3:34

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

Re: Logger class -> write to file too slow

Cedric Moonen1-Jul-09 3:35

Cedric Moonen

1-Jul-09 3:35

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) ?

Cédric Moonen
Software developer

Charting control [v2.0]
OpenGL game tutorial in C++

Re: Logger class -> write to file too slow

Michael Schubert1-Jul-09 4:01

Michael Schubert

1-Jul-09 4:01

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.

Re: Logger class -> write to file too slow

David Crow1-Jul-09 4:52

David Crow

1-Jul-09 4:52

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

Re: Logger class -> write to file too slow

Joe Woodbury1-Jul-09 6:06

Joe Woodbury

1-Jul-09 6:06

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.

Re: Logger class -> write to file too slow

Chuck O'Toole1-Jul-09 10:31

Chuck O'Toole

1-Jul-09 10:31

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.

// Add a line of text to the Log
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();													// force single file to the log file
    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,	// open log file
			FILE_APPEND_DATA,		// open for writing
			FILE_SHARE_READ,		// allow multiple readers
			NULL,				// no security
			OPEN_ALWAYS,			// open or create
			FILE_ATTRIBUTE_NORMAL,	// normal file
			NULL);				// no attr. template
	if (hAppend != INVALID_HANDLE_VALUE)
	{
		SetFilePointer(hAppend, 0, NULL, FILE_END);
		WriteFile(hAppend, (LPCTSTR)t1, t1.GetLength(), &dwBytesWritten, NULL);
		CloseHandle(hAppend);
	}
	Unlock();												// OK, file is ready for the next guy
}

And it's created with:

TheLogFile = new Logger();
TheLogFile->SetFolder("Log\\");
TheLogFile->SetPrefix("UpdateProcess");

Re: Logger class -> write to file too slow

Souldrift1-Jul-09 21:54

Souldrift

1-Jul-09 21:54

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

Re: Logger class -> write to file too slow

Michael Schubert1-Jul-09 23:25

Michael Schubert

1-Jul-09 23:25

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.

how to detect Listctrl check box selection/deselection

hemlat1-Jul-09 1:22

hemlat

1-Jul-09 1:22

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.

Re: how to detect Listctrl check box selection/deselection

Jijo.Raj1-Jul-09 1:45

Jijo.Raj

1-Jul-09 1:45

Hello Hamlat,

You can use CListCtrl::GetCheck()[^]. Please have a look at this article[^].

Regards,
Jijo.

_____________________________________________________

http://weseetips.com[^] Visual C++ tips and tricks. Updated daily.

Re: how to detect Listctrl check box selection/deselection

hemlat1-Jul-09 2:04

hemlat

1-Jul-09 2:04

Thanks for your replay. But I need to get check box event selection message handler not whether check box is checked or not.

Re: how to detect Listctrl check box selection/deselection

Stuart Dootson1-Jul-09 2:40

Stuart Dootson

1-Jul-09 2:40

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

Re: how to detect Listctrl check box selection/deselection

hemlat1-Jul-09 3:08

hemlat

1-Jul-09 3:08

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.

Re: how to detect Listctrl check box selection/deselection

CPallini1-Jul-09 3:21

CPallini

1-Jul-09 3:21

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]

Re: how to detect Listctrl check box selection/deselection

hemlat1-Jul-09 20:46

hemlat

1-Jul-09 20:46

Thanks for your reply.I got it.

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.