SetWindowSubclass is killing my app!
-
Hi, This app is in C++ without MFC, and I'm using SetWindowSubclass to subclass two of my windows controls so that I can manually catch the messages that are sent to their message pumps and process them accordingly. The app is dialog-based and uses a GetMessage loop, so it does not usually take much CPU power... however, the problem is this: when I call SetWindowSubclass to subclass either of the controls, suddenly my CPU usage jumps to 99% on the task manager. Does SetWindowSubclass branch a new thread for each control that will just run on its own regardless of my GetMessage loop? If so, how do I stop it from doing that? If not, what the heck is it doing and how can I use SetWindowSubclass without using 99% of my darned CPU? Thanks!
KR
-
Hi, This app is in C++ without MFC, and I'm using SetWindowSubclass to subclass two of my windows controls so that I can manually catch the messages that are sent to their message pumps and process them accordingly. The app is dialog-based and uses a GetMessage loop, so it does not usually take much CPU power... however, the problem is this: when I call SetWindowSubclass to subclass either of the controls, suddenly my CPU usage jumps to 99% on the task manager. Does SetWindowSubclass branch a new thread for each control that will just run on its own regardless of my GetMessage loop? If so, how do I stop it from doing that? If not, what the heck is it doing and how can I use SetWindowSubclass without using 99% of my darned CPU? Thanks!
KR
KellyR wrote:
Does SetWindowSubclass branch a new thread for each control that will just run on its own regardless of my GetMessage loop?
No it wont start any new thread. If possible show the code that calls the SetWindowSubclass() fucntion and also the claabck function that you passed to SetWindowSubclass.
-
KellyR wrote:
Does SetWindowSubclass branch a new thread for each control that will just run on its own regardless of my GetMessage loop?
No it wont start any new thread. If possible show the code that calls the SetWindowSubclass() fucntion and also the claabck function that you passed to SetWindowSubclass.
I see what happened, I was returning in my WM_PAINT messages which was causing the huge CPU usage. I guess the DefSubclassProc must do something with WM_PAINT that causes the message not to be sent again; maybe by returning and not setting this parameter, the WM_PAINT was getting sent continuously. Thanks for help!
KR
-
I see what happened, I was returning in my WM_PAINT messages which was causing the huge CPU usage. I guess the DefSubclassProc must do something with WM_PAINT that causes the message not to be sent again; maybe by returning and not setting this parameter, the WM_PAINT was getting sent continuously. Thanks for help!
KR
KellyR wrote:
...maybe by returning and not setting...
"Maybe"? When working with window messages, you will have much better results if you are sure about how to handle the messages, including proper return values. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: