C / C++ / MFC

Avoiding Resource Conflicts in MFC Extension DLLs

8-Aug-10 5:31

A statement of the form:

LPHWAVEOUT		_hOutputDevice = NULL;

states that _hOutputDevice is a pointer to a HWAVEOUT (whatever that may be). However, you have also initialised it to the value NULL which means that it is not pointing to anything. If you then pass that as the function parameter then the function will reject it as part of the response is to return some data in the memory that is pointed to. Since the value is NULL the function cannot store the response.

It is much better practice to do something like:

HWAVEOUT		_hOutputDevice;
function(&_hOutputDevice, ...

It's time for a new signature.

softwaremonkey7-Aug-10 21:07

softwaremonkey

7-Aug-10 21:07

Hi,

Over the years I have written a number of MFC extension DLLs which, amongst other things, contain resources (mainly dialogs) which can be accessed from the main app as well as from code within the DLL itself.

Occasionally I ran into problems of the resource ID's clashing with those of the main app, and to avoid this, I have always tried to allocate resource IDs in different ranges in each DLL. This has worked OK but it is getting increasingly difficult to manage and I thought that there must be a more elegant way to ensure that you can access the correct resource.

Any suggestions? Unsure | :~

Re: Avoiding Resource Conflicts in MFC Extension DLLs

Niklas L7-Aug-10 22:27

Niklas L

7-Aug-10 22:27

I've been using AfxSetResourceHandle() for that. Call once before accessing a resource, and use it afterwards to reset the handle. Of course you will have to know what dll contains your resource. Depending on your architecture, this can be really simple, or close to impossible Poke tongue | ;-P

On way to solve some of these problems is to have factory functions exported from the dll for creating dialogs and such.

Inside each dll this is not a problem if you are using the AFXMANAGESTATE (?) macro which I assume you are doing, and you are not accessing resources in other dll's.

home

Re: Avoiding Resource Conflicts in MFC Extension DLLs

softwaremonkey8-Aug-10 4:21

softwaremonkey

8-Aug-10 4:21

Hi Niklas,

Thanks for the reply. I do need to invoke the dialogs contained in my DLL from the main application but your suggestion of using a factory function is a great idea and should do the trick.

Thanks for your help Thumbs Up | :thumbsup:

Tony

Error :: C1061 compiler limit : blocks nested too deeply

Le@rner6-Aug-10 22:31

Le@rner

6-Aug-10 22:31

Hi all,

in my program this error C1061 compiler limit : blocks nested too deeply comes,i m using number of if else,please tell me how can i resolve this,

thanks in advance.

Re: Error :: C1061 compiler limit : blocks nested too deeply

Code-o-mat6-Aug-10 22:52

Code-o-mat

6-Aug-10 22:52

Without seeing your code it is hard to tell, genericly you can either try to re-structure the whole thing, or divide it into multiple functions, or, if everything else fails, -oh my i hope no lightning will strike me now *ducks and covers*- use goto, but as said, without seeing actual code, it is hard to say...

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Re: Error :: C1061 compiler limit : blocks nested too deeply

Le@rner6-Aug-10 23:23

Le@rner

6-Aug-10 23:23

I have a TreeCtrl,with number of Tree items.

get currently selected tree item and perform function on it respectively.

CString Tree_str;
BOOL flag;

if(Tree_str==_T("Item 1"))
{
  if(flag==TRUE)
  {
     //do dome work
  }
  else if(flag==FALSE)
  {
     //do dome work
  }
}

else if(Tree_str==_T("Item 2"))
{
  if(flag==TRUE)
  {
     //do dome work
  }
  else if(flag==FALSE)
  {
     //do dome work
  }
}

.
.
.
.

else if(Tree_str==_T("Item 140"))
{
  if(flag==TRUE)
  {
     //do dome work
  }
  else if(flag==FALSE)
  {
     //do dome work
  }
}

Re: Error :: C1061 compiler limit : blocks nested too deeply [modified]

Richard MacCutchan7-Aug-10 2:39

Re: Error :: C1061 compiler limit : blocks nested too deeply

7-Aug-10 2:39

This is nowhere near deep enough to generate that message, I suspect something else is wrong with your source.

[edit]Something for the weekend? ... MuraliKrishnaP spotted the obvious point that I missed, which is that you have exceeded the 128 nest limit because of the number of if .. else if statements.[/edit]

It's time for a new signature.

modified on Saturday, August 7, 2010 9:32 AM

MuraliKrishnaP7-Aug-10 3:07

MuraliKrishnaP

7-Aug-10 3:07

The following code

if(a)
{
}
else if (b)
{
}
else if(c)
{
}

is nothing but

if(a)
{
}
else
{
    if (b)
    {
    }
    else // how deep this can go? 128? not sure.
    {
        if(c)
        {
        }
    }
}

else, you can also do like this. Will this solve your problem?

if(a)
{
    if(flag)
    {
        // do work
    }
    else
    {
        // do work
    }
}

if(b)
{
}

if(c)
{
}

Re: Error :: C1061 compiler limit : blocks nested too deeply

Luc Pattyn7-Aug-10 11:02

Luc Pattyn

7-Aug-10 11:02

You can turn that into a regular switch, here is the scenario in pseudo-code:

int n=extract the number from string Tree_str;
switch (n) {
case 1:
    ...
    break;
case 2:
    ...
    break;
...
}

it will result in less code and faster execution!

Smile | :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

Re: Error :: C1061 compiler limit : blocks nested too deeply

David Crow7-Aug-10 15:58

David Crow

7-Aug-10 15:58

Shave the levels down to 123 or less.

"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

"Man who follows car will be exhausted." - Confucius

Re: Error :: C1061 compiler limit : blocks nested too deeply

Moak6-Aug-10 23:14

Moak

6-Aug-10 23:14

Please show source code or simplify nesting by refactoring.
Have a good weekend.

Chat in Europe Java | [Coffee]

Now with 24% more Twitter

ConnectEx fails

followait6-Aug-10 14:25

6-Aug-10 14:25

fail

//prepare function
	{
		DWORD dwBytes;
		int res = WSAIoctl(s,
			SIO_GET_EXTENSION_FUNCTION_POINTER,
			&GuidConnectEx,
			sizeof(GuidConnectEx),
			&g_lpfnConnectEx,
			sizeof(g_lpfnConnectEx),
			&dwBytes,
			NULL,
			NULL);

		int err = WSAGetLastError();

		assert(res==0);
	}	

	DWORD bytes_sent;
	BOOL ok = (*g_lpfnConnectEx)(s, (sockaddr*)&addr_in, sizeof(addr_in), NULL, 0, &bytes_sent, NULL);
	int err = WSAGetLastError(); // err==87 (indicates invalid parameter)
	assert(ok); // failed here!

succeed

int ok = connect(s, (sockaddr*)&addr_in, sizeof(addr_in));
assert(ok==0);

why?

Richard Andrew x646-Aug-10 15:06

Richard Andrew x64

6-Aug-10 15:06

The documentation says that when you call ConnectEx, the socket must be already bound.

The connect function binds the socket for you. That must be why connect succeeds when ConnectEx fails.

followait6-Aug-10 16:09

6-Aug-10 16:09

tried, still not work

int main()
{
	WSADATA wsa;
	int res = WSAStartup(MAKEWORD(2,2), &wsa);
	assert(res==0);

	SOCKADDR_IN addr_in;
	addr_in.sin_family = AF_INET;
	addr_in.sin_addr.s_addr = inet_addr("127.0.0.1");
	addr_in.sin_port = htons(5150);
	ZeroMemory(&addr_in.sin_zero, sizeof(addr_in.sin_zero));

	SOCKET s = WSASocket(AF_INET, SOCK_STREAM, IPPROTO_TCP, NULL, 0, 0);
	assert(s!=INVALID_SOCKET);
	SOCKADDR_IN addr_in_local;
	addr_in_local.sin_family = AF_INET;
	addr_in_local.sin_addr.s_addr = INADDR_ANY;
	addr_in_local.sin_port = 0;
	ZeroMemory(&addr_in_local.sin_zero, sizeof(addr_in_local.sin_zero));
	res = bind(s, (sockaddr*)&addr_in_local, sizeof(addr_in_local));
	assert(res==0);

	//prepare function
	{
		DWORD dwBytes;
		int res = WSAIoctl(s,
			SIO_GET_EXTENSION_FUNCTION_POINTER,
			&GuidConnectEx,
			sizeof(GuidConnectEx),
			&g_lpfnConnectEx,
			sizeof(g_lpfnConnectEx),
			&dwBytes,
			NULL,
			NULL);

		int err = WSAGetLastError();

		assert(res==0);
	}	

	DWORD bytes_sent;
	BOOL ok = (*g_lpfnConnectEx)(s, (sockaddr*)&addr_in, sizeof(addr_in), NULL, 0, &bytes_sent, NULL);
	int err = WSAGetLastError();
	assert(ok);
	//int ok = connect(s, (sockaddr*)&addr_in, sizeof(addr_in));
	//assert(ok==0);

	for (int i=0; i<10; ++i)
	{
		char buf[256];
		sprintf_s(buf, sizeof(buf), "message %d", i);
		WSABUF wsa_buf;
		wsa_buf.buf = buf;
		wsa_buf.len = strlen(buf);
		DWORD bytes_sent;
		int res = WSASend(s, &wsa_buf, 1, &bytes_sent, 0, NULL, NULL);
		assert(res==0 && bytes_sent==wsa_buf.len);
		printf_s("sent: %s\n", buf);
		Sleep(1000);
	}

	WSACleanup();

	return 0;
}

Richard MacCutchan6-Aug-10 21:49

6-Aug-10 21:49

followait wrote:
tried, still not work

What does this mean? Please explain which part of the program does not work, what results you receive, what messages you see, what error codes are returned. We cannot guess what happens by looking at your source code.

It's time for a new signature.

followait7-Aug-10 2:16

7-Aug-10 2:16

As he suggests, bind the socket used by ConnectEx, but still can't connect successfully.

Richard MacCutchan7-Aug-10 2:24

7-Aug-10 2:24

followait wrote:
but still can't connect successfully.

Did you actually read my previous post? What is the error code returned when your connect call fails?

It's time for a new signature.

followait7-Aug-10 4:28

7-Aug-10 4:28

sure, the error code of ConnectEx is 87, it means "The parameter is incorrect.".

Richard MacCutchan7-Aug-10 5:35

Re: ConnectEx fails [modified]

7-Aug-10 5:35

followait wrote:
the error code of ConnectEx is 87, it means "The parameter is incorrect.".

OK, so check all your parameters and make sure that they contain values appropriate to the call.

It's time for a new signature.

Richard MacCutchan7-Aug-10 5:56

7-Aug-10 5:56

I just took a copy of your code and ran it on my Windows 7 system and it runs fine; must be something local to you.

[edit]Actually no it didn't, I had to change a couple of things and misread a fail status. I will test some more tomorrow in the absence of a solution.[/edit]

It's time for a new signature.

modified on Saturday, August 7, 2010 1:05 PM

Richard MacCutchan7-Aug-10 11:20

7-Aug-10 11:20

Well, I went and did what I should have done in the first place and looked here[^] at the MSDN documentation. Take a look at the final parameter lpOverlapped which must not be NULL, and compare with your code.

It's time for a new signature.

followait8-Aug-10 19:33