AndyB wrote:I have implemented now WinForms (windowed rendering) and WPF (offscreen) based on your sample projects.
WinForms works great so far, i published a beta version of my app today with this option, hope i get no issues reported back.
WPF basically works, but:
1) Tooltips are displayed a bit "shake".
I think because in the sample, each change of the tooltip adds an additional event handler to _tooltipTimer.Tick.
After changing this it works fine.
2) The context menu does not close when i click on a free area.
I worked around this by displaying a custom context menu.
3) No touch screen support.
That's a key requirement for me because my app is used on tablets (Microsoft Surface)
I have implemented a custom touch scroll, using Manipulation events and SendMouseWheelEvent, works ok for me.
4) No good HighDPI support, text looks too bold and blurry.
Maybe i take a look on this some time. CefSharp works fine on this point, so i probably look how they do the rendering.
Thank you and all others for this awesome project!
CefGlue WPF OSR sample has been created from contribution of one of CefGlue user. It is very far from "just use" usage. So even bugs are exists. I'm use it only as OSR demo and some quick-tests. WPF also chosen... because it has been chosen in initial implementation. I.e. demo's goal is demo of OSR capabilities rather than ready to use WPF-centric control.
For WPF or WinForms control we need create "brand-new" implementations. For WinForms it is not very needed, because it is usually already covers many aspects internally, as you mentioned. Projects which i'm touch personally are far from standard UI apps, so even when i'm need UI control - project has own implementation which adjusted as it needed to best suit to whole project without worrying about unneeded feats. If someone want to create WPF and WinForms controls (i'm mean design it in first place - implementations are more trivial), then i'm like to accept this contributions. But from design point it is not very easy: control need CefClient and related things. CefSharp's way is based on interfaces, but i'm disallow this idea, because it is violates possible calls directions (you can see, that protected methods are called only by CEF, and public by client code in CefGlue). Also in CEF C++ headers all methods in handlers are public, but it is already considered as design error and they should be protected. And with interfaces we make possible to call this methods from both sides.
So... basically controls requires some concept and API. Also they should not hide CEF possibilities. For example control can introduce CefClientFactory and use CefClient provided by factory, but this is doesn't work well all times and with form designers to which some peoples stick forever. So... to effectively use CEF APIs - you need known CEF APIs. Due to nature of CEF - control can be work in same way as WinForm's WebBrowser work. When user has this knowledges - they usually are more advanced, and can accept more sophisticated APIs.
When peoples want easy-to-use control - i'm always suggest CefSharp actually. CefGlue is for peoples who more like access to nearly raw CEF API. Generally i'm started CefGlue in times when CefSharp doesn't cover even 90% of CEF API, and any addition requires CefSharp recompilation. And it that times it is also required custom CEF build... what was a pain (it was CEF1 times.) Now CefSharp is much easier in all senses: good/complete or nearly-complete CEF API coverage, has ready-to-use WPF (OSR-based) control has WinForms-based control? and has lot of samples which CefGlue misses and work on standard CEF builds (again - in past times it always required custom build, while CefGlue was aim to utilize standard builds without touching C++/CLI.)
So back to your notices:
1) Tooltips - i'm think it was bug initially and never noticed in first place.
2) The context menu: looks strange, but custom menus definitely should be a way to go.
3) OSR+touchscreen: CEF misses this, has
PR #104 Touch processing for OSR, different API. But again, it will require event translation... which is not very easy to debug/make correct. Current sample doesn't uses WM_POINTER message for modern systems, so... So, again, in cases when you not needed OSR - good choice is windowed browser which do it internally and chrome team worry about such details.
4) No good HighDPI support, text looks too bold and blurry: i think sample code just doesn't do nothing about (starting from correct app.manifest), but OSR already has all required abilities to do it correctly (device scale factor should be provided by CefRenderHandler).