|
A lot of Windows API functions take or provide data through some structure, so you need to provide the structure (i.e. allocate memory for it), fill it (if it is input data), and pass a pointer to it. Passing a pointer "to nowhere" isn't going to cut it.
|
|
|
|
|
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.
|
|
|
|
|
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?
|
|
|
|
|
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 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.
|
|
|
|
|
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
Tony
|
|
|
|
|
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.
|
|
|
|
|
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. <
|
|
|
|
|
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)
{
}
else if(flag==FALSE)
{
}
}
else if(Tree_str==_T("Item 2"))
{
if(flag==TRUE)
{
}
else if(flag==FALSE)
{
}
}
.
.
.
.
else if(Tree_str==_T("Item 140"))
{
if(flag==TRUE)
{
}
else if(flag==FALSE)
{
}
}
|
|
|
|
|
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
|
|
|
|
|
The following code
if(a)
{
}
else if (b)
{
}
else if(c)
{
}
is nothing but
if(a)
{
}
else
{
if (b)
{
}
else
{
if(c)
{
}
}
}
else, you can also do like this. Will this solve your problem?
if(a)
{
if(flag)
{
}
else
{
}
}
if(b)
{
}
if(c)
{
}
|
|
|
|
|
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!
|
|
|
|
|
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
|
|
|
|
|
|
fail
{
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);
succeed
int ok = connect(s, (sockaddr*)&addr_in, sizeof(addr_in));
assert(ok==0);
why?
|
|
|
|
|
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.
|
|
|
|
|
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);
{
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);
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;
}
|
|
|
|
|
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.
|
|
|
|
|
As he suggests, bind the socket used by ConnectEx , but still can't connect successfully.
|
|
|
|
|
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.
|
|
|
|
|
sure, the error code of ConnectEx is 87, it means "The parameter is incorrect.".
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Fine, it is the reason why it doesn't work.
So ConnectEx works only in asynchronous mode, doesn't it?
Thanks a lot.
|
|
|
|
|
followait wrote: BOOL ok = (*g_lpfnConnectEx)(s, (sockaddr*)&addr_in, sizeof(addr_in), NULL, 0, &bytes_sent, NULL);
Now what would be the most fishy aspect of that statement?
You should realize that for every cast the programmer takes the responsibility away from the compiler; you are simply passing a SOCKADDR_IN thingy and casting it to something else (a sockaddr) in order to make the compiler happy. However if they aren't compatible, that will not work out at run-time. So back to the documentation and the drawing board.
|
|
|
|
|