On a WinForm with an extended borders, when i place a text on the glass area it doesn't appear right.
This is how the text looks like Status
a busy cat http://img833.imageshack.us/img833/4732/95454282.png
![form][1]
how can i fix the text to appear normally?
Text in Winforms is rendered with an alpha of 0. Which makes it transparent when you draw on glass. So you'll see the background color, not the ForeColor you selected.
Drawing text on glass is troublesome, you can't get it easily anti-aliased correctly since the background of the text isn't well defined. Note how the screenshot shows how Windows addresses that problem, the text in the window caption has a milky-white background, thus ensuring that the anti-aliasing properly blends the letter into the background.
Which is what you need to do as well. You get text drawn like that with pinvoke, DrawThemeTextEx() with the DTT_GLOWSIZE flag option. Visit pinvoke.net for the required declarations or use this project. And don't forget to provide a fallback so this window still looks decent on older Windows versions. And newer versions, glass is no longer appropriate for Windows 8.
Related
I would happily provide a screenshot of this, however the problem is the captured image, is much larger than my actual desktop.
I am completely frustrated with this as I have tried using BitBlt with the desktop hdc AND the new "Graphics" commands.
My actual desktop resolution is 1920x1080 - 1080p .
BitBlt and "Graphics" both return that my resolution is 1536x864 # 96 DPI.
A form (WinForm), Maximized, borderless, and irrelevant of scaling mode the form is set to, also shows 1536x864 # 96 DPI.
Now the image that is captured, is like it is being done from 1920x1080, but clipping the region 1536x864 as the screenshot.
If I do PrintScreen directly using Prtscn button, I get the entire image, but still it is about 1.5-2x larger than what I actually see.
What I am looking for -- is a resolution for how I can take a picture of what is on my screen in the scale/dpi/whatever is going on here that it visually looks like. I have written a screen capture program, and using a few different examples for the RubberBand form (overlay form to select a region of the screen by drawing a box), and as you can imagine, this scaling crap is causing those box captures to be offset, and the contents are zoomed.
This is very annoying -- even to explain, however I am positive that most of you are familiar with the terms I use, and also know what to expect from taking a screenshot, so my explanation above should be pretty clear as to what my problem is.
Example/Consideration
Imagine, taking a picture of a window that is 300x300, and getting the top left 150x150 of that zoomed to 300x300 completely skipping the remainder of the window. Resulting image is still 300x300, but it's not what you selected.
Now imagine, you grab a picture of your screen by the only dimensions you can get programmatically, and then put the image into a picturebox. Even though both your screen and the picturebox claim to be the same dimensions and dpi, the image in the picturebox requires scrolling even if the picturebox is maximized to fullscreen on a borderless with no borders / etc. -- again, the picture is zoomed, but how is it still reporting that it's the same size as the form XD (comparing Graphics or BitBlt dimensions with the actual form. also tried comparing picturebox contents, and still same effect)
This, is EXACTLY what the effect is that is happening. When I try to capture a region or segment of the screen. I am not sure why windows api/crl is lying about this seemingly trivial stuff, however there must be a way to accurately obtain screenshots/capture regions without this faux zoom effect -- across all resolutions.
Thank you Hans Passant for pointing me in the right direction.
To add "true" dpi scaling support to a winforms application, you can make it so by adding the following block to your manifest :
Project > Add New Item > Visual C# Items > Application Manifest File
One the file has been added, open it up and look for a line like
</asmv1:assembly>
Whatever the "asmv" number is, (in the example above it is 1), use that to format the code:
<asmv1:application>
<asmv1:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv1:windowsSettings>
</asmv1:application>
Paste the above code (changing the asmv1 to whatever version the manifest is), just above the final closing line for the ""
Also, make sure your forms are set to AutoScale to dpi (and all sub-elements).
I work on gschem, a free software tool for editing electronics schematic diagrams. Recently we have encountered a problem using a GtkScrolledWindow containing a GtkTextView.
Context
Recent versions of Ubuntu use overlay scrollbars, which mean that GtkScrolledWindows no longer set a minimum height that provides enough room for a legacy scrollbar (in fact, they have a minimum height of 0). Likewise, a GtkTextView with no text to display requests a height of 0. This means that one of the scrollable GtkTextViews in gschem has been being displayed as one pixel in height, and this is obviously unusable.
In the dialog box on the right of the screenshot shown above, note the invisible widget between the "Value:" label and the "Add" button.
This has been reported independently by several users -- see also the bug report.
Question
Obviously, we could fix this by doing:
g_object_set (textview, "height-request", 100, NULL);
However, this is pretty inelegant, and will break for users who set very large font sizes in pixels (e.g. users with vision problems or who use high-DPI screens).
Ideally, therefore, we want to set the minimum size of the GtkTextView relative to the default font size, e.g. tell it to "show at least three lines of text".
Can anyone suggest a sensible/elegant approach for doing this?
Just disable the ubuntu overlay scrollbars in your application by doing:
putenv("LIBOVERLAY_SCROLLBAR=0");
Not ideal, but it's a quite good until you can find a more permanent solution. Alternatively just wait until Ubuntu disables overlay scrollbars...
I would add code to dig out the current/default style information, use that to figure out the font baseline height, and then compute some rough size allocation based on that, around three lines as you mention.
Does it have to be a textview ? If you can use an eventbox instead, then you can make a cairo surface from it, render the text with pango, and then use pango_layout_get_size() to get the text height.
Likewise, a GtkTextView with no text to display requests a height of 0.
Probably you can create GtkTextView with some text inside. Like several spaces, and set empty value after creation.
So the new WPF 4 text rendering looks great, but enabling the aero glass effect on a window requires that you change the background to transparent, which of course disables ClearType rendering.
Using the provided RenderOptions.ClearTypeHint=Enabled allows you to designate child elements to reenable ClearType rendering from that point in the tree. I've found a few other topics that talk about doing this for the ScrollViewer used internally inside RichTextBox and FlowDocumentScrollViewer, and creating a custom style does indeed fix it so that my FlowDocument gets ClearType rendering again.
However, this only applies to top level paragraphs in the FlowDocument. If I add floaters or figures, or a table, any text inside them is inexplicably grayscale again. I know that the glass effect is to blame, since disabling it reenables the ClearType rendering.
I looked through the visual tree with Snoop, but both the main content (which renders properly) and the sub-content (which is grayscale) have similar element hierarchies without anything to which I can attach RenderOptions.ClearTypeHint.
Has anyone run into this problem? Is there a workaround or a solution? I checked Connect but there isn't any bug filed about this. It's quite an annoying problem.
After doing a lot more research, and comparing the way different controls work on and off of aero glass, I've found a few answers. The TextBox control doesn't work properly either, but portions of FlowDocument and things like TextBlock do, which prompted me to explore why.
After digging around in reflector for a while, I found that when using the advanced text formatting APIs to get text and render it onto a drawing context, the RenderOption flags essentially go ignored, since the drawing system knows from the root visual (the window) that transparency was enabled. Once that happens, all the RenderOptions flags in the world aren't going to get ClearType back.
I did happen to stumble on a work-around though. If you have access to the DrawingContext and are doing the low-level text rendering yourself, you can do a DrawRectangle behind the text with a fill, and ClearType gets reenabled. I assume that this is the only way for the renderer to be sure that it has a proper background to draw on.
So in summary, you need to do your own text drawing, and additionally you need to explicitly draw a background using the same DrawingContext behind your text in order for ClearType to get rendered properly.
I know this could get tedious, but have you tried setting general styles like so:
<Style TargetType="Paragraph">
<Setter Property="RenderOptions.ClearTypeHint" Value="Enabled"/>
</Style>
I'm using DwmExtendFrameIntoClientArea in my WPF application to get the glass effect. This is working fine. What I'd like to do is change the colour used for the glass -- I'm writing a countdown timer, and I'd like the window to be the normal glass colour most of the time, and then to go red (but still with glass) when the time runs out.
I found this question, which talks about how to apply a gradient glass, and that works fine when picking a different colour. Unfortunately, the borders are not coloured appropriately.
When I turn off the borders by using ResizeMode="NoResize", then I end up with square corners. I'd like to keep the rounded corners.
I looked at creating an irregularly-shaped window, by using AllowTransparency="True" and that works fine, but doesn't look like an Aero glass window. It looks a bit flat.
So: my question: how do I create a window in WPF that looks like Aero glass transparency, but uses a different colour?
I think the only possible way to achieve this is to use a semi-transparent filled border and draw it over the entire window or the part you got the glass. Its a workaround but I guess it's a possible solution since the color of the glass gets defined by the system-user and this setting would overwrite yours.
I'm asking the same question myself.
I haven't found a good solution, though the best I've come across so far is doing the following:
HwndSource.FromHwnd(hwnd).CompositionTarget.BackgroundColor = Colors.FromArgb(100,255,0,0);
Unfortunately this tints the minimize, resize and close buttons, which I would rather avoid.
When a child window of my application is opened and I view the ALT+TAB menu, the application icon looks pixellated. I assume that Windows uses a low resolution version of the icon (16x16 pixel I think). What can I do that Windows selects the right version which would be 32x32 pixel?
I assigned an icon to the window in question that has 16x16, 24x24, 32x32, 48x38 and 256x256 in true color. Please note that VS says in the proterties that 32x32 is used and that it works fine for the main window of my application where I assigned the exact same icon.
The caption bar of a Windows application window display icons in 16x16 pixels. The Alt-Tab list, however, shows icons in 32x32 pixels. It uses the same icon as is set for the window. If you only set a 32x32 one, the caption bar has to scale it down, which tends to look ugly as it uses nearest-neighbor interpolation. So how does one support both?
The answer is the ICO file! It supports embedding multiple icons in one file, typically the same (or similar) icon in various sizes and, less commonly, color formats.
Browsers, Windows, and others are typically designed to smartly use the appropriately sized variant within a given ICO file. So the answer is to have an ICO file with both sizes (or more) inside. The result is that the caption bar correctly uses the 16x16 version and Alt-Tab uses the larger 32x32 one.
The methods for saving an ICO file with multiple icons inside varies from program to program. However, GIMP can easily do it (and it's free). The trick is to have your variously-sized icons as separate layers. When you go to save it as an ICO file, GIMP will prompt you with the ability to set the size and color format of each layer. A good tutorial, with images, can be read here.
If anyone has any links or suggestions for creating multi-icon ICO files in other programs, feel free to add them. Also, I'm unsure if the Visual Studio built-in image editor can do it or not — I've rarely bothered with it.
Fixed the problem. I put the icon on the wrong form. As I don't think that this question will be of any help for anybody feel free to delete it.