I recently started learning C++ and wxWidgets and now I'm building a calculator program. I have a grid sizer with buttons and I want to know is it possible to change the font of the whole sizer instead of changing the font of every single button?
Sizers are not windows and so don't have any font, so, no, you can't just call SetFont() on a sizer. You can iterate over all sizer items and call SetFont() on each item which is a window. Or, somewhat less efficiently (because you "waste" a window), but more conveniently, you can make all your button children of a wxPanel and associate the existing sizer with this panel. Then you'd be able to call SetFont() on the panel, which is a window, and so would propagate the font change to all of its children by default.
Another solution might be to create a child of wxButton that will take the number in constructor and change the font there.
Related
I am using Qt-5.8 over Ubuntu.
This is how my QTabWidget appears :
And the black dot is where I want the Minimize Button to happen.
One way I came across is that I can use QToolButton *qToolButton to create a new button and tabWidget->setCornerWidget(qToolButton) and then add the implementation over its click event.
But should there not be any other way to just show the minimize button as like in MainWindow or SubWindows has. Which just minimizes it.
Minimize button on top panel of your QMainWindow's instance is part of Windows Manager subsystem of your OS. So you can't use similar approach inside your window as toolbox with buttons, etc.
As you wrote, try to use tabWidget->setCornerWidget(qToolButton) to place your custom minimize button inside your window.
I have two Qt widgets in the window. One of them is QDockWidget, and another one is just QWidget.
When I drag the QDockWidget, the default behaviour of the another widget is moving without changing its size. And I want it to fill the whole window except dock widget, and to change its size programmatically when I drag QDockWidget. Hwo to do it better?
The solution was to set container horizontal policy as "fixed"
I have an application written in C++/QT5 with a QListView widget within a QHBoxLayout within a QGroupBox. There is also a QTabWidget in the main window. I would like the user to be able to resize the QListView widget by clicking and dragging and for the other items to automatically resize themselves accordingly.
I feel like this should be something that is easily done within the framework of QT5, but I can't for the life of me find a way. Even having a border on the list view that I can resize within the code of my application would be a start.
Thanks to jhnnslschnr I was able to solve this via the QSplitter widget. If you're using QtCreator as I was, you can use QSplitter simply by Ctrl-clicking the widgets you want in the splitter and then selecting "Lay out horizontally (vertically) in splitter". The user can now select the partitioning at run-time.
I am undergoing a number of tutorials on wxWidgets and found that I must add a wxPanel to my main frame in order to get a Windows native-like background, instead of the ugly dark-grey that it defaults to.
Now, the WxSmith tutorial: Hello world states that a wxBoxSizer is the first control that should be added to the main frame. Then goes the wxPanel, and then another sizer where I'll put my controls (text, buttons, etc).
I'm failing to understand the need for the first sizer. For me it would make more sense to have the following hierarchy: Frame -> Panel -> Sizer -> Controls.
So, do I really need to add a top-level sizer to my frame, before the panel?
Note: The only purpose of the wxPanel is to give my window a light-grey background.
Edit In fact, I only get what I want (light background color for the entire window) if the panel is the frame's first and only child control.
No, you don't need a sizer for the panel because wxFrame automatically resizes its only child to fill its entire client area, just because it's such a common case.
The purpose of wxPanel is not only to give you the "correct" background, but also to provide correct keyboard navigation among your controls. And the reason it is decoupled from wxFrame is that some frames don't contain controls but are used as e.g. canvases, in which case the panel would be unnecessary.
Finally, don't be confused: sizers are not controls, they are associated with a window and, in turn, contain (some of) the window children, but are not controls themselves.
I have an instance of QDialog, populated by widgets using code generated by uic. The dialog contains a few labels laid out vertically, and I am popping the dialog from time to time to show some text in these labels. The text can be multi-line and its length is not pre-determined. I set the vertical size policy to fixed, so the user can't drag it (doesn't make sense), but I also want the dialog to change its size before being shown to accomodate for the current size of the labels.
To this end, I was calling QWidget::adjustSize() on the QDialog before displaying it, but it doesn't work as expected. When the dialog is shown, it seems to retain the (wrong) size from the previous displaying, but when I click the mouse in the (disabled) vertical resize mode, the dialog suddenly "snaps" to the (correct) adjusted size.
Is there any way to make my dialog appear correctly?
EDIT: I tied rubenvb's advice, and ended up with this:
QSizePolicy free(QSizePolicy::MinimumExpanding, QSizePolicy::MinimumExpanding);
QSizePolicy fixed(QSizePolicy::MinimumExpanding, QSizePolicy::Fixed);
dialog->setSizePolicy(free);
dialog->adjustSize();
dialog->setSizePolicy(fixed);
dialog->show();
Unfortunately, that didn't seem to change anything.
This isn't the answer you're hoping for, and it may not apply to what you're trying to do, however, the only way that I was able to adjust the dimensions of a QWidget at run-time was by handling the object's resizeEvent(..) method. This allowed me to calc the size of items based upon the font being used, number of lines, available space, etc., and then adjust their size accordingly before passing the 'event' on to the base resizeEvent(..) method.
My approach used a single QWidget container within a window, below a header, above a footer status area, and to the right of a column of menu buttons. The widget container, inside the resizeEvent() call, would look at the objects it was going to display, calculate the font heights being used, and then resize some items according to their dimensions (because of how the style sheet selected fonts and colors, etc) and then adjust the sub-widget dimensions before allowing the container widget to get the resizeEvent() message.
So I wasn't so interested in setting a window size, but I think the container QWidget might work the same way? I was more interested in setting the dimensions to some asthetically pleasing size, depending upon the dimensions of the display.
Hope you find that helpful.
Do everything in the right order:
Dialog is not shown. Dialog is resizeable.
Calculate new size, set new size.
Set dialog to not-resizeable.
Show Dialog.
Hide dialog, go to step one.