OnSize execution, locks
-
The OnSize handler of a CListCtrl receives control once for each small dragging movement separatedly. If one drags the mouse quickly when resizing, the messages will be generated quickly too. Because the resizing of a dozen columns or so is a bit computing intensive, a message generated from a longer mouse movement (dragging) with the the new size can arrive sooner than the processing of the previous message has been finished. Is this normal? Should not the processing of the previous message (the same type of message, the same handler, to the same object) be completed before the next such message gets scheduled? The interruption of the message processing causes problem, because size calculations get confused. I am trying to synchronize the executions with using locks. I declared a CCriticalSection object and used Lock and Unlock in the OnSize handler. It has no effect. The lock count goes up, and it does not block the thread from execustion. I declared a CRITICAL_SECTION object and used Init, Enter and Leave - the result is the same. Why is the lock not blocking the thread?
-
The OnSize handler of a CListCtrl receives control once for each small dragging movement separatedly. If one drags the mouse quickly when resizing, the messages will be generated quickly too. Because the resizing of a dozen columns or so is a bit computing intensive, a message generated from a longer mouse movement (dragging) with the the new size can arrive sooner than the processing of the previous message has been finished. Is this normal? Should not the processing of the previous message (the same type of message, the same handler, to the same object) be completed before the next such message gets scheduled? The interruption of the message processing causes problem, because size calculations get confused. I am trying to synchronize the executions with using locks. I declared a CCriticalSection object and used Lock and Unlock in the OnSize handler. It has no effect. The lock count goes up, and it does not block the thread from execustion. I declared a CRITICAL_SECTION object and used Init, Enter and Leave - the result is the same. Why is the lock not blocking the thread?
A CRITICAL_SECTION will not block the SAME thread from reentrancy into the same lock.
-
A CRITICAL_SECTION will not block the SAME thread from reentrancy into the same lock.
-
But the next message should be passed in a different thread! It is not a recursion, the handler is processing separate messages.
It is possible you are in the middle of processing a posted message, and some function you call causes a sent message to appear in your queue, in which case it seems like it 'came' from another thread, when in fact it did not. If you were to put some GetCurrentThreadId() function calls, you might be able to prove to yourself if it is the same thread or not. None of us has probably ever observed a locked CRITICAL_SECTION entered successfully by another thread.
-
It is possible you are in the middle of processing a posted message, and some function you call causes a sent message to appear in your queue, in which case it seems like it 'came' from another thread, when in fact it did not. If you were to put some GetCurrentThreadId() function calls, you might be able to prove to yourself if it is the same thread or not. None of us has probably ever observed a locked CRITICAL_SECTION entered successfully by another thread.
I am not doubting that the lock functions work properly. I recorded the currently active thread ids in an array. The messages will be passed in the same thread, even though their processings are running concurrently, at least partially. Should not cucurrently running messages be passed in different threads? Anyway, I "solved" the problem by simply immediately returning from the message processing if another message is still being processed, i.e. too fast dragging will not be honored (not truely a restriction).
-
The OnSize handler of a CListCtrl receives control once for each small dragging movement separatedly. If one drags the mouse quickly when resizing, the messages will be generated quickly too. Because the resizing of a dozen columns or so is a bit computing intensive, a message generated from a longer mouse movement (dragging) with the the new size can arrive sooner than the processing of the previous message has been finished. Is this normal? Should not the processing of the previous message (the same type of message, the same handler, to the same object) be completed before the next such message gets scheduled? The interruption of the message processing causes problem, because size calculations get confused. I am trying to synchronize the executions with using locks. I declared a CCriticalSection object and used Lock and Unlock in the OnSize handler. It has no effect. The lock count goes up, and it does not block the thread from execustion. I declared a CRITICAL_SECTION object and used Init, Enter and Leave - the result is the same. Why is the lock not blocking the thread?
Following is only for the record (and for the improbable case, that someone experiences a like problem). I found the problem. The original problem description was incorrect. The OnSize handler changes the size of certain columns. This in itself does not trigger OnSize, however it can cause inserting or removing the horizontal scroll bar, and THAT causes OnSize. Now, the problem was, that this OnSize message has not been queued but started immediately, i.e. recursively; in other words, the processing of the original OnSize message has not been finished yet, and the new one got started - a big mess.