In my program, I'm moving from QMainWindow to QDialog on a press of a button.
I want to do the same without opening a new window and be able to move between the UI's.
The Target device will have a very small touchscreen, so I want my UI to sit still and require minimal repositioning.
Please point me in the right direction or give me an example on How-to.
To do that, you can use a QStackedWidget.
From the documentation:
The QStackedWidget class provides a stack of widgets where only one widget is visible at a time.
Instead of opening a new window, push its content on top of the stack and pop it when you want to (let me say) close the window.
Each widget is a page of your application and no separate window is required. You can design them as you would design a central widget of a normal window or dialog.
Related
I'm getting started with Qt and decided to build a full-screen text editor. I want to have a button (button with arrow in screenshot) attached to a QDockWidget which opens and closes it so the button is always visible to the right side of the screen and stay anchored to it when dock is visible or resized.
My current app is a simple fullscreen textEdit set to centeralwidget in Mainwindow.
I haven't found a way to do this yet with layouts or existing addAnchor() functions so any help or direction is appreciated.
You can achieve what you want by using a container for your text edit and the button. A QWidget instance can be used as an "invisible"*** container for other widgets.
So in Qt Designer you add a widget as a central widget of the main-window, inside this widget you add the text edit and the button, then you set a vertical layout for this container widget.
Don't forget to restrict the docking widget to only dock to the right side, you can do that with: dock->setAllowedAreas(Qt::DockWidgetArea::RightDockWidgetArea); //assuming dock is the pointer to your QDockWidget.
In case you want the dockWidget to be able to dock to any side and the button to follow, you can do that too, but it get a little bit more complicated. Basically you need to connect a slot to dockLocationChanged of your dockWidget and based on where it's docked you need to set-up a new layout for the container widget to be vertical or horizontal and the order of the textEdit and the button based on the side the dock happened.
LE:*** you will most likely need to set the margins you want, since both the widget and it's layout can have them and the actual content might have higher spacing than you want.
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 QtCreator 5.5 for the Mac, using C++, and I'm new at this. I have a MainForm window. I want to show a dialog inside that but draw it separately in its own UI designer. Then, at runtime, my code will pull that other UI and show it inside that window.
Imagine for instance a main application window. You click a button and you need to see a confirmation dialog. Normally you could do that with a separate window. Instead, I want it to be inline at runtime, to show it like a widget on the main window.
Sure, I could draw my dialog on top my existing window in a widget, but that defeats the point where I want to be able to adjust it in its own designer window, and just load it as necessary in the main window when I need it.
What's the technique in QtCreator and C++ to do this?
Open QtCreator. This task can only be done through there.
Assuming you have a regular Qt Widget Application, you need to just add a QWidget control on the MainWindow's centralWidget in the UI Designer.
Next, click Edit in the UI Designer and then rightclick Forms. Choose Add New...
In the dialog that opens up, choose Qt > Qt Designer Form Class, and click Choose...
Select Widget and then go with the defaults on the rest. This creates a widget called Form, and the form.h and form.cpp will also be added to your project.
Now find the form.ui and open it in Qt Designer. Add a Stacked Widget Control on the QWidget form. Size it to the same size as the parent widget. Next, stick a Label Control on the Stacked Widget Control's first page. This label will be temporary just to prove that this works. You'll set it to the text of "Testing". Now close the designer.
Flipping back to your UI File of your Main Window, find that QWidget you added and rightclick it. Choose Promote... and a dialog box appears. In that dialog, set Promoted Class Name to Form and then set Header File to form.h. Leave everything else on defaults and click Add and then Promote.
You may be expecting to see an immediate change in your Main Window in that QWidget that you added previously. However, that's not how this works unfortunately. You only see the change at runtime. So, now you should Run your application in Qt Creator. You'll see when it runs that your widget now contains the contents of that form.ui component you created.
Now, here's where it gets interesting. You can now draw all your inline modal dialogs on that form.ui, just putting them on different pages of your Stacked Widget control. You can also set the properties of your widget so that the background of the QWidget container is opaque and dark (creating a background dimmer) and then, at runtime, resize the QWidget to the size of your Main Window. When you need to switch to a different dialog, you can use setCurrentWidget() or setCurrentIndex() on that StackedWidget item like so:
QStackedWidget *w = ui->widget->findChild<QStackedWidget *>("stackedWidget");
w->setCurrentIndex(1);
In that example, I had a QWidget control on my MainWindow named simply widget. I then found the control on it called stackedWidget. Once I had it, I used the setCurrentIndex(x) method on it to change the page of that widget to show the one I needed. Remember that this is a zero-based index. So, (1) would be page 2.
QMainWindow::setCentralWidget
Inside your QMainWindow constructor add:
MyDialogClass myDialog = new MyDialogClass();
setCentralWidget(myDialog);
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 am making an SDI MDF application that uses a frameview to provid the user with a set of controls (buttons, editboxes and such). The view also owns a set of CDialogs used to desplay aditional controls that can be can be shown or hidden via a tabcontrol and other means. Untill recently the dialogs have been staticly placed at creation to be in their proper location on the screen but I wanted to add a dialog that the user could move around but is still a child of the view. When I created a dialog with a caption and sysmenu that the user can move around the issue I am running into is that when the window is placed over another control owned by the view, (lets say a button) when the paint method is called on the button, it draws over the dialog. The dialog is still on top and the dialogs controls can still be interacted with but the button is drawn over them untill the dialog is repainted. I have tryed to change the clipchild and clipsiblings settings of the dialog and have been able to get the dialogs to properly clip eachother but can not seem to get the child dialog to properly clip the parent view controls. Does anyone have any ideas on what setting might fix this clipping issue.