I am fixing a MFC applivation written in C++. It is a GUI and it communicates with an external module connected to the PC via USB.
I want to avoid using a separate thread. Is there a way I can add things to the mainloop so that it runs continously rather than being event based?
I want the mainloop to make a call to a function runCommStack() in every loop.
Some possible approaches:
You can use CWnd::SetTimer to set a timer.
You can override CWinApp::OnIdle (called by CWinApp::Run).
You can override CWinApp:Run, copying and modifying the original MFC's CWinApp:Run. This definitely is not the easiest solution.
You can create a background thread.
It depends on the requirements of runCommStack(). Is this function running long times? Then you probably won't want to run it in the GUI thread. Does runCommStack need to get called every n milliseconds? Then it might also be better to run it in it's own thread. In other cases you can just use the timer or OnIdle approach.
Regarding solution 1: as Tim pointed out WM_TIMER messages are low priority messages and will not be passed to the application while other higher-priority messages are in the message queue. See also Determine priority of a window message.
With solution 2 you should remind that OnIdle will only be called if no window message is available. So this is quite the same as solution 1 (in fact a little worse).
Also keep in mind that solutions 2 and 3 might result in your runCommStack not getting called if a dialog's DoModal() is called or if a message box is displayed. This is because during MessageBox() the control is not returned to CWinApp::Run().
I'ld implement solution 1 or 4.
When there are no messages (like keys, mouse, repaint) arriving the main loop suspends the program, waiting for the next message. So the idea of adding a call to the main loop will give you very erratic operation. For example, minimizing your window will stop all the USB communication.
Using SetTimer and calling your runCommStack function in a WM_TIMER handler will probably be much more satisfactory.
You can use idle processing with CWinApp::OnIdle; this will work if reading your USB device takes only a short amount of time, otherwise the user interface will be blocked during long reads.
But using a separate thread is definitely a better method.
Related
I have a DirectShow filter written in Delphi 6 using the DSPACK component library. It is a push source video filter that receives its source frames from an external cooperating process that I also wrote.
When the worker thread that calls my Filters' FillBuffer() call is created and ran, when the graph starts up, the first thing I do from that worker thread is create a hidden window using AllocateHWND() to process WM_COPYDATA messages that contain the externally generated frames. Right before the thread is destroyed I destroy the hidden window. In other words the hidden window is created and destroyed in the execution context of the worker thread that calls FillBuffer(). My intention is to let FillBuffer() block as it waits for a WM_COPYDATA or a WM_QUIT message. The external cooperating process will submit frames to my filter using a WM_COPYDATA message and the handle to my hidden windows' WndProcc(). I will post a WM_QUIT message in my override of the pin's Inactive() method (thanks for that tip #RomanR), to unblock the FillBuffer() call before the filter is shut down.
My question is, is it safe to call PeekMessage() or GetMessage() from the FillBuffer() call given this scenario? Or are there potential pitfalls that may arise from this occurring in the context of a DirectShow graph executing? Also, do you see any flaws in my overall approach here that I need to consider?
Safe, but not so reasonable too. FillBuffer is being called on a background worker thread which is typically have no windows on it. It would be perhaps only your window which you are going to implement message loop for. And the window is here only for the purpose of receiving WM_COPYDATA messages. It sounds like it can work out, but you would perhaps could do much easier without helper windows by passing your data between applications via named file mappings and events. In case of video (you have audio, right?) you would also be able to appreciate a smaller performance overhead.
I've created two threads A & B using CreateThread windows API. I'm trying to send the data from thread A to B.
I know I can use Event object and wait for the Event object in another using "WaitForSingleObject" method. What this event does all is just signal the thread. That's it! But how I can send a data. Also I don't want thread B to wait till thread A signals. It has it own job to do. I can't make it wait.
I can't find a Windows function that will allow me to send data to / from the worker thread and main thread referencing the worker thread either by thread ID or by the returned HANDLE. I do not want to introduce the MFC dependency in my project and would like to hear any suggestions as to how others would or have done in this situation. Thanks in advance for any help!
First of all, you should keep in mind that Windows provides a number of mechanisms to deal with threading for you: I/O Completion Ports, old thread pools and new thread pools. Depending on what you're doing any of them might be useful for your purposes.
As to "sending" data from one thread to another, you have a couple of choices. Windows message queues are thread-safe, and a a thread (even if it doesn't have a window) can have a message queue, which you can post messages to using PostThreadMessage.
I've also posted code for a thread-safe queue in another answer.
As far as having the thread continue executing, but take note when a change has happened, the typical method is to have it call WaitForSingleObject with a timeout value of 0, then check the return value -- if it's WAIT_OBJECT_0, the Event (or whatever) has been set, so it needs to take note of the change. If it's WAIT_TIMEOUT, there's been no change, and it can continue executing. Either way, WaitForSingleObject returns immediately.
Since the two threads are in the same process (at least that's what it sounds like), then it is not necessary to "send" data. They can share it (e.g., a simple global variable). You do need to synchronize access to it via either an event, semaphore, mutex, etc.
Depending on what you are doing, it can be very simple.
Thread1Func() {
Set some global data
Signal semaphore to indicate it is available
}
Thread2Func() {
WaitForSingleObject to check/wait if data is available
use the data
}
If you are concerned with minimizing Windows dependencies, and assuming you are coding in C++, then I recommend using Boost.Threads, which is a pretty nice, Posix-like C++ threading interface. This will give you easy portability between Windows and Linux.
If you go this route, then use a mutex to protect any data shared across threads, and a condition variable (combined with the mutex) to signal one thread from the other.
Don´t use a mutexes when only working in one single process, beacuse it has more overhead (since it is a system-wide defined object)... Place a critical section around Your data and try to enter it (as Jerry Coffin did in his code around for the thread safe queue).
I have an application that message-loops using MsgWaitForMultipleObjects to catch additional events while pumping ui messages. It seems that as soon as a window is being moved or resized, DefWindowProc begins it's own message loop until the mouse is being released. This situation prevents from the outer loop to catch the additional messages in the meantime.
I'd hate to multi-thread the application just because of this. Is there any other way to solve it?
MsgWaitForMultipleObjects has very few uses in a traditional multi threaded program. It has some use in Games - where traditional non client frame elements are omitted and APIs like "MessageBox" and "DoDragDrop" are avoided...
Usually it finds its best use in "UI worker" threads that don't host visible windows, but use the message queue as an inter thread messaging system and also need to wait on kernel handles.
In your case, making a second thread does not seem avoidable. Ironically, PostThreadMessage + MsgWaitForMultipleObjects will probably be the easiest way to set up a reliable communication mechanism between the GUI thread and your "ui" worker thread.
There are several additional places in the Windows API that will enter their own message loop. If you need to continue handling your messages during these times then you'll need a separate thread.
I wish to launch a separate thread for handling window messages (via a blocking GetMessage loop), but still create the windows in the initial thread, afterward.
Within the separate thread, as soon as it launches, I am calling PeekMessage with PM_NOREMOVE to ensure a message queue exists (is this necessary?), followed by..
AttachThreadInput(initial thread id,GetCurrentThreadId(),true)
..before finally entering the message loop
I am not yet using a mutex or cs to ensure this is happening in time, but am merely using a Sleep statement in my initial thread for the sake of simplicity.
Regardless, window messages do not appear to be intercepted by the separate thread.
I am a little unsure as to whether I am doing this correctly, and would appreciate any possible guidance. Both threads are in the same process
Thank you all
That's not what AttachThreadInput does. Even after you attach your input queue to another thread, Windows still have thread affinity. Messages in the queue for a given window can only be removed from the queue by that window's thread.
What AttachTheadInput does is to make two threads share an input queue. This allows them to query information about the input state and know that the other thread will get the same answer for the same query. For instance, one thread could call GetAsyncKeyState and know that the answer reflected the key state for the other thread.
It allows two or more threads to have the same relationship to the input queue and each other as processes had in Windows 3x. This is the reason that this API exists; so that complex multiprocess applications could be ported from Win 3x to Win95/WinNT.
It seems the best way to instigate window creation from the main thread, while having messages for them handled in a separate, looping thread is to use a custom message, that can be sent to the separate thread - Thus allowing it to create the window, but still allowing that action to be invoked from the initial thread:
1) Allocate a custom message, and create a structure to hold the window initialisation parameters:
message_create_window = WM_USER + 0;
class Message_create_window{
Message_create_window(...);
};
2) Instead of calling CreateWindow(Ex), use something similiar to the following, passing in the relavant window creation parameters:
PostThreadMessage(
thread.id,
message_create_window,
new Message_create_window(...),
0
);
3) Handle the custom message in the message pump of your ui handling thread, extract the creation parameters, & free afterwards:
MSG msg;
GetMessage(&msg,0,0,0);
...
switch(msg->message){
...
case message_create_window:{
Message_create_window *data=msg->wParam;
CreateWindowEx(data->...);
delete data;
}break;
...
This does, however, have the following side-effects:
The window will be created asynchronously. If it is required that the initial thread block until the window is created (or, indeed, that the window's existence can ever be asserted) then a thread synchronisation tool must be used (such as an event)
Care should be taken when interacting with the window (it is a multithreaded application, after all)
If there are any major holes in this answer, or this seems like a terrible approach, please correct me.
(This is still my question, & I am trying to find the best way to accomplish this)
I'm implementing my app as a drag source. When I call DoDragDrop (Win32 call, not MFC) it enters into a modal loop and I don't get repaint messages in my main window until DoDragDrop returns. Unfortunately if I do a drop in the shell (a file) and the filename is already there the shell asks if I want to replace the file. But since me app is blocked because DoDragDrop hasn't returned it isn't repainting and looks 'frozen'.
Any clues ?
Have you tried a timer? I ran into the same problem with DoDragDrop() and other blocking calls like SHFileOperation() and solved it using a call to SetTimer().
EDIT: If you want more control over DoDragDrop() then a worker thread works well. You can try calling DoDragDrop() in the worker thread, as someone suggested, but I couldn't get the mouse capture to work properly. An easier solution is to call DoDragDrop() in the main thread and have the worker thread periodically post a WM_USER message to the main thread's queue. DoDragDrop() will then retrieve the message and dispatch it to your window's WndProc(), at which time you can perform idle processing for as long as the queue remains empty. If you give the worker thread a lower priority than the main thread, then it will execute and post the WM_USER message as soon as the main thread becomes idle (i.e., as soon as DoDragDrop() finishes processing all user input and calls MsgWaitForMultipleObjects() internally). This method is better than the SetTimer() method because it gives your application full control over the CPU. You don't have to wait up to 10ms (the minimum frequency that SetTimer() allows) after returning from your WM_TIMER handler returns before the next WM_TIMER message arrives.
I suggest running the drag-and-drop operation on a different thread. That way, DoDragDrop() will block the message loop in the new thread rather than the message loop in your UI thread. If you take this approach, you should also consider (off the top of my head):
Any code that might be run from both your main thread and your drag-and-drop thread will need to be re-entrant. As a corollary, you will need to protect any data structures used by both your main thread and your drag-and-drop thread. If your application is already multi-threaded, you should be familiar with these concerns.
You should think about what happens if your user never responds to the shell's dialog box. Can he continue to interact with your UI? Can he invalidate the data that would have been 'dropped' in the pending operation? Can he quit your application?
Seems like the real answer is to implement IAsyncOperation in my data object.