C / C++ / MFC Discussion Boards

Niklas L6-Jul-11 21:11

6-Jul-11 21:11

You can read what the inventor of the language, Bjarne Stroustrup, thinks about this right here[^]. No-one can give you a better explanation than him.

Re: operator overloading problem.......

Stefan_Lang7-Jul-11 23:58

Stefan_Lang

7-Jul-11 23:58

Great link! The explanations are even better than those found in Stroustrup's 'The C++ Programming Language' (that's what I checked, I was especially curious about :? and am somewhat disappointed that there isn't even a good reason against overloading it. I could think of a good use or two...)

Re: operator overloading problem.......

Niklas L8-Jul-11 1:06

Niklas L

8-Jul-11 1:06

The entire page is a good resource.

In the next version of the standard I'm looking forward to see overloading of the new operators:

; - ) and : - P

Re: operator overloading problem.......

JanakiramanElumalai7-Jul-11 4:09

JanakiramanElumalai

7-Jul-11 4:09

The mentioned operators are used for only one purpose. Example in c++ the '.' operator used only for accessing member functions. (so there is no use of overloading '.' )
.

::

?:

But the symbols (+,- and etc..) are used to add numbers and objects .
Ex:
By default '+' operators are used for adding the numbers only and not the objects
(we are overloading the '+' operator to add the objects )

In c++ operator overloading takes the meaning as below
Operator Overloading: customize the operator to do other operations also(other than default operation).

clear?

What are the basic benefits of using mmioxxxx “file” functions as opposed to “plain “ MFC CFile?

Vaclav_6-Jul-11 13:34

Vaclav_

6-Jul-11 13:34

The documentation states the mmioxxxx provides for unbuffered and buffered files.
The CFile supports only unbuffered files.
I am sending the data retrieved by wave API ( from buffer) to the mmioxxxx file.
So do I need mmioxxxx or not?
I am "doing" MFC in VC++
Any contructive help will be as always appreciated.
Cheers
Vaclav

Re: What are the basic benefits of using mmioxxxx “file” functions as opposed to “plain “ MFC CFile?

Mark Salsbery6-Jul-11 13:43

Mark Salsbery

6-Jul-11 13:43

Vaclav_Sal wrote:
What are the basic benefits of using mmioxxxx “file” functions as opposed to “plain “ MFC CFile?

None.

THe mmioOpen docs also state "This function is deprecated. Applications should call CreateFile or CreateFileEx to create or open files. "

CreateFile or CreateFileEx are used in the windows implementations of most standard library and MFC file classes.

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: What are the basic benefits of using mmioxxxx “file” functions as opposed to “plain “ MFC CFile?

Vaclav_6-Jul-11 15:43

Vaclav_

6-Jul-11 15:43

Thanks again Mark.

Since I got my wave API going I 'll tackle this mmioxxx.
I do not remember but I think I done CFile before so it should not be much of a struggle this time.
I think I picked this mmioxxxx because the guy I copied it from build the wave file header and really did not explained why it was build that way. Most of the time when I use someone else program like that ( poorly documented) I get burned in the long run!
For example the stuff I used for wave hardly checks the functions returns. I think that is not very good programming style.

I think I need to read up on buffered and unbuffered files too.
Vaclav

IOCP again

csrss6-Jul-11 8:34

csrss

6-Jul-11 8:34

Hi guys. I am stuck again with IOCP again. The problem is that, i just cannot create more then one worker thread. If i'll create more then one worker thread, for example 10 and on the other side there are 10 client connections, everything crashes in a random places, or it crashes because buffer for WSARecv is not allocated while in debugger i can see perfectly allocated buffer, or it crashes because socket is invalid - i just dont get it. While it is only one thread - it is working perfectly, when there more threads, it becomes unstable, and when there are 10 or more, it crashes after 1 second. Is there some magic trick i am missing again?
Thanks

011011010110000101100011011010000110100101101110
0110010101110011

Re: IOCP again

cmk6-Jul-11 10:38

cmk

6-Jul-11 10:38

It sounds like there are more issue than can be easily solved via a forum post.
I'd suggest you look at some of the IOCP posts here.

In particular, Len Holgate wrote a good series:
A reusable, high performance, socket server class - Part 1[^]
A reusable, high performance, socket server class - Part 2[^]
A reusable, high performance, socket server class - Part 3[^]
Handling multiple pending socket read and write operations[^]

