I think there's no definite answer so how would you approach debugging this problem?:
My main app (a MicroStation plugin) launces IE using the SHDocVw.InternetExplorer COM wrapper, interacts with it, hides it when it is not used (e.g. intercepts when the user closes the window and sets InternetExplorer.Visible to false).
When the main app is closed the plugin closes IE by calling InternetExplorer.Quit but the iexplore process is left running (the IE is hidden at the moment the main app is closed).
What I have tried:
Calling System.Runtime.InteropServices.Marshal.FinalReleaseComObject on the InternetExplorer object after calling Quit
Setting the reference to the InternetExplorer object to null after Quit and FinalReleaseComObject
Making sure the parent managed objects gets GC'd (checking if Finalize is called) before the main app exits
Creating a test console app and trying to reproduce the problem there. E.g. trying to call Quit when IE is in the hidden state. (I could not reproduce the problem, IE gets closed as soon as the app exits)
What is also interesting, I could not reproduce the problem calling Quit within the same main app (MicroStation plugin) but while the main app is running, not in the exit event handling code. When called in that other place Quit closes IE as expected.
Otherwise the InternetExplorer object is opaque to me.
Are there other ways to debug this problem?
Edit: It may be worth noting that the main app creates a UserControl and makes the IE window a child of this UserControl (using SetWindowLong to change the GWL_STYLE to allow the window to be a child and SetParent to set the UserControl as parent). But when the IE is hidden (which it is when the Quit attempt fails) the parent window is set to 0.
Thanks!
Related
I need to execute some native code to interact with the macOS menu bar, ideally immediately after it got initialised. IMHO, a good time would be right after the JavaFX application window becomes visible.
From the documentation, I thought that Window.onShown should do exactly that:
Called just after the Window is shown.
But that does not seem to be the case. When putting a breakpoint into the event handler for Window.onShown, the window is not yet visible. Unfortunately at this point, the macOS menu bar is not yet fully initialised, so all my changes to the menu bar would be overwritten later by JavaFX's default menu bar.
For now, I'm just using a delay of 1sec after the WindowEvent.WINDOW_SHOWN is sent, but that does not seem to be a good solution. So does anyone have a better idea on how to reliably determine when the window is actually visible or all initialisations have finished?
If you put a breakpoint in the onShown method the problem might just be that the window was created but you are blocking the visualization because of the debugger.
If this is not the case you could try to create a new Thread that only checks for the visibility of the window using the isShowing method of the class Window.
This should be faster than just waiting for one second after the onShown method was called.
A little background
Our application (AppA) is calling a 3rd party application (AppB). We are simulating AppB's window as being modal to our application.
pseudo
while AppB_Running
If AppA_focused
SetForeGroundWindow(AppB_Hwnd)
HandleMessage
SetForegroundWindow(AppA_HWnd)
This has been working for years without incidents, that is, until we started rolling out Windows 10. We started receiving reports that a random app (AppC) was sometime getting the focus when we closed AppB (Actually, given our user's tech expertise, the report were more along the line "Closing AppB kills AppA" but I digress). That behavior can be reproduced occasionnaly(<5%) on dev machine (But not yet while debugging...)
So far, test result suggest AppC is the application that had the focus before AppA.
Is there a way I can ensure AppA gets the focus back when AppB closes?
Extra notes
The problem can be reproduced even if AppA only ever loses focus to AppB. (AppC never being focused after AppA started)
While this does not directly answer my original question, it does give some more insight on the problem and might be useful to someone else.
Part of the issue was an oversight on our end. More specifically, the way we obtained AppB_HWnd. We basically picked the first top level window we encountered. In our current test case, that window happens to be an invisible windows ('MSCTFIME UI'). Calling SetForegroundWindow on an invisible window doesn't seem to cause problems per se, Windows seems to just bring to front one of the process' visible window. It is when said process does not have any visible windows left that things seems to go awry. That usually happen in our case between the moment AppB's main window is closed and the moment the process ends.
So... Don't call SetForegroundWindow on an invisible window
As for why we didn't have any trouble in Win7? Maybe the first window was always a visible one. Or maybe SetForegroundWindow behaved differently back then.
If my wxWidgets application creates a new window while the application does not have focus, its taskbar icon blinks yellow until I switch to it, as shown here:
This is annoying. How can I prevent this from happening?
EDIT: The original version of this question suggested the blinking was happening during startup. After further investigation, this is not occurring right at application startup; rather, it occurs if I create an additional window while the application does not have focus.
To give a bit more background: my application is a sort of server, that opens windows in response to network events. If I boot up the application, then switch focus to something else and a network event comes in while the focus is elsewhere, my application will open a new window in the background (not grabbing focus) and this blinking will occur.
The windows are wxFrames; the application constructs them and their child widgets, then calls Show(true) on the frame.
Also, I've attempted to set a breakpoint on the FlashWindow Win32 API function, hoping to trap wherever in WX it's getting called, but haven't been able to make that work.
Maybe the following would work:
wxTopLevelWindow::ShowWithoutActivating ( )
http://docs.wxwidgets.org/trunk/classwx_top_level_window.html#a03e526f505716568318d601318527bd0
Yes. If you create a new top level window while the app does not have focus, then the task bar icon will flash. This is the intended behaviour of the windows operating system.
I understand that Chrome using re-parenting in order to have child plugins such as Flash render from different processes.
I have experimented with this, and I have got it working using the SetParent Win32 call.
However, when I force the child GUI thread to block, the parent process will also hang as soon as the mouse moves over a the window area owned by the child process. Presumably this is because the message loop in the parent application is calling down to the child and it never responds. How does Chrome get around this?
Flash uses the re-parenting trick. It has its own .exe and renders to its own window. That doesn't prevent hangs, any message that is sent from that window to its owner is going to block when the owner isn't pumping messages. As you found out.
Browsers uses a different trick. They create an invisible helper process for each tab and render to a memory device context. And blits the result to their desktop window. Any input messages are shuttled back to that process. That makes them immune from crashes and hangs in that process, killing that helper process keeps the browser going. Much harder to do yourself.
To all Win32 professionals. Let's say we have completed existing application with window. The task is to write another application with (my) window. My window must always align its left edge to existing window right edge while user moves existing window across the screen (my window not allowed to move by user).
Precondition: a) Existing window can not be subclassed b) Windows hooks are not a case.
Yes, looks right. I'd not asked this question if it not become a problem. Forgot to say that OS is Vista 2, application is IE. I try to make an application that follows IE main window, align it edge. Subclassing of IE not allowed, and SetWindowsHook not works correctly under regular user (when user have admin privileges application works normally). Such way as all of you talking about works under Windows prior to Vista.
And looks like there is no trivial way to solve this task. Thank you all.
I think you can't without a hook. SetWindowLong allows you to set a WndProc, but this won't work if the window belongs to a different application.
If you dont want/cant subclass or set global hooks, you can look into the following:
Implement your code in a DLL
Call CreateRemoteThread on LoadLibrary's address and your DLL's name to inject your DLL into the target process
In the DLL's DllMain, you can SetWindowHook just on the thread that owns the window. This is a local hook and doesn't require special privileges and is very nice to the system.
In your hook function, process WM_WINDOWPOSCHANGED on the main window's HWND and adjust your window accordingly.