I'm using the ChooseFont system dialog to populate a LOGFONT structure that is passed to CreateFontIndirect and the resulting font handle is selected into the device context and used. But it doesn't resemble the requested font in any way (well, OK, similar character sets, but otherwise not the same). Here's an image of the screen showing the ChooseFont dialog selecting an old DOS-style VGA font and in the background (behind the ChooseFont dialog) shows the font that I got when I selected the values shown in the dialog:
Notice that the Sample in the dialog and what Windows puts on the screen when the created font is selected into the DC are quite different. This doesn't happen for ALL fonts, only some of them, which is why I'm trying to correct and/or detect this.
I've tried getting the LOGFONT for the new font from the DC using (GetCurrentObject and GetObject) and it is identical to my request, except that the lfQuality has changed to NONANTIALIASED_QUALITY from anything else I've tried setting it to.
I have a kinda two part question:
How can I force Windows to use the font I've selected. Obviously there is a way, or it wouldn't look right in the ChooseFont dialog, either.
If no one can answer #1, how can I reliably find out that Windows has selected a totally wrong font, when asking Windows for the font info about the created font when selected into the device context doesn't work?
EDIT: July 8
If this helps at all, my basic calling sequence is:
LOGFONT lf;
CHOOSEFONT cf;
HFONT hf;
cf.lpLogFont = &lf; // plus other necessary stuff
ChooseFont( &cf );
hf = CreateFontIndirect( &lf );
SelectObject( hdc, hf );
ExtTextOut( hdc, ... );
Then, when I use the font, it doesn't always match what I requested. At all. (I just tried using Arial Monospaced MT and was rewarded with Courier -- Lucida Console would be a better substitute, at least it doesn't have serifs!) I don't do ANYTHING to the DC other than call GetDC(). I don't call any GDI setup/configuration functions, either, so I'm in whatever default mode one gets with a standard Windows program written in C to the WIN32API.
I've discovered that the Windows version of PuTTY shows the correct fonts while my program doesn't, but I have not yet been able to find anything different between the functions/parameters it uses to handle font creation and the way I do it. I'll keep looking though. Thanks to anyone who's given my question any thought, with or without suggestions. :-)
Related
I'm currently getting back to some Windows Programming using Petzold's book (5th edition).
I compiled the following example using BitBlt and it doesn't work as it is supposed to.
It should copy the Window's icon of (CxSource, CySource) size and replicate it on the whole window's surface.
What happens, in reality, using Windows 7 is that the bitmap below the window gets sourced and copied into the drawing surface i.e. hdcClient.
I don't understand why it behaves like this knowing that it's clear the DC passed to BitBlt is hdcWindow, which refers to a device context obtained via a GetWindowDC(hwnd) of the current application.
I first thought it was due to the fact the transparency mode is enabled by default, but deactivating it doesn't change anything. BitBlt seems to always take the surface below the application Window!
I don't get it! :)
Anyone knows why it works that way and how to fix it?
Making screenshots with BitBlt() did not exactly get any easier since the addition of the DWM (Desktop Window Manager, aka Aero). Petzold's sample code suffers from a subtle timing issue, it is making the screenshot too soon. It does so while Aero is still busy animating the frame, fading it into view. So you see what is behind the window, possibly already partly faded depending on how quickly the first WM_PAINT message is generated.
You can easily fix it by disabling the effect:
#include <windows.h>
#include <dwmapi.h>
#pragma comment(lib, "dwmapi.lib")
And after the CreateWindow() call:
BOOL disabled = TRUE;
DwmSetWindowAttribute(hwnd, DWMWA_TRANSITIONS_FORCEDISABLED, &disabled, sizeof(disabled));
Another tricky detail is that the first BitBlt matters, the DWM returns a cached copy afterwards that is not correctly invalidated by the animation.
This gets grittier when you need a screenshot of a window that belongs to another process. But that was already an issue before Aero, you had to wait long enough to ensure that the window was fully painted. Notable perhaps is the perf of BitBlt(), it gets bogged-down noticeably by having to do job of composing the final image from the window back-buffers. Lots of questions about that at SO, without happy answers.
It is not supposed to copy the windows icon, it is supposed to copy the windows titlebar part where the icon is located.
There are some issues with this (now 20 year old code):
GetSystemMetrics values cannot be used for window related dimensions anymore since GetSystemMetrics returns the classic sizes, not the Visual Style sizes.
Depending on the Windows version, the DWM might define the window size as something larger than your window (where it draws the window shadow and other effects).
Your example works OK on XP:
(There is a small problem because the titlebar is not square (unlike Windows 98/2000 that this example was designed for) so you see a issue in the top left where it is just white. I also modified the example slightly so it varies the HDC source location)
On a modern version of Windows it seems like the DWM or something is not able to properly emulate a simple window DC and parts of the shadow/border/effects area is part of the DC:
I don't know how to fix this but the example is pretty useless anyway, if you want to draw the window icon you should draw the HICON with DrawIconEx. If you want to draw custom non-client area stuff then you need to find more recent examples, not something that only supports the classic theme.
I am writing a small GUI library in OpenGL for fun and profit. When it comes to font handling, so far I require the client application to explicitly load all fonts and set them on the widgets. So far this is ok, I also have a means to set them once as a default for all widgets of a certain type.
Although this is feasible, I though, would it not be dandy to use the system's default font as a default instead. In the case of Windows this would be the fonts that are configured though the Color and Appearance dialog.
After warming up my rusted Win32 programming knowledge and souring the MSDN I can't find an awnser to this question. I can load a font by name and set it on any widget, but figuring out what font Win32 would use as a default eludes me.
So far the best I have found is the SystemParametersInfo function with SPI_GETNONCLIENTMETRICS. But these are just the settings for the "non client" area, such as window title bar and such.
DEFAULT_GUI_FONT is not your solution. The name certainly sounds good, and indeed it was the default GUI font at some point in history, but that font hasn't been used in years.
You already stumbled upon the correct solution: calling SystemParametersInfo with the SPI_GETNONCLIENTMETRICS option. This will fill in a NONCLIENTMETRICS structure with information about the standard system fonts.
The "standard UI font" in that structure is called lfMessageFont. It is the one used for text in message boxes, dialog boxes, and elsewhere in the client area of windows. It is the same one configurable in the "Appearance" properties.
I wrote out a very detailed answer about fonts in Windows applications a few years ago. That one kind of focuses on MFC, so I've chosen not to mark this question as a duplicate of that other one and compose a separate answer, but really all of the information you need is there.
For fun, I'll throw in that you can get the system colors by calling the GetSysColor function. Pass one of the COLOR_* values to indicate which color you want; you'll get back a COLORREF value (typedefed as a 32-bit unsigned integer into which are packed the red, green, and blue component values of the color). Use the GetRValue, GetGValue, and GetBValue macros to extract the individual components; I doubt OpenGL wants COLORREF values.
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.
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.
I want to copy the contents of an existing Window to my own Window using Xlib. I have tried XCopyArea and it refuses to copy between two Windows. I have also tried XGetImage and XPutImage and it's also failing.
What's the best way to copy the graphics contents of a Window to my own?
Part II:
Based on information below, I was able to get XCopyArea and XGetImage to work. The reason it wasn't working was difference in depth of source and destination Window. I was surprised to learn that different Windows have different depth on my desktop.
But I still have limited success with XCopyArea. If I start copying from the top of certain Windows, like Google Chrome, it doesn't copy the full area, just the title bar. XGetImage works fine in those cases. Any clue on why XCopyArea won't copy beyond the title bar of some Windows?
XCopyArea should be fine.
Note that this will only copy into the foreground of the destination - maybe it is being drawn then erased?
Without code I can speculate:
If it is failing, have you checked that the windows definitely have the same root and depth?
Also make sure you review the X Window coordinate system. Maybe try copying so that the corner of your Copy is in the centre of the Destination to see if you can get anything.
You normally want some way of handling Expose events in the destination window so you can do a refresh.
I'd recommend creating a Pixmap as an intermediate. Both Pixmap and Window are Drawable.
Use XCopyArea to copy into the Pixmap.
Then use XSetWindowBackgroundPixmap to actually render the image. Setting the background means you can then ignore any need for handling Expose events to redraw the image.