...cmk

The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack

Re: IOCP again

Mark Salsbery6-Jul-11 10:56

Mark Salsbery

6-Jul-11 10:56

Could only guess without seeing the code.

Some comments and random thoughts though...

The IOCP knows nothing about how many threads there are beyond how many are waiting on ::GetQueuedCompletionStatus().

There's no correlation between number of sockets (one for each client) associated with the IOCP and the number of worker threads. In fact, one thread per client is wrong and exactly what IOCPs are meant to eliminate.

So something is up in your code (obviously? Smile | :)

).

You can't share completion packets (OVERLAPPED structs) between sockets.
If the threads are accessing any common data objects then synchronization must be used.

For what it's worth, here's an example of an OVERLAPPED struct from one of my apps. Maybe it will spark something on your end...

Notes:
CClientConnection is a class that holds client information and also holds the socket handle and associated information.
pData is the I/O buffer, and is reallocated for each I/O operation. In my protocol I send a header of a known size first. That header has the number of following data bytes to expect.
dwDataLength and dwDataLengthProcessed are used tohandle situations where a single WSASend/WSARecv call doesn't process the total number of bytes requested. This MUST be done! There's no guarantee send and recv operations will send or receive all the bytes in one call. Successful completion could mean just a single byte!

// OVERLAPPEDOP_xxx used for overlapped IO

#define OVERLAPPEDOP_NOOP				0
#define OVERLAPPEDOP_SOCKACCEPT			1	// CompletionKey = SOCKET, pData  = 0
#define OVERLAPPEDOP_SOCKSEND			2	// CompletionKey = SOCKET, pData  = NETCOMMPACKET*
#define OVERLAPPEDOP_SOCKRECVHEADER		3	// CompletionKey = SOCKET, pData  = NETPACKETHEADER*
#define OVERLAPPEDOP_SOCKRECVPACKET		4	// CompletionKey = SOCKET, pData  = NETCOMMPACKET*
#define OVERLAPPEDOP_EXITTHREAD			5	// CompletionKey = 0

// MANAGEROP_xxx used for server manager thread operations

#define MANAGEROP_ADDCLIENTCONNECTION		1	// pData  = NEWUSERSOCKETINFO*
#define MANAGEROP_REMOVECLIENTCONNECTION	2	// lParam1 = CClientConnection*
#define MANAGEROP_REMOVEIOCPTHREAD			3	// lParam1 = CIOCPHandlerThread*
#define MANAGEROP_BROADCASTMESSAGE			4	// lParam1 = NETCOMMPACKETLITE* (alloc'd as BYTE*), lParam2 = CClientConnection* client to exclude

//-------------------------------------------------------------------------


#pragma pack( push, SRVRMGR_OVERLAPPEDpack, 1 )
//-------------------------------------------------------------------------
struct SRVRMGR_OVERLAPPED
//-------------------------------------------------------------------------
{
	OVERLAPPED Overlapped;

	DWORD dwOpCode;    // OVERLAPPEDOP_xxxx and MANAGEROP_xxxx codes defined above
	CClientConnection *pClientConnection;
	LPARAM	lParam1;
	LPARAM	lParam2;
	DWORD dwDataLength;
	DWORD dwDataLengthProcessed;
	BYTE *pData;

	SRVRMGR_OVERLAPPED()  {memset(this, 0, sizeof(SRVRMGR_OVERLAPPED));}
};
#pragma pack( pop, SRVRMGR_OVERLAPPEDpack)
typedef CTypedPtrList<CPtrList, SRVRMGR_OVERLAPPED*> SRVRMGR_OVERLAPPEDPtrList;

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: IOCP again

csrss6-Jul-11 11:11

csrss

6-Jul-11 11:11

