I want to display a QPolarChart in a QChartView.
I won't add a title or a legend anything else than the QPolarChart.
Unfortunately, when I add my chart I have bit empty white space around the QPolarChart.I guess this is the space for the title and or the legend...
Is there a way to reduce this space?
I already used
chart->layout()->setContentsMargins(0, 0, 0, 0);
chart->setBackgroundRoundness(0);
which helped a bit.
I want to reduce the red margins:
Seems like you already followed the guidelines from the answers to the related question: How to remove margin from QChartView or QChart
If you are still not satisfied with the result, you can go one step further and use negative values by calling setContentsMargins directly on the chart object:
chart->setContentsMargins(-10, -10, -10, -10);
while keeping your layout object margins at 0 as you were doing already:
chart->layout()->setContentsMargins(0, 0, 0, 0);
I've done this in the past and it always worked fine, although it's a bit of a hack.
Also, the legend takes up some space so don't forget to hide it if you don't need it.
chart->legend()->hide();
This is the result you will get after making these changes:
You might try experimenting with negative values other than -10 to get the desired result.
Related
when I run my application under Ubuntu (Gnome/Unity) all wxBitmapButtons come with a white border (with a size of about 2..4 pixels). This border also shifts the position and extends the size of the total button by the borders size.
When I specify flag wxNO_BORDER (or wxBORDER_NONE) the border is no longer shown by default bur re-appears on mouse-over.
So my question: how can I remove this border completely? Normal wxButtons do not show this behaviour, only wxBitmapButton is affected...
wxBORDER_NONE is supposed to work, so if it doesn't, it looks like a bug in wxGTK. It's pretty strange that it does work for wxButtons as wxBitmapButton is basically the same class. However if it's really the case, you should consider just using wxButton with a bitmap instead.
I am trying to get my dialog box to match. I have been all through google, random testing, etc, even read some places it cant be done.
What I have been able to do is to use one of the messages to set font and colors, but nowhere about drawing itself.
I would think it has to be able to do...
Does anyone have any ideas? Or know anything about this?
http://imageshack.com/a/img832/5955/91m.png
It looks like edit controls don't support owner draw, but you can still solve your direct problem. According to the MSDN page for EDITTEXT, by default edit controls in a resource file have the WS_BORDER style set. Looks like you can get rid of it with something like this:
EDITTEXT IDC_EDIT1,17,51,136,14,ES_AUTOHSCROLL | NOT WS_BORDER
For the status bar, you might try using a static control with customized colors instead of a real status bar. Or you could roll your own, specify the window class name in the resource file, and make sure you register the class before displaying the dialog.
UPDATED: Wow, the documentation for status bar is terrible. You can owner draw one, though. Follow these steps:
// where hStatus is the HWND of a status bar...
// You must set simple mode to false, because simple mode doesn't
// support owner draw.
SendMessage(hStatus, SB_SIMPLE, FALSE, 0);
// I'm assuming 1 status bar part for demonstration. Setting the right edge
// for the 1 part to -1 make it take up the whole status bar.
int partWidths[] = { -1 };
SendMessage(hStatus, SB_PARTS, 1, reinterpret_cast<LPARAM>(partWidths));
// There is background stuff that stays behind even with owner draw,
// so you have to set the background color to black, too, to get rid of
// any appearance of borders.
SendMessage(hStatus, SB_SETBKCOLOR, 0, RGB(0, 0, 0));
// There is still a slim border that stays behind, so you need to set
// SBT_NOBORDERS in addition to SBT_OWNERDRAW. The 0 is the index of the
// status bar part. It could be anything between 0 and 255.
SendMessage(
hStatus,
SB_SETTEXT,
SBT_NOBORDERS | SBT_OWNERDRAW | 0,
reinterpret_cast<LPARAM>(_T("Status")));
From there, you must also handle the WM_DRAWITEM for the status bar. Now, as to why I say the documentation for status bar is terrible...
Docs for SB_SETTEXT say the high byte of the low order word of the WPARAM can be one of the values that follows. There are two problems with this:
You can combine them, and you must for this to work. MFC does it, too. I checked.
You might be tempted to write MAKEWPARAM(MAKEWORD(0, SBT_OWNERDRAW), 0). This will not work. By appearances, the SBT_ styles are defined so that they will automatically appear in the high byte of the low word if you just OR them with your index value.
That I had to look at the MFC source code to figure out how to use SB_SETTEXT correctly is telling.
Edit controls do not have an owner-draw mode, however you can subclass an Edit control and process messages like WM_ERASEBKGND, WM_NCPAINT, WM_PAINT, etc, as well as the WM_CTLCOLOREDIT message sent to the edit's parent window.
The answer for part 2, vertical aligning text in an edit:
RECT rect;
GetClientRect(GetDlgItem(hwnd, IDC_TIMEINPUT),&rect);
Rectangle(hdcEdit, rect.left, rect.top, rect.right, rect.bottom);
rect.left+=5; rect.top+=5; rect.right+=5; //rect.bottom+=5;
SendMessage(GetDlgItem(hwnd, IDC_TIMEINPUT), EM_SETRECTNP, 0, (LPARAM)&rect);
Has to be multi-line, and you really do have to play around with different numbers to keep it single lined, and maintain the vertical align. The EMS_SETRECTNP allows you to specify where you want the text to be, allowing the Edit to have a larger height.
I have a GtkDrawingArea that is used to visualize data.
Depending on the database and user input the drawing can grow really large (larger than the maximum allowed GtkDrawingArea size). Therefore I would like to use a drawing area that is just as big as the current window and update it manually upon scrolling.
If I use the ScrolledWindow + Viewport method to add scroll-bars to the drawing area it does obviously not work because the drawing area is not big enough to need scroll-bars.
Is there any way that that I can trick the viewport into thinking that the underlying widget is larger than it actually is?
If not what would be the best way to solve this problem?
Note: I am using Gtk2 and switching to Gtk3 is not a possibility.
You need to subclass GtkDrawingArea and override the set_scroll_adjustments signal. GtkWidget docs
In this signal you will get the adjustments for the scrolled window. I wrote some code a few years back that you can look at to see how to implement it.
MarlinSampleView code
This code was able to pretend that the widget was millions of pixels wide when in reality it wasn't any bigger than the window.
It turned out to be quite simple:
The GtkScrolledWindow has another constructor which can be used to set the GtkAdjustments that the scrolled window should use.
//These adjustments will be attached to the scrollbars.
prvt->hAdjustment = GTK_ADJUSTMENT(gtk_adjustment_new(0, 0, 0, 0, 0, 0));
prvt->vAdjustment = GTK_ADJUSTMENT(gtk_adjustment_new(0, 0, 0, 0, 0, 0));
GtkWidget* scrolledTree = gtk_scrolled_window_new(prvt->hAdjustment, prvt->vAdjustment);
gtk_scrolled_window_add_with_viewport(GTK_SCROLLED_WINDOW(scrolledTree), drawing_area);
Now, whenever the size of the drawing changes you just need to modify the GTKAdjustments to simulate the change. There is no need to actually resize the drawing area.
gtk_adjustment_set_lower(prvt->hAdjustment, 0);
gtk_adjustment_set_step_increment(prvt->hAdjustment, 1);
gtk_adjustment_set_page_increment(prvt->hAdjustment, 10);
gtk_adjustment_set_upper(prvt->hAdjustment, picture_width);
gtk_adjustment_set_page_size(prvt->hAdjustment, scrollArea_width);
gtk_adjustment_changed(prvt->hAdjustment);
Notice that I call gtk_adjustment_changed in the end. This is important, otherwise the ScrolledWindow will not update the scrollbars.
Finaly the value_changed callback of the GtkAdjustmens can be used to catch the scroll events and adjust the drawing.
Edit: This does not work properly because the GtkScrolledWindow receives the scroll event
as well and moves the image :(
I'm using a fixed size font ( eg: "Courier New" ). When I initialize the CFont object by calling CFont::CreateFont function, I want to specify only the font height.
CFont Font;
Font.CreateFont( nFontHeight, 0, 0, 0, 0, false, false,
0, ANSI_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
FIXED_PITCH|FF_MODERN, _T("Courier New") );
As per documentation, font width will be calculated automatically. I need that automatically calculated value for some other calculation.
GetLogFont Function is useless as it seems CFont only holds the value we give that is width = 0 and it calculates the value only when it is used for first time. ( Please check the Microsoft documentation )
Another option was to use CDC::GetTextExtent using a single character. But in that case also I could see some minor differences even in the height. For example, when I give -32 as height, GetTextExtent returns 33 for y value.
Is there any way to get the correct calculated width?
First of all, if you only want to specify the font height, you normally want to use CreatePointFont. Second, Windows 95/98/SE/Me are dead and gone -- and with them, essentially all reason to use Microsoft's "text" macros like _T("whatever"). If you want wide characters, ask for them directly:
CFont font;
font.CreatePointFont(nFontHeight, L"Courier New");
Then, as suggested by #MikMik, you can use GetTextMetrics to get the width -- but only after you select the font into a DC (GetTextMetrics gets the data for a font selected into a DC, not just for the raw font -- especially at small font sizes, some things get adjusted to compensate for the resolution of the output device).
Note, however, that even for a fixed-width font, the width of a string is not necessarily char_width * num_chars. At least if I recall correctly, even a fixed-width font can still be kerned, which means the spacing is adjusted based on what pairs of characters occur together. The classic example is a pair like AV. Because the lines where they're next to each other are typically at the same angle (or at least very close to the same) the spacing will be adjusted to move them closer together -- in fact, the top of the "V" will often overlap with the bottom of the "A". The width of a string of characters can vary even though each individual character has the same width as every other.
Offhand, I'm not sure that Courier New does that, but I'm reasonably certain at least a few fixed-width fonts do.
Have you tried CDC::GetTextMetrics()? I've never used it, but it seems to be what you're looking for. You can get the average and maximum character width, which I guess should be the same for Courier New.
I'm trying to draw vertical text in win32 GDI api.
I call CreateFont() with 2700 for the angle and 900 for bold.
logPxlY = ::GetDeviceCaps (c->_hdc, LOGPIXELSY);
_hfont = ::CreateFont (-::MulDiv (point, logPxlY, 72),
0, angle, weight, 0, FALSE, FALSE, FALSE, 0, 0, 0, 0,
FIXED_PITCH | FF_MODERN, face);
where face is "Courier New", point is 9, angle is 2700 and weight is 900.
The text IS rotated correctly, but it's pretty dang faint compared to normal Courier New rendering. Is this since truetype is polishing the normal text real nice and isn't bothering with wierd rotated text or something?
Thanks for any insight :)
The font mapper can be a bit strange at times. 700 is bold, 900 is supposed to be "black". However, you probably have a Courier New Bold font file, so it can be used directly, whereas you probably do not have a Courier New Black font file, so it'll be synthesized -- probably from the normal Courier New font instead of from Courier New Bold (not sure why that is, but such is life).
If you try running through the possibilities, something like this (MFC code, for the moment, but the idea applies regardless):
CFont fonts[num];
pDC->SetBkMode(TRANSPARENT);
for (int i=0; i<num; i++) {
fonts[i].CreateFont(10, 0, 2700, 0, i*100, 0, 0, 0, DEFAULT_CHARSET, OUT_CHARACTER_PRECIS, OUT_CHARACTER_PRECIS, PROOF_QUALITY, FF_MODERN, L"Courier New");
pDC->SelectObject(fonts+i);
pDC->TextOut(20+i*14, 20, L"This is some text");
}
What you'll probably see (what I get anyway) looks like this:
The 700 weight font is noticeably bolder than the 800 or 900 weight. This is not unique to Courier New either -- for example, the same code with the font name changed to Times New Roman produces output like this:
That's a bit closer, but the 700 weight still clearly looks darker than the 800 or 900. I won't bore you with screen shots, but the same effect happens when the text is horizontal.
Edit: One other minor detail: though it probably doesn't make any difference, you're currently computing the size of the font a bit incorrectly -- you're using logpixelsy, which makes sense when the font is horizontal. For a vertical font, you should use logpixelsx instead. On a typical screen, those will be identical, but on a printer (for example) they may be substantially different.