|
Whatever gave you that impression?
Have you been following all of this?
Of course that's not the place that handles all the windows messages NORMALLY. Just like any GUI based application, it's event driven by messages dispatched by the standard windows message pump. It's reacting to the "OnButtonClick()" events, just like anybody else.
One of the clicks causes a long running validation process. It's that process, already called by the DispatchMessage(), that needs to keep the GUI responsive while it munges on the data files and reports progress. (As a side note, it also cares about the cancel button which sets a cancelled flag).
The whole point of this thread of this post has been exactly that, a process, itself a "dispatched" message handler, that is taking a long time to do something. So a SECOND, NON-BLOCKING message pump is needed to allow for those backed up messages to be processed, JUST LIKE MICROSOFT SAYS TO DO.
So, yes it's a valid test. It's not the loop that processes all the messages, and if you've been reading for comprehension, you'd see that.
I no longer wish to play this game with you.
|
|
|
|
|
|
And don't forget this, which is what I've been saying
Using Messages and Message Queues[^]
Occasionally, an application needs to examine the contents of a thread's message queue from outside the thread's message loop. For example, if an application's window procedure performs a lengthy drawing operation, you may want the user to be able to interrupt the operation. Unless your application periodically examines the message queue during the operation for mouse and keyboard messages, it will not respond to user input until after the operation has completed. The reason for this is that the DispatchMessage function in the thread's message loop does not return until the window procedure finishes processing a message.
You can use the PeekMessage function to examine a message queue during a lengthy operation. PeekMessage is similar to the GetMessage function; both check a message queue for a message that matches the filter criteria and then copy the message to an MSG structure. The main difference between the two functions is that GetMessage does not return until a message matching the filter criteria is placed in the queue, whereas PeekMessage returns immediately regardless of whether a message is in the queue.
The following example shows how to use PeekMessage to examine a message queue for mouse clicks and keyboard input during a lengthy operation.
|
|
|
|
|
Oh, by the way, yes, what you suggest works, I have seen it myself, though implementing multiple message pumps in the code as soon as things get stickky is ugly.
Propper threading and coordination is the answer, as always.
I always laughed at Winzip. Once started, if you click anywhere in the window it brings up a 'do you want to abort'. It has done that for as lonkg as I have known it. They probably hook the mouse to do this, but it always made me laugh since it is so easy to do properly.
==============================
Nothing to say.
|
|
|
|
|
One last thing, FYI. That methodology existed as far back as Windows 3.1, long before threading existed in Windows. It was once the only way to do things. It is still applicable for non-threaded GUI applications.
Yes, when threads came along with Windows NT, that would have been a better way to approach things but it's not a absolute requirement nor the solution for every problem.
Anybody who implementes multiple message pumps, presumably in separate threads, is asking for trouble. However, there is an old saying, "Here's the rope....."
|
|
|
|
|
Thats the reason I disliked your suggestion, not that it doesnt work, but that it is a hack, a hack sugested by Microsoft. A hack based on a very old model, and one I dislike.
Sorry for any umbridge caused, I didnt mean it. I just like to see things done properly. 
==============================
Nothing to say.
|
|
|
|
|
Chuck O'Toole wrote: Whatever gave you that impression?
If you name a function ProcessWindowsMessages() dont be surprised if people assume it processes windows messages.
I dont have a problem with reading comprehension, I have a problem when people can't describe their code accurately.
==============================
Nothing to say.
modified 2-Nov-11 4:33am.
|
|
|
|
|
Chuck O'Toole wrote: So, I think that Sleep() does not do as you assert, it has no effect on the Windows Message Processing. Furthermore, Microsoft's documentation on Sleep() explicitly warns against using it during functions called by message processing as it may cause a hang or delay in processing.
I know that MSDN is sometimes wrong, but what I read about Sleep(), and what you may be already saying, is that it suspends the execution of the current thread, meaning that the current thread does NOTHING. So, in effect, it halts execution and processes no messages.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Nah, it's not wrong, it's exactly what Sleep() does. It has no knowledge of the context of what the application is doing (message dispatch or whatever else), it just stops running for the specified amount of time.
|
|
|
|
|
In addition to the other replies....
There's rarely a need to sit in a loop on the UI/message-loop thread. Waiting on I/O should be done on separate thread(s). IMO, learn how to use threads and thread synchronization objects like events and your app will be much better behaved (not eating CPU cycles doing nothing). Even a PeekMessage loop is going to peg a virtual processor unnecessarily. At least use GetMessage() if you can
Mark Salsbery
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Yes, PeekMessage() is CPU intensive but GetMessage() blocks. PeekMessage() allows your GUI to be "responsive" incase the user clicks on something, GetMessage() waits UNTIL the user clicks on something. (Yes, I know "Clicks or types or something")
|
|
|
|
|
Chuck O'Toole wrote: PeekMessage() allows your GUI to be "responsive" incase the user clicks on something
All messages go through either function (unless filtered). If not there would be a ton of unresponsive apps that use getMessage() in their message loop(s)
Mark Salsbery
|
|
|
|
|
You miss my point. If you have a loop like the OP that is doing something like polling for I/O then he's not getting back to the Windows message pump so his GUI is "unresponsive" (and his Timer requests aren't being handled - WM_TIMER). His problem is to *make* the GUI responsive while processing whatever he's doing. A "PeekMessage()" loop, strategically placed in his processing loop, will allow the Windows Messages to be processed. A "GetMessage()" loop, while it would make his GUI responsive, would totally hang *his* processing loop. So he needs a solution that keeps his loop running while allowing Windows to processes pending messages, hence "PeekMessage()".
Yes, threads might serve him better but at the cost of redesigning his app. A PeekMessage() loop is a quickie solution to this particular problem.
|
|
|
|
|
Mark Salsbery wrote: Waiting on I/O should be done on separate thread(s)
I agree, UI and IO should be kept apart.
==============================
Nothing to say.
|
|
|
|
|
Thanks you all for the replies it was very usefull i learned alot!!!
|
|
|
|
|
A Universal TCP Socket Class for Non-blocking Server/Clients
Single Threaded
The function PumpMessages() processes all Windows messages which arrive in the application so the GUI stays responsive although the code runs an endless loop:
mi_Socket.Listen(0, ms32_Port, 50);
while (...)
{
PumpMessages();
DWORD u32_Event;
SOCKET h_Socket;
DWORD u32_Error = mi_Socket.ProcessEvents(&u32_Event, &h_Socket, ....);
if (u32_Error == ERROR_TIMEOUT)
continue;
if (u32_Event & FD_ACCEPT) { }
if (u32_Event & FD_READ) { }
if (u32_Event & FD_CLOSE) { }
if (u32_Error) { }
};
|
|
|
|
|
Hi all,
Is there any alternate of MCIWndCreate API.
I want to play video in my application, and for doing it i have used MCIWnd functions. But my application is crashing due to these functions.
i have written this line
<pre>
m_myPlayer = MCIWndCreate(m_WndPreview->m_hWnd,AfxGetInstanceHandle(),WS_CHILD | WS_VISIBLE |MCIWNDF_NOMENU,File_Path);</pre>
Can anybody help me in this???
|
|
|
|
|
Your question is a bit vague. Are you looking for an alternate way to play AVI files? Are you looking for an alternate way to create the same MCI window? Aside of this, if it makes your application crash you are probably doing something wrong.
Anyways, to play all kinds of media, i'd try DirectShow[^] rather than MCI. I hope this can help you.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Hi all,
I start to do a simple application to control the P2LTCH(to blink a LED). So the toggle function as follow,
void toggleLed(unsigned char ledMask)
{
asm
(
mov dx, P2LTCH
);
}
However, it returns the following error.
Error [318] D:\Profiles\PC\WorkOnProjects\PIC\Demo\led_blink.c; 41.1 string expected
Error [194] D:\Profiles\PC\WorkOnProjects\PIC\Demo\led_blink.c; 41.1 ")" expected
Error [312] D:\Profiles\PC\WorkOnProjects\PIC\Demo\led_blink.c; 41.1 ";" expected
I do the coding on MPLAB IDE. Any comments really appreciate.
I appreciate your help all the time...
CodingLover
modified 1-Nov-11 5:54am.
|
|
|
|
|
The inline assembler block starts with "{".
|
|
|
|
|
I already tried that. But it doesn't work for me.
I appreciate your help all the time...
CodingLover 
|
|
|
|
|
See here[^], and yes you must use curly braces around your code block.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Thanks for the comment.
I tried a same example code segment from that page.
void toggleLed(unsigned char ledMask)
{
__asm {
mov al, 2
mov dx, 0xD007
out dx, al
}
}
Once I compile the code it gives the following error. It wired to me from what the documentations explain (the link you gave, book I refer, etc..)
Error [192] D:\Profiles\PC\WorkOnProjects\PIC\Demo\led_blink.c; 39.1 undefined identifier "__asm"
Error [312] D:\Profiles\PC\WorkOnProjects\PIC\Demo\led_blink.c; 39.7 ";" expected
Error [285] D:\Profiles\PC\WorkOnProjects\PIC\Demo\led_blink.c; 44.1 no identifier in declaration
Warning [374] D:\Profiles\PC\WorkOnProjects\PIC\Demo\led_blink.c; 44.1 missing basic type; int assumed
Error [314] D:\Profiles\OC\WorkOnProjects\PIC\Demo\led_blink.c; 44.1 ";" expected
I appreciate your help all the time...
CodingLover
|
|
|
|
|
I just tried a search for P2LTCH with google, finding the following block of code here.
void
toggleLed(unsigned char ledMask)
{
#define P2LTCH 0xFF5E /* The address of the I/O register. */
asm {
mov dx, P2LTCH
in al, dx
mov ah, ledMask
xor al, ah
out dx, al
};
}
Reading through this, I thought of your asm statement - In the code you showed using round braces, you used the asm keyword. Later you showed some code with curly braces, however I see that in the seconds code snippet you have used the __asm keyword, instead.
If you haven't already, I'd try the syntax used in the above snippet. I've a very hazy memory that somewhere I read that the __asm keyword is a MS thing. Dunno, too lazy to check. 
Though I do note that in Code::Blocks, asm gets syntax-highlighted, while __asm doesn't..
|
|
|
|
|
Actually that is the same I am referring, O'Reillys' book. But it doesn't work for me. Seems to me that my compiler is not support this.
I appreciate your help all the time...
CodingLover
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
