|
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++
|
|
|
|
|
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
|
|
|
|
|
I've seen that limit in action with too many windows, gdi related handles etc...
However, my IOCP server which is on the same box is handling more than 30,000 sockets.
Thanks for the idea.
Any other suggestions?
|
|
|
|
|
Just for kicks, since I found a few references to locked page limits and references that talked about increasing the working set, I gave this a try but no change in behavior...
HANDLE hProcess=GetCurrentProcess();
if (hProcess) {
DWORD dwMin, dwMax;
if (GetProcessWorkingSetSize(hProcess, &dwMin, &dwMax)) {
TRACE("Before\n");
TRACE("Minimum working set: %lu Kbytes\n", dwMin/1024);
TRACE("Maximum working set: %lu Kbytes\n", dwMax/1024);
}
SetProcessWorkingSetSize(hProcess, 204800, 1413120*4);
if (GetProcessWorkingSetSize(hProcess, &dwMin, &dwMax)) {
TRACE("After\n");
TRACE("Minimum working set: %lu Kbytes\n", dwMin/1024);
TRACE("Maximum working set: %lu Kbytes\n", dwMax/1024);
}
}
|
|
|
|
|
I don't think increasing the working set will have any effect. Based on what I have read you can implement zero-byte read operations to prevent exceeding the locked pages limit. I believe you should focus your attention to two areas:
1.) Non-Paged pool limit.
2.) Locked pages limit.
Here is a sample chapter from Network Programming for Microsoft® Windows®, Second Edition[^] which addresses the issue.
Best Wishes,
-David Delaune
|
|
|
|
|
Funny, thats the same article I've been digging through.
I agree. I've been trying to reduce my usage to see if that allows the connection limit to vary.
Thanks again for taking the time out to post your comments.
|
|
|
|
|
Randor wrote: you can implement zero-byte read operations
Do you think he means put the socket in non-blocking mode, read, then put it back into blocking mode?
DWORD dwArg=1;
ioctlsocket(socketClient,FIONBIO,&dwArg); // Non-blocking mode
recv(socketClient,NULL,0,0);
dwArg=0;
ioctlsocket(socketClient,FIONBIO,&dwArg); // Blocking mode
|
|
|
|
|