Hey Mark. The worst thing is, i am sure that i am doing everything the exact same way but something is always wrong. I can give you the code only if i could send it to you - it is a solution with 5 projects and there are a LOT of lines, if you could take a look at it and point out mistakes i would appreciate it so much!!! (because i desperately need help with this Frown | :(

), can i ask you for this? please? My email: info[at]machinized[dot]com or maybe you can post yours, then i can send you the code. I am in pain Frown | :(

011011010110000101100011011010000110100101101110
0110010101110011

The code, in short

csrss6-Jul-11 11:58

csrss

6-Jul-11 11:58

Here is a code, in short:

1. Extended overlapped:

struct IOContext
{
	WSAOVERLAPPED	m_Overlapped;

	enum IOOperation
	{
		IOAccept, 
		IORead, 
		IOWrite, 
		IOConnect, 
		IODisconnect, 
		IODefault,
		IOTerminate,
		IOTerminateStopService
	};
// some more data here
//................
        IOOperation		m_IOOperation;
	IOSocket		* m_pSocket; // this is wrapper class for WSA functions
	LPBYTE			m_pbIoRecvBuffer;	// recv buffer
	DWORD			m_cbIoRecvBuffer;	// currently received bytes
	DWORD			m_sbIoRecvBuffer;	// bytes to receive

	LPBYTE			m_pbIoSendBuffer;	// send buffer
	DWORD			m_cbIoSendBuffer;	// currently sent bytes
	DWORD			m_sbIoSendBuffer;	// bytes to send

	bool GrowRecvBuffer();
	bool FlushRecvBuffer();

	bool GrowSendBuffer();
	bool FlushSendBuffer();
	bool AllocSendBuffer(DWORD dwSize);
}

bool IOContext::GrowRecvBuffer()
{
	m_sbIoRecvBuffer += 2048;
	m_pbIoRecvBuffer = (LPBYTE)::realloc(m_pbIoRecvBuffer, 
										 m_sbIoRecvBuffer);
	if(m_pbIoRecvBuffer == NULL)
	{
		return false;
	}
	return true;
}

bool IOContext::FlushRecvBuffer()
{
	m_sbIoRecvBuffer = 0;
	m_cbIoRecvBuffer = 0;
	if(m_pbIoRecvBuffer)
	{
		::free(m_pbIoRecvBuffer);
		m_pbIoRecvBuffer = NULL;
	}
	return true;
}

bool IOContext::GrowSendBuffer()
{
	return true;
}

bool IOContext::FlushSendBuffer()
{
	m_cbIoSendBuffer = 0;
	m_sbIoSendBuffer = 0;
	if(m_pbIoSendBuffer)
	{
		::free(m_pbIoSendBuffer);
		m_pbIoSendBuffer = NULL;
	}
	return true;
}

bool IOContext::AllocSendBuffer(DWORD dwSize)
{
	m_sbIoSendBuffer = dwSize;
	if(m_pbIoSendBuffer)
	{
		::free(m_pbIoSendBuffer);
		m_pbIoSendBuffer = NULL;
	}
	m_pbIoSendBuffer = new BYTE[m_sbIoSendBuffer];
	return m_pbIoSendBuffer ? true : false;
}

2. Creating a worker thread, bind listen are just regular. Next is accept function, which is called when FD_ACCEPT event occurs:

int myclass::StreamAccept()
{
	int WSAStatus = 0;
	DWORD dwFlags = 0;

	IOContext * pIoContextEx = new IOContext();

	try
	{
	::RtlSecureZeroMemory(pIoContextEx, sizeof(IOContext));

	// associate our listen socket with IO port
	if(m_bCorePortUpdated == false)
	{
		this->m_pCorePort->Update(m_pCoreSocket->Socket(), (ULONG_PTR)pIoContextEx);
		m_bCorePortUpdated = true;
	}

	// this will return accepted socket
	pIoContextEx->m_pSocket = m_pCoreSocket->WSAAccept(NULL, NULL);

	// associate new socket with completion port

	this->UpdateCorePort(pIoContextEx->m_pSocket, pIoContextEx);

	// set current IO operation
	pIoContextEx->m_IOOperation = pIoContextEx->IORead;

	// prepare recv buffer
	if(pIoContextEx->m_sbIoRecvBuffer <= pIoContextEx->m_cbIoRecvBuffer)
	{
		pIoContextEx->GrowRecvBuffer();
	}

	// post initial recv and transfer control to worker thread
	WSAStatus = pIoContextEx->m_pSocket->WSARecv(pIoContextEx->m_pbIoRecvBuffer, 
												 pIoContextEx->m_sbIoRecvBuffer, 
												 &pIoContextEx->m_dwBytesTransfered, 
												 &dwFlags, 
												 &pIoContextEx->m_Overlapped);
	}
	catch(Exception &ex)
	{
		::MessageBox(0, ex.ErrorString(), NULL, 0);
	}
	if(WSAStatus == SOCKET_ERROR && ::WSAGetLastError() != ERROR_IO_PENDING)
	{
		throw Exception(::WSAGetLastError(), TEXT(__FILE__), TEXT(__FUNCTION__), __LINE__);
	}
	return WSAStatus;
}

3. At this moment control goes to worker thread, which begins this way:

	IOComPort * pIOComPort = (IOComPort *)lpParam; // wrapper class for completion ports API

	IOContext * pIOContext = NULL;	// per socket context
	IOContext * pIOContextCasted = NULL;	// per call context

	LPWSAOVERLAPPED Overlapped = NULL;
	DWORD dwBytesTransfered = 0;

	try
	{
		while(true)
		{

			BOOL bRet = pIOComPort->GetQueuedCompletionStatus(&dwBytesTransfered,
															  (PULONG_PTR)&pIOContext,
															  (LPOVERLAPPED *)&Overlapped,
															  -1);
			pIOContextCasted = (IOContext *)Overlapped;

//.......................
// some parsing here, checking for NULL's and stuff, and there is a read event:

                                case pIOContextCasted->IORead:
					{
						pIOContextCasted->m_dwBytesTransfered = dwBytesTransfered;
						OnStreamRecved(pIOContextCasted, pIOComPort);
					}
				break;

5. Then we are going to OnStreamRecved.

int myclass::OnStreamRecved(IOContext * pIoContext, IOComPort * pIoComPort)
{
	DWORD dwLastError = ERROR_SUCCESS;
	int WSAStatus = 0;

	CGuiPrintf::Inst()->PrintfAppend(TEXT("Total bytes transfered: %d\r\n"), pIoContext->m_dwBytesTransfered);
	if(pIoContext->m_dwBytesTransfered != 0)
	{
		pIoContext->m_cbIoRecvBuffer += pIoContext->m_dwBytesTransfered;
	}
	if(!LastPacket(	pIoContext->m_pbIoRecvBuffer, 
					&pIoContext->m_cbIoRecvBuffer, 
					pIoContext->m_sbIoRecvBuffer))
	{
		CGuiPrintf::Inst()->PrintfAppend(TEXT("Need to fetch more data!\r\n"));
		DWORD dwFlags = 0;
		if(pIoContext->m_sbIoRecvBuffer <= pIoContext->m_cbIoRecvBuffer)
		{
			pIoContext->GrowRecvBuffer();
		}

		pIoContext->m_IOOperation = pIoContext->IORead;

		try
		{

			WSAStatus = pIoContext->m_pSocket->WSARecv(	pIoContext->m_pbIoRecvBuffer + pIoContext->m_cbIoRecvBuffer,
														pIoContext->m_sbIoRecvBuffer - pIoContext->m_cbIoRecvBuffer, 
														&pIoContext->m_dwBytesTransfered, 
														&dwFlags, 
														&pIoContext->m_Overlapped);
		}
		catch(Exception &ex)
		{
			CGuiPrintf::Inst()->PrintfAppend(TEXT("%s\r\n"), ex.ErrorString());
		}

		if(WSAStatus == SOCKET_ERROR && ::WSAGetLastError() != WSA_IO_PENDING)
		{
			return OnStreamDefault(pIoContext, pIoComPort);
		}
		return WSAStatus;
	}

	if(m_bLogTransmition)
	{
		CGuiPrintf::Inst()->PrintfAppend(
			TEXT("CLIENT [%s : %d] SENT THIS: %s\r\n"),
			::inet_ntoa(pIoContext->m_remote), pIoContext->m_port_remote,
			(char *)pIoContext->m_pbIoRecvBuffer);
	}

	// now we are going to send something to a client, something that will 
	// indicate we have recved data, first we set up current IO operation

	::RtlSecureZeroMemory(&pIoContext->m_Overlapped, sizeof(pIoContext->m_Overlapped));
	pIoContext->m_IOOperation = pIoContext->IOWrite;

	// next we prepare some data to send

	BYTE bRes[] = " - server recieved.";
	DWORD dwRespSize = pIoContext->m_cbIoRecvBuffer + sizeof(bRes) + 1;

	pIoContext->AllocSendBuffer(dwRespSize);

	::RtlCopyMemory(pIoContext->m_pbIoSendBuffer, 
					pIoContext->m_pbIoRecvBuffer,
					pIoContext->m_cbIoRecvBuffer);

	::RtlCopyMemory(pIoContext->m_pbIoSendBuffer + pIoContext->m_cbIoRecvBuffer,
					bRes,
					sizeof(bRes));

	// now we send it all

	try
	{

		WSAStatus = pIoContext->m_pSocket->WSASend(pIoContext->m_pbIoSendBuffer, 
												   pIoContext->m_sbIoSendBuffer,
												   &pIoContext->m_dwBytesTransfered,
												   0,
												   &pIoContext->m_Overlapped);
	}
	catch(Exception &ex)
	{
		CGuiPrintf::Inst()->PrintfAppend(TEXT("%s\r\n"), ex.ErrorString());
	}

	pIoContext->FlushRecvBuffer();

	if(WSAStatus == SOCKET_ERROR && ::WSAGetLastError() != ERROR_IO_PENDING)
	{
		return OnStreamDefault(pIoContext, pIoComPort); // clean up client
	}

	return WSAStatus;
}

And in this above function everything crashes, while it tries to allocate recv buffer, it returns some 0xfefefe value, sometimes NULL, some strange things anyway Frown | :(

I am creating 100 worker (server) threads and 100 clients connections, client send simple text string to a server and server responds with another text string. But in this above function it crashes while trying to allocate some memory. I am just giving up...

011011010110000101100011011010000110100101101110
0110010101110011

Re: The code, in short

Mark Salsbery6-Jul-11 13:21

Mark Salsbery

6-Jul-11 13:21

Before I look any further than the I/O buffer code...

It looks like you have a mix of ::free() and "new" calls for allocation operations. Those can't be mixed. In c++ I would just use new/delete and forget the realloc stuff, but you're free to use the c library functions if you prefer, but you can't mix in new/delete!

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Re: The code, in short

csrss6-Jul-11 14:53

csrss

6-Jul-11 14:53

Thats basically doesnt matter, you can mix it. What you cannot is HeapAlloc and free or malloc and HeapFree for example. It seems to me that its kind of not possible to have memory allocations with IOCP. No matter what i do, app always crashes randomly. And there is always heap corruption. If there is static buffer - 1000 connections without a problem, if there is dynamic memory allocation - even one connection crashes.

011011010110000101100011011010000110100101101110
0110010101110011

Re: The code, in short

Mark Salsbery6-Jul-11 15:22

Mark Salsbery

6-Jul-11 15:22

csrss wrote:
Thats basically doesnt matter, you can mix it.

What??? "Basically", it does matter. In practice, however, it may not matter... at least maybe currently. It's a horrible programming practice to mix memory allocation function families. There is absolutely NO guarantee that any given library implementation versions will remain compatible. But if you like to live dangerously... Smile | :)

csrss wrote:
It seems to me that its kind of not possible to have memory allocations with IOCP

IOCP doesn't know anything about memory allocations or your buffers or anything. You are responsible for that and all standard multithread rules apply.

Regardless of all that, it should be relatively easy to debug. Your heap is getting trashed. Running in debugger when it crashes you should be able to go to any thread and check call stacks to see where it's failing.

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Dynamic Tree

john56326-Jul-11 1:28

john5632

6-Jul-11 1:28

Hi Experts,

I need your help to solve a problem. Problem is to create a dynamic tree in memory.

I have a node with 2 field 1. Self Record Number and 2. Parent Record Number
I need to create a hierarchy (Tree) based on above information. Any node can come in any sequence. There is no rule defined for hirerchy.

How to set the node at run time so that I can create a correct child-parent hierarchy?

Re: Dynamic Tree

Emilio Garavaglia6-Jul-11 2:19

Emilio Garavaglia

6-Jul-11 2:19

The "parent" should point to the parent and the "self" should point to the sibling.
But it is a very poor implementation, difficult to walk and maintain (who are the children of a given parent? you should keep a list of the "world" to scan!).

Hierarchies normally requires more pointers:
- to the parent
- to the first child (and eventually to the last)
- to the next sibling (and eventually the previous)

2 bugs found.
> recompile ...
65534 bugs found.
D'Oh! | :doh:

Re: Dynamic Tree

Niklas L6-Jul-11 4:47

Niklas L

6-Jul-11 4:47

john5632 wrote:
I have a node with 2 field 1. Self Record Number and 2. Parent Record Number

You can add your nodes to a vector, a linked list or a map. Then by definition you already have a tree, as long as you keep the constraint of not adding any loops, and keeping a single root node.

It all depends on what you want to do with it in the end. If you need fast look-up, then look at Emilios suggestion above. Otherwise, go simple.

How to retrieve Icon/Bitmap/HBITMAP information from CMenu? [modified]

nate316-Jul-11 0:30

nate31

6-Jul-11 0:30

Hi all, I need to retrieve image information from an CMenu item, below is my code, but exception occurs at last line when I call GetHBITMAP().

I suspect the dwItemData I retrieved is NOT a Bitmap*.

I suspect the menu I am working on is build with MFT_OWNERDRAW option.

// get the menu item icon
MENUITEMINFO mii;
mii.cbSize = sizeof(MENUITEMINFO);
mii.fMask = MIIM_FTYPE;
mii.fType = MFT_OWNERDRAW;
pMenu->GetMenuItemInfo(i, &mii, TRUE/*1st param = item position*/);

HBITMAP hbm = NULL;
Gdiplus::Bitmap* pMI = (Gdiplus::Bitmap*)mii.dwItemData;

Gdiplus::Status status = pMI->GetHBITMAP(Gdiplus::Color(0, 255, 255, 255), &hbm);

Thanks in advance!

modified on Wednesday, July 6, 2011 9:50 PM

Re: How to retrieve Icon/Bitmap/HBITMAP information from CMenu?

Richard MacCutchan6-Jul-11 0:37

Richard MacCutchan

6-Jul-11 0:37

I don't see a call to GetMenuItemInfo()[^], so the contents of dwItemData will not be valid.

The best things in life are not things.

Re: How to retrieve Icon/Bitmap/HBITMAP information from CMenu?

nate316-Jul-11 15:52

nate31

6-Jul-11 15:52

Sorry I removed that line with some other comments after pasting here. Added already. In the actual code I did call GetMenuItemInfo(), thanks!

Re: How to retrieve Icon/Bitmap/HBITMAP information from CMenu?

David Crow6-Jul-11 3:52

David Crow

6-Jul-11 3:52

nate31 wrote:
Gdiplus::Bitmap* pMI = (Gdiplus::Bitmap*)mii.dwItemData;

Since dwItemData has not been initialized, what value do you suppose pMI has?

"One man's wage rise is another man's price increase." - Harold Wilson

"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

"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather

Re: How to retrieve Icon/Bitmap/HBITMAP information from CMenu?

nate316-Jul-11 15:53

nate31

6-Jul-11 15:53

Can you point out what I should do here? Thanks!

Re: How to retrieve Icon/Bitmap/HBITMAP information from CMenu?

David Crow6-Jul-11 16:55

David Crow

6-Jul-11 16:55

Start with something like:

MENUITEMINFO mii = {0};
mii.cbSize = sizeof(MENUITEMINFO);
mii.fMask = MIIM_FTYPE; 
mii.fType = MFT_OWNERDRAW;
if (pMenu->GetMenuItemInfo(i, &mii, TRUE /*1st param = item position*/))
{
    Gdiplus::Bitmap *pMI = (Gdiplus::Bitmap *) mii.dwItemData;
    if (pMI != NULL)
    {
        HBITMAP hbm = NULL;
        Gdiplus::Status status = pMI->GetHBITMAP(Gdiplus::Color(0, 255, 255, 255), &hbm);
        if (status == Status::Ok)
            ;
    }
    else
        ASSERT(FALSE);
}
else
    dwError = GetLastError();

At CADORecordset.Close() Application get crashed.

Amrit Agr5-Jul-11 23:16

Amrit Agr

5-Jul-11 23:16

Hi developers,
I am using a wrapper class (Taken from Codeproject), in which ADO connectivity has been used,

CADORecordset rsAccessMedia(&theApp.m_pDbHompath);

CString strQuery;
strQuery.Format( _T("select * from %s where ID = %d"), m_strTable, lngcurrItemID );
rsAccessMedia.Open( strQuery, CADORecordset::openQuery );

bool bIsOK = true;
if(rsAccessMedia.IsEOF()) //If Record not found for the selected( draaged ) media
bIsOK = false;

rsAccessMedia.Close();

At the last line application getting crashed. Connection is proper, but I don't know why it is being crashed.

Pls help me out.

Thanks.

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