|
|
Hi,
I got a
WSAEWOULDBLOCK return code from the connect method would the proper
response be to retry the operation until I get a Zero return code
|
|
|
|
|
As MSDN suggests[^]:
If this indicates an error code of WSAEWOULDBLOCK, and your application is using the overridable callbacks, your application will receive an OnConnect message when the connect operation is complete
you shouldn't call again the Connect method because the connect operation is in progress after method returns. Viceversa, you should override the OnConnect method (see the example in its documentation[^]) to know when the connect operation is completed.
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]
|
|
|
|
|
I did that and i got WSAETIMEDOUT as the nerror code any way to set the time out value for more time
thanks
|
|
|
|
|
This time it is properly an error and you have to call again the Connect method. I don't know if you may change the timeout value.
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]
|
|
|
|
|
How about if I set the thread priority where CAsynSocket Class lives to the highest value the highest value
|
|
|
|
|
I have pop-up dialog that I custom paint in the client rect and show it in the titlebar of my MDI application. Then I use SetWindowPos such that my dialog stays in the desired relative position on the titlebar, whenever the main window is resized\moved.
Everything works fine, except when I minimize the main window. Clicking on the window icon in taskbar does not restore it, but the icon changes to that shown for an active window. I can however right-click on the icon and say "Restore" or "Maximize" to do the same.
Can someone tell me what I am missing? Does it have something to do with WS_CLIPSIBLINGS in the windows styles when its created?
modified 11-Jan-12 12:21pm.
|
|
|
|
|
I don't know how you showed it in the title bar?
This is my main window
hWnd = CreateWindow(
sz_WindowClass,
sz_Title,
WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN | WS_EX_CONTROLPARENT,
CW_USEDEFAULT, 0,
CW_USEDEFAULT, 0,
NULL,
NULL,
hInstance,
NULL
);
|
|
|
|
|
When I close my program in visual studio 2010 running in debug, I notice that I have to stop debug, to fully close the program. So I've been running my compiled exe's and the same thing happens, in which I have to use task Manager to kill the process. The windows close, but the process is still running.
So perhaps I'm missing something in my WndProc.
I have a WM_DESTROY, but I don't have a WM_CLOSE switch
case WM_DESTROY:
PostQuitMessage(0);
This is my File Exit
case IDM_FILE_EXIT:
PostMessage(hWnd, WM_CLOSE, 0, 0);
break;
|
|
|
|
|
Do you have any extra threads running, that aren't marked "background threads"?
|
|
|
|
|
I'm not sure, but that's a good start or point in the right direction.
|
|
|
|
|
Try "Break" instead of "Stop" for your debug session
and observe the stack(s) of the existing thread(s) 
They sought it with thimbles, they sought it with care;
They pursued it with forks and hope;
They threatened its life with a railway-share;
They charmed it with smiles and soap.
|
|
|
|
|
That's a good idea
MSG m;
while(GetMessage(&m, NULL, 0, 0)) <-- Break
{
if (!IsDialogMessage(hUserAccount_Index, &m))
{
TranslateMessage(&m);
DispatchMessage(&m);
}
}
|
|
|
|
|
Dont post WM_CLOSE message post WM_DESTROY Message
or
Call the PostQuitMessage function under WM_CLOSE case.
|
|
|
|
|
Posting the WM_CLOSE is quite correct.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I am not saying WM_CLOSE is wrong.
But I think OP did not call that function under WM_CLOSE message.
|
|
|
|
|
The default action for WM_CLOSE[^] will do what's necessary.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Yes, I agree with you. I developed a small program to check the behavior of WM_CLOSE. And It does its job.
Anyway:
If you want to check how many thread is used by your program just open the task manager then click on menu View->Set Column and then choose thread check box, You will get the thread count
|
|
|
|
|
johny10151981 wrote: WM_CLOSE. And It does its job.
As I said.
johny10151981 wrote: If you want to check how many thread is used by your program ...
Agreed, but it's not me who wants to know.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
My Bad It was not for you, It was for The OP.
|
|
|
|
|
I just came to that conclusion, that I did not handle my WndProc Correctly. So I started to remodel it with a better understanding. I must admit that I should check for open threads still running during one of the events.
I do need some help in organization and clarity here.
WM_CLOSE
Gives me a chance to do something before WM_DESTROY is called
WM_DESTROY
That's it, shutting down, I must do something, or it just shuts down
WM_QUIT
I'm suppose to PostQuitMessage(0), 0 means close, 1 means abort?
case IDM_FILE_EXIT:
PostMessage(hWnd, WM_CLOSE, 0, 0);
break;
case WM_CLOSE:
{
msgboxID = MessageBoxEx(g_hWndMainFrame,
L"Are you sure you wish to quite Internet Commerce Engine 5",
L"Question",
MB_OKCANCEL | MB_DEFBUTTON1 | MB_ICONINFORMATION,
LANG_NEUTRAL
);
}
switch ( msgboxID )
{
case IDOK:
PostQuitMessage(0);
DestroyWindow(hWnd);
break;
case IDCANCEL:
PostQuitMessage(1);
break;
}
break;
case WM_DESTROY:
break;
case WM_QUIT:
PostQuitMessage(0);
break;
|
|
|
|
|
jkirkerx wrote: PostQuitMessage(0), 0 means close, 1 means abort?
The parameter is an exit code that you want to return from your program. The numbers do not mean anything unless you, as the programmer, define a meaning for them.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
|
|
|
|
|
Yah that didn't work. Think I'm closer now
case WM_CLOSE:
{
msgboxID = MessageBoxEx(g_hWndMainFrame,
L"Are you sure you wish to quite Internet Commerce Engine 5",
L"Question",
MB_OKCANCEL | MB_DEFBUTTON1 | MB_ICONINFORMATION,
LANG_NEUTRAL
);
switch ( msgboxID )
{
case IDOK:
Sleep(1000);
PostQuitMessage(0);
return 0;
break;
case IDCANCEL:
return 1;
break;
}
}
break;
case WM_DESTROY:
break;
case WM_QUIT:
DestroyWindow(hWnd);
break;
|
|
|
|
|
jkirkerx wrote: case WM_QUIT:
DestroyWindow(hWnd);
break;
When the thread retrieves the WM_QUIT message from its message queue, it should exit its message loop and return control to the system.
Why is common sense not common?
Never argue with an idiot. They will drag you down to their level where they are an expert.
Sometimes it takes a lot of work to be lazy
Individuality is fine, as long as we do it together - F. Burns
|
|
|
|
|
I need to fix my child window first. I think I have the main window fixed. I have the same loop in the parent window and child window, so the child window is still running the loop when I try to shutdown the main window.
Now I'm starting to think that I have to call DestroyWindow for each control as well.
Main Window
case WM_CLOSE:
{
msgboxID = MessageBoxEx(g_hWndMainFrame,
L"Are you sure you wish to quit Internet Commerce Engine 5",
L"Question",
MB_OKCANCEL | MB_DEFBUTTON1 | MB_ICONINFORMATION,
LANG_NEUTRAL
);
switch ( msgboxID )
{
case IDOK:
Sleep(1000);
PostQuitMessage(0);
break;
case IDCANCEL:
return 1;
break;
}
}
break;
case WM_DESTROY:
DestroyWindow(hWnd);
break;
case WM_QUIT:
break;
Child Window
case WM_CLOSE:
{
HMENU hMenu;
HMENU hManagementMenu;
hMenu = GetMenu( gUserAccount_Index_GAC );
EnableMenuItem(hMenu, 1, MF_BYPOSITION | MF_ENABLED);
hManagementMenu = GetSubMenu(hMenu, 1);
EnableMenuItem(hManagementMenu, IDM_MANAGEMENT, MF_BYCOMMAND | MF_ENABLED);
DrawMenuBar( gUserAccount_Index_GAC );
}
return 0;
break;
case WM_DESTROY:
{
if ( hUserAccount_Index )
hUserAccount_Index = NULL;
DestroyWindow(lbl_UserAccount_Index_Label);
DestroyWindow(lb_UserAccount_Index_Listbox_Field);
DestroyWindow(bt_UserAccount_Index_Add);
DestroyWindow(bt_UserAccount_Index_Edit);
DestroyWindow(bt_UserAccount_Index_Delete);
DestroyWindow(bt_UserAccount_Index_Exit);
DestroyWindow(cWnd);
}
return 0;
break;
case WM_QUIT:
break;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
