Reference How to Play Media Files with Media Foundation.
My main thread has a parent window. I created an EVR child window in the worker thread through MFCreateVideoRendererActivate(HWND hwndVideo, IMFActivate** ppActivate) as a video player. But now the problem is that when the parent window exits, the child window will receive the WM_DESTROY message, which triggers the CloseSession, and the player has WaitForSingleObject waiting for the close confirmation, there may be a few seconds of stuck.
So I look forward to a safe method of Detach hwndVideo. so after that, the worker thread does not depend on the window system and does not affect the main thread.
But the IMFTopologyNode or IMFActivate / IMFMediaSink documents have not reset the interface method of hwndVideo，and I tried using IMFTopology::RemoveNode to remove the MF_TOPOLOGY_OUTPUT_NODE nodes, and it had no effect
You could probably handle WM_DESTROY in parent window and hide and detach (SetParent) children preventing their immediate destruction. Either way, however, creating windows from worker threads is almost always a bad idea resulting in artifacts as mentioned. If you could change this behavior, it would result in more reliable design.
Related
I am trying to track a moving desktop application window so I can move a corresponding transparent overlay window in parity. Currently, I hook the EVENT_SYSTEM_MOVESIZEEND event with SetWinEventHook. Inside my callback, I update the location of my overlay with the new location of the target application window.
This works, but it means that my overlay jumps around after the user lets go of the target window's title bar. I would like my overlay to track the target window as it is moving, not just after it has been moved.
The only way I can think to do this is to also hook the EVENT_SYSTEM_MOVESIZESTART event. When the START event fires, spawn a new thread that polls the target windows location and updates my overlay location. Then, when the END event fires, kill the polling thread.
Is this a reasonable approach, or is there a better way to achieve the functionality I want.
Thanks.
As per Hans Passant's suggestion on my question. I was indeed looking to hook EVENT_OBJECT_LOCATIONCHANGE instead of EVENT_SYSTEM_MOVESIZEEND. Once I hooked LOCATIONCHANGE, the tracking worked as expected.
One thing of note, by hooking LOCATIONCHANGE you will also receive mouse events for the window. You can easily filter the movement of the window by checking the hwnd of the WinEventProc callback function.
MSDN:
Handle to the window that generates the event, or NULL if no window is associated with the event. For example, the mouse pointer is not associated with a window.
I have one problem . I am trying to destroy child window ,but it also destroys parent window, so application closes.
I have such code.
HWND cloneWin =FindWindowEx(hWnd, 0, szChildWin, 0);
if (cloneWin) {
MessageBox(NULL,"You are trying to create more than one child window\n Current child window will be destroyed", "Message", MB_OK|MB_ICONINFORMATION);
DestroyWindow(cloneWin);
}
What is wrong ?
THx in advance !
The documentation says:
A thread cannot use DestroyWindow to destroy a window created by a different thread.
Since you are trying to find these windows using FindWindowEx, it seems pretty obvious that the windows were created in a different process, never mind a different thread. In other words, your call to DestroyWindow can never succeed. Hard to know why this is bringing the other application down, but since you are not obeying the rules then I suppose it is reasonable that anything can happen.
It's plausible I suppose that you could send the window a WM_CLOSE message and hope that it will respond by calling DestroyWindow. That would be a valid call to DestroyWindow because it would be made on the thread that created the window. But it all depends on how that other window responds to WM_CLOSE.
We have a MFC Visual-C++ application that is not reacting to any user input.
(Note: Currently only known on one machine. The behavior does recur occasionally, but only after the App has been running for several days!)
The application is redrawn when we switch to it via Alt-Tab (or the Task Bar), but we cannot, for example, activate it's main window by clicking on the title bar.
We have already pulled 4 dumps with WinDbg and checked the active instructions. We always were in some redraw code or somesuch inside the main thread (the GUI thread). We definitely were/are not in a modal message loop and the main thread's stack always looked "OK". (Most/all worker threads were idling, waiting for some event, no suspicious code there either.)
When investigating the problem with Spy++, we see the behavior specified also in this separate question, namely that we seem to get paint and activation messages, but no user input is routed to the application. When I have the application window on the screen, and select it to show messages of the main window,
it will only show "generic" "referesh" messages and nothing else
If I drill deeper, and select all messages for the whole process,
this is what we see:
The app is apparently only processing messages on one hidden sub-window (00CB09F0), and what we see there is a constant stream of 200 WM_PAINT messages per second.
Normally this Sub Window isn't processing any messages at all (except refresh WM_PAINT etc. when Windows sends them). It is normally used as a drawing area and the drawing happens through a WM_TIMER message on it's parent (010A09B8) window. (This WM_TIMER message isn't shown on the hanging app either though.)
The performance profile as shown in process explorer looks like this (100% kernel time, more or less):
I'd say that you have a redraw loop in that window that receives the WM_PAINT flood.
That usually happens if you call Invalidate or similar from the processing of the WM_PAINT message, directly or indirectly.
Other posibility is that, since you say that you are using a timer to redraw the window, the actual drawing is taking more time that the time it self, so the messages pile up in the queue.
Yet another posibility is that you are invalidating the window from a different thread than the one making the painting.
Anyway, you should ensure that you are calling Invalidate*() properly (you showed no code), and never from the OnPaint event. And avoid calling UpdateWindow() as this function can mess things if called without a little care.
I've seen this problem when an exception is thrown from a dialog. MFC's DoModal function disables the main program window then reenables it when the dialog returns; exceptions bypass the reenabling part and the main window remains disabled forever.
Did anyone notice that in Windows applications the mouse pointer doesn't change from Hourglass back to normal until you move the mouse?
So even if your application has finished a task and the mouse pointer has been set to go back to default, it will stay as an hourglass until you move the mouse. What is the reason for this, and can be it resolved?
I'm not sure if other people have noticed this but it is quite strange and it might be some kind of event-driven way to conserve OS resources.
The dialog box should maintain the logic of the hourglass. The worker thread should send a message to the dialog itself, telling it to start maintaining an hourglass thread. (You could test this by adding a temporary button to the dialog which starts and stops the hourglass.)
Another thing to be aware of is that having a second process set the hourglass of the first is an odd thing to do. An hourglass should only happen due to user action. While an hourglass is up, typically the only action that should be available to the user is "Cancel [whatever operation is keeping the hourglass up]."
Can it be resolved? Call ShowCursor(FALSE) before you call SetCursor(), and ShowCursor(TRUE) afterwards. Should do the job.
I'm fairly new to GUI programming and I'm trying to write a plotting lib in D to use with some otherwise console-based scientific apps. I'm using DFL as my GUI library.
Assume my plot form has a method called showPlot() that's supposed to display the plot on the screen. I would like to be able to have any thread in my app throw up a plot window and either block until the plot is closed or continue working, without the caller of showPlot() having to know what any other thread is doing with regard to plotting, or what plots were created in the past and may still be on screen. (The internals of showPlot() may, of course, have this knowledge.)
I'm still trying to wrap my head around how GUI libs typically work under the hood. It seems like you're supposed to only have one GUI thread, and one main form. I'd appreciate answers at the language/library-agnostic design pattern level in addition to language/library-specific ones.
Edit: To emphasize, this app has no GUI besides the plots that it throws up at interesting points in its execution. It's basically a console app plus a few plots. Therefore, there's no well-defined "main" form.
What you're going to be able to do will likely rely on how DFL works. Typically, in a GUI app, there's an event thread which handles all the events in your app - be it repaint events, button click events, mouse click events or whatever. That thread calls the event handler which is registered to handle the event (that frequently being the widget which was clicked on or whatnot). The problem that you run into is that if you try and do too much in those event handlers, you lock up the event thread, so the other events (including repaint events) don't get processed in a timely manner. Some GUI toolkits even specifically limit what you're allowed to do in an event handler. Some also limit certain types of operations to that specific thread (like doing anything - especially object creation - with actual GUI-code like the various widget or window classes that the toolkit is bound to have).
Typically, the way to handle this is to have the event thread either fire off separate threads in the event handlers and let those other threads actually handle the events, or you set some amount of state in the event handler, a separate, already-running thread is alerted to this change in state (possibly using the observer pattern), and it handles things appropriately based on that state. In either case, what the event handlers themselves do is generally fairly limited.
How GUIs work is generally very event-based. The program handles events from the user and the system and doesn't tend to a do a lot without being signaled to do it. Frequently, GUI apps don't do anything until they're told to by an event (though there are plenty of cases where a background thread is doing some sort of work separate from the events). What you're trying to do doesn't sound particularly event based, so that complicates things a bit.
My guess would be that you would need to have your app create a new window every time that you want to throw a new plot up. That window would likely be a child window of the main window which would be hidden since you obviously don't need it, and presumably DFL requires you to have a main window of some kind. There's a decent chance that each thread which wanted to create a window would have to tell the main GUI window to do that, but it depends on DFL really. It's also possible that DFL allows any thread to create new GUI elements (such as a new window).
Regardless, it would almost certainly be the main event thread which actually handles the window. The thread which wants to create a window and populate it would likely have to create the window (either directly or indirectly), and then update the state of the window by updating a set of shared variables so that the event thread could appropriately repaint the window. The most that original thread would likely to do actually repaint the window is send a repaint event to window after it's updated the state of the shared variables that hold the data necessary to paint the window. It wouldn't handle the painting itself.
As for the thread blocking, it would likely have to do busy-waiting until the window closed event was received by the event thread, and some shared variable was updated, or you could make it go to sleep until the event thread woke it up after receiving the window closed event. In the case where you didn't want it to block, it just wouldn't care about waiting to be told about the window-closed event and would keep chugging along.
In any case, hopefully that's enough information to put you in the right direction. Usually events drive everything, with everything hanging off the GUI, so to speak. But in your case, your app is using the GUI more like stdout. So, you might do better to first work on some small, fairly stupid GUI apps that are actual, normal, event-based GUI apps (like a Tic-Tac-Toe game or something) in order to get a better handle on how the GUI stuff works before trying to get it to work in a somewhat less standard manner like you are.
GUI frameworks typically have their own own event-loop, and call the application code as callbacks in reaction to external events(button clicks, timers, redraw, ...). The main difference between a "typical" console application and a GUI application is that you give up the control about when a function is called to the GUI framework.
Threads are typically used when the application code contains some long-running process, which cannot be interrupted into smaller chunks(large computations, copying files, take control over the world, ...). Then one thread is used to keep the GUI responsive, while the work is done in a separate thread. The main problem is to keep both threads correct in sync, since most GUI toolkits are not capable to handle calls from more than one thread. When you have only small work parts, which don't block the GUI for long time (<0.1s), then it is better to stay without worker threads.
I also strongly suggest to separate the GUI code and the application logic apart from each other. Having GUI code and application code mixed together is a maintenance nightmare.