I have an IE Browser Helper Object (BHO) (written in C++) which records the height and width of iFrame(s) and the Main page when it receives a document complete notification (OnDocumentComplete). This code has been running fine up until now (all older Windows and IE versions) but has stopped working in IE11 (desktop) on Windows 8.1 for iFrames. Getting the width and height for the Main page still works.
I am using the get_Height and get_Width functions from the IWebBrowser2 interface. A call to these functions now return an error, 0x80004005 (Unspecified error) and the height and width returned back is 0.
Has anyone encountered this issue? It sounds like this could be a bug in IE11. Any help will be appreciated.
Thanks!
I've observed that IE9+ (including IE11) seems to fire onload= type DOM events "early," before the entire DOM is loaded. In particular in my case where I've got the browser DOM loading an SVG document. Webpages having <object> tags in them might be another risky area. My work around was to catch the onload= event, then wait another 0.75 seconds for the DOM to settle down. An imperfect, crazy hack, but it seemed to help.
Related
I'm writing a plugin for a big x64 application in C++. I want the plugin to open a dialog and show a web view of my site.
I'm been able to use WKWebView in macOS and it works well. On Windows I'm evaluating CEF https://bitbucket.org/chromiumembedded/cef (please let me know of any alternative, ideally I would like it to be Webkit-based).
Let's say the application framework that is hosting my plugin has already created a window for my plugin and has it's own message loop, so I can only receive events in a sort of WindowProc. I can also get the HWND of the window.
My implementation is inspired by cefsimple example, because cefclient is way too complicated. I've implemented the subprocess architecture with the external executable and everything works fine until it's rendering the client area of the window. Then I have problems with closing the window (it crashes) and resizing the window interactively (the window frame is resized but the web view in the client area does not resize).
I've tried all possible combinations, but I've run out of ideas. Namely:
If I use CefRunMessageLoop() the web view is rendered correctly but the main application does not process the UI events like close window button. Resize does not work.
If I call CefDoMessageLoopWork() myself once in a while (from WindowProc) the web view is rendered correctly and it processes the close button, but it crashes. Resize does not work.
If I use settings.multi_threaded_message_loop = true the web view is rendered correctly and I can close the window without crash. The destructor of the window calls CefShutdown(). But if I try to reopen the window it crashes! Are CefInitialize and CefShutdown allowed to be called only once?
And resizing still does not work. I don't understand why in the cefsimple example resizing works and in my window it does not work.
Besides message processing issues, probably I'm not closing the browser correctly, any advice? Why is so complicated? WKWebView is so straighforward!
There is no error message, no stack trace, no source code, no OS/CEF version - I doubt this question can be answered.
I can only tell you how to close browser cleanly: call CefShutdown at the right time (see cefclient/cefsimple examples) and do not keep any references to CEF objects when calling shutdown.
I'm trying to use SendMessage to post mouse clicks to a background window (Chrome), which works fine, but brings the window to front after every click. Is there any way to avoid that?
Before anyone says this is a duplicate question, please make sure that the other topic actually mentions not activating the target window, because I couldn't find any.
Update: aha, hiding the window does the trick, almost. It receives simulated mouse/keyboard events as intended, and doesn't show up on screen. However, I can just barely use my own mouse to navigate around the computer, and keyboard input is completely disrupted.
So my question is, how does sending messages to a window affect other applications? Since I'm not actually simulating mouse/keyboard events, shouldn't the other windows be completely oblivious to this?
Is it possibly related to the window calling SetCapture when it receives WM_LBUTTONDOWN? And how would I avoid that, other than hooking the API call (which would be very, very ugly for such a small task)?
The default handling provided by the system (via DefWindowProc) causes windows to come to the front (when clicked on) as a response to the WM_MOUSEACTIVATE message, not WM_LBUTTONDOWN.
The fact that Chrome comes to the front in response to WM_LBUTTONDOWN suggests that it's something Chrome is specifically doing, rather than default system behaviour that you might be able to prevent in some way.
The source code to Chrome is available; I suggest you have a look at it and see if it is indeed something Chrome is doing itself. If so, the only practical way you would be able to prevent it (short of compiling your own version of Chrome) is to inject code into Chrome's process and sub-class its main window procedure.
I have a property sheet view with few property pages. One of this property page contains a HTML representation via a CHtmlView derived class.
Initially, the .html file is correctly rendered. The problem is that sometimes switching between properties pages sometime the html file is not redraw. The behavior appears randomly.
According to Spy++ in such situation some Windows messages are not sent by WebControl (Internet Explorer_Server layer): WM_ERASEBKGRD, WM_PAINT or WM_NCPAINT.
Approaches such Q179421 or Q183161 are not useful. My machine runs IE 10.
The windows hierarchy is: Shell Embedding -> Shell DocObject View -> Internet Explorer_Server.
Do you know any workaround that would determine Internet Explorer_Server layer to send these messages always?
Update: Even if in the real application I make some intensive processing, I was able to reproduce this bug even with a dummy Html content.
I have a NPAPI plugin running in Safari, Chrome and Firefox. I'm able to handle all key combinations with the event callback, but the problem I'm having is with certain key combinations.
In the plugin, I'm trying to use Command+O to fire the plugin's file open dialog, but the browser is also firing its open file dialog.
Supposedly, returning TRUE for event handling method should report the browser that the plugin handled the event, but I'm having no luck with that.
You neglected to specify which OS you're on; based on the fact that you said "Command+O" instead of "Ctrl-O" I'm assuming you're on Mac. The bad news is that on Mac, all events are passed to the plugin from the browser. If the browser doesn't choose to make it possible to override the handling of an event (and it sounds like this is the case) then there is probably nothing you can do about it, short of possibly using some OS hook to intercept the key event before the browser gets it, which seems risky.
On windows you might have a little more luck, since a windowed plugin should actually get events first before they are passed to the parent window and thus could intercept them. On Mac, though, it's all windowless and you get events when the browser feels like giving them to you.
I have a strange issue I've been unable to diagnose and am hoping someone can at least point me in the right direction. I have a C++ MFC application that collects data from various sources and displays it on the screen. After a random interval (typically around 5-10 minutes), however, the display gets "corrupted" in a way I've never seen or have been able to track down as shown in the image below (left is normal, right is corrupt):
The basic symptoms are:
Up/down arrow images turn into "5"s and "6"s.
Opening a combo box list results in just the item text displayed (list border and scroll bar is not shown).
Background colours on some controls don't update or display correctly.
Z-order is broken and the app controls "leak" through other windows placed on top.
Pressing Print-Screen with the app in focus no longer captures the window to the clipboard.
Closing and reopening the window does nothing.
Restarting the application gets things back to normal.
Things I've tried to eliminate as a possible cause include:
Operating System & Computer: The same issue is present on a variety of systems from Windows 7-64 bit to Windows Xp-32 bit.
Multi-threading: I added a mutex to prevent the display updates from occurring at the same time but it had no effect (as expected).
Memory Corruption: This has been my assumption all along but there are no signs of memory corruption at all. The base display code has been used for years with no similar issue as well as the base networking message library.
Specific Code: I have narrowed down the issue to one specific dialog among a variety of others that show no issue. They all use the same base code which would seem to indicate the issue lies in the specific display code for the dialog. Exactly how or why the issue occurs has eluded me so far.
Any ideas on what the cause might be or how to narrow it down would be great.
Update 1:
Doing some more timing/repeatable tests and it looks like leaving this one dialog running for a short while causes the issue. The amount time is consistently between 300-400 seconds before the issue shows up.
It sounds like your application could be leaking GDI objects. To check if that is the case, open your task manager and enable the GDI Objects column. Observe the number for your process and see if it's increasing continuously.
If that is actually the case, you should read Detect and Plug GDI Leaks in Your Code with Two Powerful Tools for Windows XP. That MSDN article also offers a tool named GDILeaks.exe that should help you identify your GDI Leaks.
In the case where these symptoms surface within a short time, it should be something that is drawn repeatedly that isn't freeing GDI resources properly. Possibly in (or called within) the windows procedure (OnPaint for example).
If I'm not mistaken Windows' GUI uses a ttf(?) font for those little icons, and it looks like the font gets destroyed somehow (DeleteObject being called with font's handle?)