I have a Direct2D app where I draw text messages with DirectWrite. It's all C++. I want to add an edit control which must support emojis and a button on the right. Does Win32 edit controls and buttons can be used in a Direct2D window and is the text button rendered with DirectWrite or with the old GDI?
Thanks you
No GDI-based common controls in comctl32.dll use DirectWrite to draw text (too many compatibility concerns), but many newer parts of the Windows 10 shell use DirectWrite - anything based on DUI or XAML, like the Start menu or system Settings app.
Per Simon Mourier's comment, I wrote an SDK sample years ago called PadWrite that demos a very basic edit control, but I can't recommend it as a serious text editor because it recreates the IDWriteTextLayout object every edit. So it's best for just a few lines or paragraphs of text, as a smarter editor would selectively update only the parts of the text that changed. This works on Windows 7, but Windows 7 itself had only basic emoji support (monochrome glyphs in Segoe UI Symbol). Not until Windows 10 (with Segoe UI Emoji) did it really become colorful.
The newer RichEdit is also a viable option (I forget which flags enable it).
I've tried to subclass the standard EDIT control to intercept WM_PAINT messages (along with Edit_GetRect, GetDCEx, DefSubclassProc), but that's brittle because the HFONT does not always match the same metrics as the corresponding IDWriteFontFace due to font fallback and metrics differences between GDI vs DWrite, meaning your drawn text may not match the glyph advances the underlying EDIT control uses.
WinUI should work nicely if you can take a dependency on >= Windows 10.
There's also the Scintilla text editor which supports a DirectWrite mode. https://www.scintilla.org/ScintillaDoc.html (set SCI_SETTECHNOLOGY = SC_TECHNOLOGY_DIRECTWRITE). This will work on >= Windows 7 (or Vista with SP2 Service Pack Platform Update).
Related
When I create a window or custom control with wpf inside Visual Studio the default font used is Segoue UI 12 (at least on Windows 7). When I execute the application the font really used is Verdana 13, a bit greater, so some signs are cut and the user experience is a poor formatting look and feel. Don't know how to change the default font inside VS 2010 and if it is the best way to achieve the goal of aligning what I see during the design phase and what the user will see at run time.
I checked for the word 'Verdana' in the entire solution and it was not found so I'm quite sure this weird behavior is not due to a style which is applied as a dynamic resource.
Thanks for any help
Filippo
By default, WPF uses system font in runtime. If you want to always use Segoe UI, you can set FontFamily property to "Segoe UI".
This question already has answers here:
How to create custom window chrome in wpf?
(5 answers)
Closed 6 months ago.
We are developing a WPF application which uses Telerik's suite of controls and everything works and looks fine. Unfortunately, we recently needed to replace the base class of all our dialogs, changing RadWindow by the standard WPF window (reason is irrelevant to this discussion). In doing so, we ended up having an application which still looked pretty on all developer's computers (Windows 7 with Aero enabled) but was ugly when used in our client's environment (Terminal Services under Windows Server 2008 R2).
Telerik's RadWindow is a standard user control that mimicks a dialog's behaviour so styling it was not an issue. With WPF's Window though, I have a hard time changing its "border". What I mean by "border" here is both the title bar with the icon and the 3 standard buttons (Minimize, Maximize/Restore, Close) and the resize grip around the window.
How can I change the looks of these items:
Title bar color
3 standard buttons
Window's real border color
With round corners if possible.
Those are "non-client" areas and are controlled by Windows. Here is the MSDN docs on the subject (the pertinent info is at the top).
Basically, you set your Window's WindowStyle="None", then build your own window interface. (similar question on SO)
You need to set
WindowStyle="None", AllowsTransparency="True" and optionally ResizeMode="NoResize"
and then set the Style property of the window to your custom window style, where you design the appearance of the window (title bar, buttons, border) to anything you want and display the window contents in a ContentPresenter.
This seems to be a good article on how you can achieve this, but there are many other articles on the internet.
I found a more straight forward solution from #DK comment in this question, the solution is written by Alex and described here with source,
To make customized window:
download the sample project here
edit the generic.xaml file to customize the layout.
enjoy :).
Such statements as “you can't because only Windows can control the non-client area” are not quite true — Windows lets you specify the dimensions of the non–client area.
The downside is this is only possible by calling Windows' kernel methods, and since you're in .NET, which is not native code, you'll need P/Invoke. (Remember, the whole of the Windows Form UI and console application I/O methods are offered as wrappers that make system calls under the hood.) Hence, as documented in MSDN, it is completely possible to use P/Invoke to access those methods that are needed to set up the non–client area.
Update: Simpler than ever!
As of .NET 4.5, you can just use the WindowChrome class to adjust the non-client area. Get started here and here, a guide to changing the window border dimensions. By setting it to 0, you'll be able to implement your custom window border in place of the system's one.
I suggest you to start from an existing solution and customize it to fit your needs, that's better than starting from scratch!
I was looking for the same thing and I fall on this open source solution, I hope it will help.
I made a demo application using Silverlight where I have given certain Unicode of Hindi language to be displayed on a textbox as a text. ऋ ऊ उ ई इ आ, unicode positions are '\u090B', '\u090A', '\u0909', '\u0908', '\u0907','\u0906' respectively.
So when I pass this whole thing as a string to the textbox.text property it shows at the debug time as the exact value is to the textbox but when I go through the emulator the display shows empty boxes.
Is this require installation of different fonts on emulator? If so then how can I do this? Is it possible to build an application for Windows Phone 7 which can support different languages?
You can embed fonts in your WP7 applications in the same way that you embed fonts for any Silverlight application as decribed in the Embedding fonts in Silvelright blog post by Paul Yanez. You simply check the Embed checkbox in the Text pane in Expression Blend.
NOTE: You will need to make sure that you are licensed to use the font in this way or that it is free for use in this way.
We have a couple of winforms applications that host a bunch of icons in a ListView control as a handy quick launch down the side of the applications. We also have "XP visual styles" enabled in the project build options for both which works great for Windows XP, but we've had someone highlight that the items in the control are (roughly) twice as wide in one application as the other (normal) when both are run under Windows 7.
As far as I can see in code, both ListViews are added to their respective forms using the windows forms designer, and there doesn't appear to be anything fiddling with the width of the labels (etc.)
I'm a little confused why the two applications/ListViews are behaving differently, and also why there doesn't seem to be anything I can do to affect the width of the items in the ListView? What have I missed when checking for differences between the "working" scenario and the "non-working" scenario?
It appears that setting the StateImageList property causes this (even if it is the same image list as used for the normal icons)
I have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.