I've spent two months creating an immaculate WPF browser app using the CefSharp embedded Chromium web browser. Now it was revealed that this browser must work with IME input methods, which it does not. Essentially, the WPF browser is rendered off-screen, with screen images and input events marshaled back-and-forth.
When the IME is invoked, text entry occurs in a popup tool-window outside of the app, typically in the upper left corner of the desktop. Once input is accepted, the input is not being marshaled back to the browser.
Is it possible to make the IME appear, as normal, next to the input-field?
I would appreciate some pointers on where to start reading or coding. If this takes a month to implement, I'm sure it will happen.
update -
It looks like the keys OemAuto and ImeProcessed are being previewed by the WPF browser control (but not passed to the off-screen browser). Passing those keys to the off-screen browser prevents the IME window from appearing. I'm not sure if this is progress or not. :)
update -
I think I'm going to roll my own window message loop to forward IME and input events to the browser. Maybe I can get the browser to handle IME events on its own?
update -
Off-screen IME support does not seems to be implemented on Windows (only Mac)
CEF3: Windows: Enable IME when Off Screen Rendering is enabled. I'm continuing to explore my options.
I threw together a quick hack posted as part of the discussion in https://github.com/cefsharp/CefSharp/issues/583 ... but as the proper place to resolve this really is in the CEF codebase I'm hesitating to add the hack the the CefSharp codebase (I'm afraid of side effects for those not needing IME support).
Anyway I hope the CefSharp issue #583 is helpful in bringing you towards a solution - either via the short term hack - or preferably leading to resolution of the CEF issue you already dug up yourself!
Related
Possibly this is better asked on a different StackExchange site, or just reported as a bug to Microsoft, although I'm approaching this as an app developer.
I have my Win10 box configured so that pressing PrtScrn runs the Snip & Sketch overlay (the screen fades and controls appear at the top of the screen, allowing selection of a rectangular or other area to specifically snip, rather than capturing the whole display). This normally works fine.
However, I have noticed that whenever I have a WPF app focused, pressing PrtScrn is apparently intercepted and silently copies the whole screen to the clipboard instead of displaying the Snip & Sketch overlay, as in previous versions of Windows or with Snip & Sketch disabled. Presumably somewhere in the framework WPF is intercepting this key and doing its own thing, or otherwise interfering with Snip & Sketch's hotkey.
I can work around this by focusing a different app while keeping the WPF app visible and then pressing the key, which allows capturing the WPF app. But this is inconvenient and silly.
As an app developer, is there some way to disable this interception so that (at least for my apps) PrtScrn works as intended?
Google Chrome does not refresh accessibility elements (AutomationElement) when a user scrolls down in the browser.
To reproduce it:
Enable renderer accessibility with : "chrome --force-render-accessibility" or by setting on Global Accessibility at "chrome://accessibility".
Go to http://en.wikipedia.org/wiki/Google
Open inspect.exe in UI Automation Mode (from Windows Kits), look for "Links to related articles" element.
Come back to Chrome, Scroll down until "Links to related articles" at the bottom is visible
"Links to related articles" element is marked off screen
I found some manual solutions that can force Chrome to refresh it:
Set Zoom to 90% then set it back to 100 % (very very ugly way)
Switch accessibility off then switch on in chrome://accessibility/
What I'm looking for is the ability to do one of these operations programatically, or any operation that can make Chrome refresh its cache tree.
What I've tried:
Resize window with PInvoke/MoveWindow
Redraw Window with PInvoke/Redrawwindow
Build a chrome extension and force zoom to 100% on demand: chrome.tabs.setZoom(null, 0); (working but blink and slow down the window)
None of these are working properly.
EDIT: Tested with Google Chrome 40.XX, 41.XX, 42.XX, 43.XX, 44.XX, 45.XX, 46.XX, 47.XX.Dev, 48.XX.Dev under Windows 7.
Scrolling in simple pages is optimized to not require computation from the renderer. Only the compositor and the GPU are needed to scroll therefore the render tree which is only updated from the renderer is still the same.
Requiring the renderer to traverse the DOM and update the Accessibility tree during a scroll runs contrary with the several years effort of having smooth scrolling, specially for touch devices so I don't think you are going to get traction on a bug fix.
Your idea of an extension I think is the best (although ugly) compromise. But rather that changing zoom, doing a small mutation of the page (or DOM) might be a better solution. Try for example adding a invisible (or nearly so) element with a low z-order. You will also need to rate control the mutation so it only happens 1 times per second or even less often.
Chrome's multi-process architecture is different from that of any other browser. For security, the main browser UI is in one process, and web pages are run in separate renderer processes (typically one per tab). The Renderer processes are the only ones with a representation of the webpage's DOM and therefore all of the accessibility information, but the renderer processes are specifically not allowed to interact with the operating system (sending or receiving events or messages) - in particular, the renderer processes cannot send or receive accessibility events.
I have whipped up a C# clipboard application that stores multiple 'clippings' for later use. I use low-level keyboard hooks to pop open my application's window(s) on command. When the window is closed (or a clipping is double-clicked), it is supposed to paste the selected clipping into the last active window (the window prior to my application's window). I use low-level WINAPI methods to determine the last active application, snag its handle, and then return focus to it before simulating a Ctrl+V keystroke to paste.
This typically works except in one very unique scenario: I am in a WPF application project, Quick Finding in a XAML file, the cursor automatically switches to the body text, not the Quick Find textbox, and pastes it there. It seems to have something to do with the loss of focus/activation, as it moves the cursor whenever I activate another window, regardless of my own application's running.
VB files, C# files, what have you, and XAML opened in WinForm projects do not steal the Quick Find focus when switching between the VS2013 application and my own; upon returning to the last active application, the text pastes into the Quick Find box.
Only the XAML in WPF application projects gives me this problem.
So far. I know it is a fringe case, but I expect to run into more. This program is meant to be used in a coding environment and it's pretty important that it be able to handle these kinds of scenarios.
I've tried getting the internal control handle using code from http://www.codeproject.com/Articles/34752/Control-in-Focus-in-Other-Processes, so that I can return the focus to it, but it seems that the handle for the body text and the handle for the Quick Find text box are the same.
A partial solution is found in: How do I prevent the original form from losing focus when I show another form? The popup window I use is navigated primarily through my low-level shortcuts, and therefore has no need of explicit activation.
Using the mouse on it or any of my other windows (as I expect my users will sometime), will cause it to gain activation and circumvent this fix. However, it's such a fringe case it doesn't seem to matter. Hopefully this helps anyone in a similar situation (if not necessarily specifically this one).
When I set focus on a text box, on a forms load event in Windows Mobile 5.0, the Windows tool bar appears even though my form is maximized.
When I do not set the focus on the text box the form opens maximized. I do not want the windows tool bar appearing.
How do I prevent this from happening?
TThe start bar in WinMo is actually not part of your app - it is a separate process managed by the Shell and it really wants to always be on top. Trying to get your app above it goes against the design goals of WinMo (though it's a common thing to want to do).
I'd recommend doing some searching and reading on "kiosk mode" to garner what knowledge you can from others who have been down this road, but what you're seeing is that the StartBar is getting set topmost.
Raffaelle Limosani has a pretty decent blog entry that covers kiosk mode, so it's a good place to start (take a look at the other blogs he links to as well).
The toolbar at the top is actually a separate window, and it has a habit of appearing when not wanted over top of a full-screen ("kiosk" mode) app. For example, if you ShowDialog a second full-screen window from the first, the Start window flickers up for a split second before going away.
The only way I ever found of dealing with it was to hack into the API and actually make the Start window hidden while my application was open. This is a big potential problem, because if your app crashes without making the Start window visible again, it will stay invisible until you reset the device (or run you app again successfully).
I'd advice against doing this unless you absolutely have to. As ctacke points out, this would be an example of an app not playing nicely with Windows Mobile.
I was asking myself how the browsers are working. How does the browser tell to the OS to change the mouse pointer from arrow to hand(IDC_HAND) for example. In desktop application I know that are used windows messages(right) but how it is happening in browsers? Spy++ doesn't seems to catch any of the mouse pointer messages in this case. Can you help me with an explanation?
I'm trying to build a C# application which will detect the type of the mouse pointer.
You can define a specific cursor for each window class. Consult the documentation for the function RegisterClassEx and structure WNDCLASSEX
HTH.
The browser viewport is a simple window with hardly any standard events. A page is rendered by pixel and treated later as a bitmap. A browser builds an hierarchy of web page controls and display elements and keeps it in memory. Whenever mouse moves across the page, the browser algorithms search through this hierarchy to identify whether these particular coordinates belong to, say, a button or a link and then change the cursor to pointer. In short, it's what a browser engine is all about. Parse HTML to an hierarchy of controls, then parse CSS and update properties of these elements then render the controls under consideration of their properties to a viewport, then process user input and when required initiate a request. Browser engine also executes JavaScript code and performs manipulation on the document structure.
Remember also that FireFox exists for Linux as well in which case it would make no sense for browser developers to work with standard windows events. Some basic initialization code is definitely platform dependent but after the window is prepared and user input is forwarded through some abstraction layer to the core, then the browser engine leads the play with no concern for the underlying operating system and its event system whatsoever.