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.
Related
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.
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.
I'm wanting to make something like a tab control, but without visible tabs at the top.
I would prefer to have the tabs selected from a list or tree at the left hand side of the page, something like this...
Selecting the list/tree item at the left changes everything on the right-hand side of the dialog.
I know I could do this by individually showing/hiding all the fields on the RHS, depending on the selected view, but this is unmanageable to design, when there are at least 10 different designs. C++ doesn't let me design groups and make them visible/invisible in one go. I would prefer to design them as totally separate dialog resources, and then bring them in, like a tab control.
I believe Windows Forms has a ContentControl, which is like a tab control without the tabs, which sounds perfect, but MFC doesn't seem to have this.
Is there a way to do this nicely? Or maybe even a 3rd party control to handle it?
In MFC you would do this by making a child modeless dialog for each group. For each dialog turn off the titlebar style and border style and it will blend in to the parent window instead of looking like a dialog. Create all the dialogs, then use ShowWindow to show/hide one at a time.
Minor detail: Put an invisible control (like a group box) on the parent window to serve as a landmark. When you create each dialog use MoveWindow to position and size it on the landmark.
Use window style WS_EX_CONTROLPARENT in the parent window to help with tab key navigation from parent to child.
Yes you can using DIALOG resources. Set the DIALOG Style to Child, Border to None, Title Bar to False. You can then add implementation classes/files for each DIALOG. The dialogs are then inserted/removed to and fro the parent as a child components by setting the containing window as the dialog's parent (i.e., SetParent)
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.
Let's say that I have an application frame, and I want to show a popup QCalendarWidget over on the right side of the frame. Normally, QT will clip the edges of the QCalendarWidget, cutting it in half and not displaying the rest, as it would be over the right side border.
Is there a way to work around this limitation without resorting to implementing a QDialog?
I want the widget to be visible outside the bounds of it's container.
If you'd show your Calendar, let's say, after a button click, as QDateTimeEditor does, it's contents will not be clipped, cause it do not belong to frame. It will be just a widget, that shows in a dialog manner. And maybe you should even place it in QDialog, that is modal and provides some convenience methods, rather then simple QWidget.
Btw, why don't you want to use QDatetimeEditor?