|
Not sure what you are trying to explain or do here, but this line of code looks really incorrect.
currentthread = (MyAsynSocket*) = AFxGetthread():
Also in terms of trying to connect again, can you not wrap the connect call within some kind of loop operation? 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
 Dear Friends
I am loading a dll from another exe mfc application. for that i have exposed one api 'runAppli' in the dll as extern "C". Then I am loading the dll using LoadLibrary. By loading the dll itself the dll application is launched. I am surprised. I should call the api 'runAppli' and then the application should launch but its not happening. How come it is happening please give some suggestions.
[code]
// in the all
extern "C" BOOL __declspec(dllexport) runAppli(CString filename)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
if(filename.IsEmpty())
return false;
view->ShowWindow(SW_SHOW);
view->loadProfile(filename);
view->domainSetUpForProfile();
view->drawLines();
view->drawArcs();
view->drawProfile();
return true;
}
//in the client exe application
void CClientRevolutionProjDlg::OnBnClickedButton1()
{
HINSTANCE hinstLib;
hinstLib = LoadLibrary(L"C:\\Users\\sujan.dasmahapatra\\Documents\\Projects\\Bhagavan_SurfaceRevolution\\RevolutionProj\\debug\\RevolutionProj.dll");
}
[\code]
By simply loading the dll the dll application is launching.. why ??? Thanks Sujan
|
|
|
|
|
it's impossible for us to say, without knowing what the DLL has in its DllMain (or CWinApp::InitInstance).
|
|
|
|
|
Hi,
The MFC DllMain function will automatically call InitInstance when your DLL is loaded and it also calls ExitInstance when the DLL is unloaded.
You might be able to get around this by providing your own DllMain function:
HOWTO: How to Provide Your Own DllMain in an MFC Regular DLL[^]
I don't really recommend providing your own Dllmain function... you could probably prevent the window creation by modifying your InitInstance and removing/moving the window/view initialization.
Best Wishes,
-David Delaune
|
|
|
|
|
Hello,
Ive been programing in MFC for a while.
And now i would like to learn MFC deeper and to understand better what is going on behind the scene.
What good books exist for learning MFC?
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
