|
the following is my code,give me some advise.
sometimes the dialog can close by this,sometimes doesnot work like i want.
LRESULT CSettingDlg::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
switch(message)
{
case WM_COMMAND:
//I use the button to exit the dialog,which is static create by me!
if(wID==IDC_Btn_SetEsc) //static create the button
{
this->SendMessage(WM_CLOSE,NULL,NULL);
return TRUE;
//break;
}
case WM_CLOSE:
// case WM_DESTROY://2008--4--24 xqh_xg
DeleteObjects(); //free the used object
break;
}//switch(message)
return CDialog::WindowProc(message, wParam, lParam);
}
|
|
|
|
|
Why, oh WHY are you using a WindowProc() override in an MFC dialog?
Or is this not MFC? 
MFC modal dialogs are closed with CDialog::EndDialog().
MFC modeless dialogs are closed with CWnd::DestroyWindow().
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Because the button which is used to close the Diaolg is created by myself.
I donot use the ok button and cancel button which are displayed on the Dialog by default.I want to close the Dialog by just send WM_CLOSE message.AS we all know ,when we send the WM_CLOSE message, the WM_Destory and WM_QUIT message will occur following.so i think i can close the Dialog by just send WM_CLOSE.But the idea sometimes work well ,sometimes it doesnot.
I donot know what is the wrong.
|
|
|
|
|
xqhrs232 wrote: Because the button which is used to close the Diaolg is created by myself.
There's rarely a need to override WindowProc(). If you're using MFC,
why not just use MFC's message handling instead of doing it the Win32 way?
Regardless, your code snip is incomplete so it's not much help.
The WM_CLOSE message should be posted, not sent from your window proc.
BEGIN_MESSAGE_MAP(CSettingDlg, CDialog)
ON_BN_CLICKED(IDC_Btn_SetEsc, &CSettingDlg::OnBnClickedBtn_SetEsc)
ON_WM_CLOSE()
END_MESSAGE_MAP()
LRESULT CSettingDlg::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
return CDialog::WindowProc(message, wParam, lParam);
}
void CSettingDlg::OnBnClickedBtn_SetEsc()
{
PostMessage(WM_CLOSE);
}
void CSettingDlg::OnClose()
{
DeleteObjects();
CDialog::OnClose();
}
Mark
Mark Salsbery
Microsoft MVP - Visual C++
modified on Saturday, May 10, 2008 11:18 PM
|
|
|
|
|
if the button which i used to exit the dialog is created by dynamic.what can i do?if this, i must use windproc function which can capture the WM_COMMAND which is sended by common control.
|
|
|
|
|
You can do it the same way I showed since you know the ID of the
button (IDC_Btn_SetEsc) at compile time 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
if i want to use the WM_COMMAND message to dispose the common control's press message.what can i do?i think my idea is good,but something is wrong which i donot know now!Because the MFC message is a way,the win32 Messge is another way.i think that my way which uses the Winproc( ) function(in WIN32 message way)is good way.may be i make a mistake in some another positon which i donot know now!
you think that my win32 message way is wrong?that in MFC Appication we cannot use the win32 message way(Winproc( ) function).
|
|
|
|
|
xqhrs232 wrote: Because the MFC message is a way,the win32 Messge is another way
What do you mean? They are all Windows messages - there's no MFC messages.
xqhrs232 wrote: you think that my win32 message way is wrong?
Not wrong, just unnecessary. You're using MFC - why use a Win32 style Window proc
when MFC handles that for you? If you do that, then all MFC is, is an expensive wrapper
around an HWND.
xqhrs232 wrote: if i want to use the WM_COMMAND message to dispose the common control's press message.what can i do?
Again, what do you mean? Your original problem was closing the dialog on a
button press, right? I showed you MFC style code that does that. If you want
to use the WM_COMMAND message instead of the button click notification message,
then use it. Same effect. Here's the WM_COMMAND version:
BEGIN_MESSAGE_MAP(CSettingDlg, CDialog)
ON_COMMAND(IDC_Btn_SetEsc, &CMFCTesterDlg::OnBtn_SetEscCommand)
ON_WM_CLOSE()
END_MESSAGE_MAP()
LRESULT CSettingDlg::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
return CDialog::WindowProc(message, wParam, lParam);
}
void CSettingDlg::OnBtn_SetEscCommand()
{
PostMessage(WM_CLOSE);
}
void CSettingDlg::OnClose()
{
DeleteObjects();
CDialog::OnClose();
}
Anyway, you missed my point in my original post, which was that you needed
to POST the WM_CLOSE message, not SEND it.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I think i can capture and dispose the WM_COMMAND message in the Winproc( ) function which is sended by the common control.
my question is that my idea is wrong or not? why sometimes i cannot close the Dialog?what is the matter with my way?
I think my way is the same to your way,but now why my way doesnot work well?
|
|
|
|
|
xqhrs232 wrote: I think i can capture and dispose the WM_COMMAND message in the Winproc( ) function
MFC does that for you in the code I posted. It does the same thing you are doing
except in an MFC way instead of the Win32 way.
xqhrs232 wrote: I think my way is the same to your way,but now why my way doesnot work well?
I used PostMessage(), you used SendMessage().
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
you wrote "I used PostMessage(), you used SendMessage()."
you think this is the reason that i cannnot close the dialog sometimes?
if you send WM_CLOSE message,you want to close the dialog right now. so i think i use SendMessage( ) function is a right way.that waits for the result back which we want.so i think i use SendMessage( ) function is no wrong.but the question is that sometimes i can close the dialog correctly but sometimes it doesnot work well!
|
|
|
|
|
Is there a way to write an application to take advantage of multi-core procesors so that all availble processors (be-it dual-core, quad-core, etc) get equal duty??
Thanks!
|
|
|
|
|
Threads.
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
|
|
|
|
|
97C5ENVY wrote: Is there a way
yes, be multithreaded.
but that also means that you'll probably have to be very careful about data synchronization and such problems...
|
|
|
|
|
The OS usually assigns the workload to the various cores (or processors). If, for example, you have an application with just a single thread running on a dual core processor, it's quite likely that Windows will spread the work evenly to both cores. In this case, each core would be loaded to approx. 50%.
So, to answer your question, Windows will try to "equalize" the workload for all cores/processors (unless you mess around with affinity settings). However, In order to load the cores to more than 50% (or 25% for a quad), you'll have to create multiple threads in your application (as CPallini pointed out so short and sweet  ).
|
|
|
|
|
Michael Schubert wrote: If, for example, you have an application with just a single thread running on a dual core processor, it's quite likely that Windows will spread the work evenly to both cores.
How can a single thread be run simultaneously on multiple cores?
Just curious,
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Not simultaneously. It's called context switching. The OS manages the thread pool and distributes the workload from all threads among the available cores (be it 1, 2, 4 or 16 cores) in small time intervals.
|
|
|
|
|
Michael Schubert wrote: distributes the workload from all threads among the available cores (
Right, but you stated "If, for example, you have an application with
just a single thread running on a dual core processor, it's quite likely
that Windows will spread the work evenly to both cores. In this case, each
core would be loaded to approx. 50%.".
So again, how does one thread get split between cores? IME, if you have a thread
that is busy (e.g. in a loop) then one core gets pegged to 100%.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark Salsbery wrote: So again, how does one thread get split between cores? IME, if you have a thread
that is busy (e.g. in a loop) then one core gets pegged to 100%.
The OS splits, even a single thread, into "time slices".
If you have a dual core CPU, try it yourself with a single threaded application that puts a heavy load on the CPU and watch how the workload is distributed in Task Manager. It may favour one core but you will see that both are used (unless you set the affinity in Task Manager to use just one core).
|
|
|
|
|
Gotcha. The key part I missed in your previous reply was "Not simultaneously" 
Thanks!
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
So basicly the OS manages the processor loads and not the application correct?
|
|
|
|
|
I am trying to use CopyFileEx to copy files like this:
CopyFileEx(m_strSrc,m_strDst,(LPPROGRESS_ROUTINE)CopyProgressRoutine,NULL,false,COPY_FILE_FAIL_IF_EXISTS)
DWORD CALLBACK CopyProgressRoutine(
LARGE_INTEGER TotalFileSize, LARGE_INTEGER TotalBytesTransferred,LARGE_INTEGER StreamSize, LARGE_INTEGER StreamBytesTransferred,
DWORD dwStreamNumber, DWORD dwCallbackReason,
HANDLE hSourceFile, HANDLE hDestinationFile, LPVOID lpData)
{
return PROGRESS_CONTINUE;
}
I want to have a progress indicator to display the copying progress. What would be the best way to have somthing like this?
I think this should be in CopyProgressRoutine. Is IProgressDialog an option for me? If I use this, I can update the progress using IProgressDialog::SetProgress but this function seems to accept the following DWORD parameters:
DWORD dwCompleted,
DWORD dwTotal
But in my CopyProgressRoutine I have LARGE_INTEGER parameters
TotalFileSize, TotalBytesTransferred. Please advice. Thanks
modified on Thursday, May 8, 2008 8:55 PM
|
|
|
|
|
Have CopyProgressRoutine() post a message to the primasry thread indicating the percent done. The handler for that message will call the progress bar's "update" methods.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I'm stress testing a server that utilizes IO Completion Ports. For my test client, I'm just creating threads that perform many connect() calls to the server and leaving the socket connected so I can test my timeout mechanism on the server.
One thing of interest on the test client is a limit I hit on a per thread basis. If one thread loops with a call to connect() inside, just shy of connection number 3956, connect() fails and the system error reads "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full."
I can drop the thread and start a new one from the same application and the cycle will repeat just fine. I tried increasing the threads stack size, etc... but it doesn't change it.
This is just a test client meant to beat up on my server, but I'm at a loss to explain why connect() always fails at roughly the same spot. I'm using the loopback address to test them on the same box.
Any guidance would be greatly appreciated.
|
|
|
|
|
There is a limit of 10,000 handles per process on Windows XP. I have no idea what the limit is on Vista. My guess is that you are reaching this limit.
Maximum NT User Handles Per Process Is 10,000 in Windows XP[^]
CreateIoCompletionPort consumes 1 handle as does each socket.
3956 * 2 = 7912
Not counting GDI/window and other types of handles.
You can try changing the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota to check if my theory is correct. I may be wrong.
Best Wishes,
-David Delaune
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
