I have a bit of an issue that involves a CMFCPropertyGridCtrl.
Normally you assign a window size to it and if it cannot fit it sets up a vertical scroll bar (for all I can see this is just the normal generic CWnd associated scrollbar). And this is great for when you just want to dump the control inside a re-sizeable window.
However, I have the reverse situation, where I would like to fit my outer window so that it shows the entire height of the control (such that no scroll bar needs to be created). In order to do that I somehow needs to get an ideal height given the contents of the control. Is that possible in some generic way or just for CMFCPropertyGridCtrl ?
To give a little more background, I have multiple gridctrl's on top of each other so to speak. Therefore, I have put a scrollbar on the outer window so you could say they share that scrollbar (and this one is working just fine). I could go into details why I want this design(as opposed to just one gridctrl with everything), but basicly it's a kind of cards where each card/element has it's own set of properties.
Related
Currently if I make a window in GTK3
For example 300x300
And I put a button at the bottom, right hand corner, I can not shrink my window
Size because this button is preventing me is there a function in gtk3 that can allow me to ignore all widgets, and resize to anything even 0x0
And this is the user doing this with the window resize, drag and click
And is there a way where I can set this resize limit myself, and not have this dependent on whats in my window
If you initially use set_size_request() to set the window to 300x300, then it won't shrink below that. To allow users to shrink below an initial value, use set_default_size(). I seem to have read that the minimum size of a widget is 1x1, which seems logical, as, at 0x0 you wouldn't be able to resize it anymore. If you want less than 1x1, you can use hide() and just hide the contents.
But if you have any widgets inside the window, then the minimum size is determined by the widgets! (Called the 'natural size')
To allow a window smaller that than the one determined by the widgets, you can maybe use a Gtk.ScrolledWindow.
Also, recall that the outer border is drawn by the window manager, NOT by Gtk. However, you can disable the outer border by using set_decorated(). Not that this may not work - depending if the window manager respects this (not Gtk's fault).
I want the user to be able to vertically resize the Window but I'm unsure how I would do this. I have selected my root object (View of type QWidget) in Qt Creator but I do not see an option to allow users to vertically resize the object. Does this have to be done through code?
By default, if a QWidget is the top-level window you are able to resize it given that the minimumSize and maximumSize are different since they indicate the range of resizing.
If you want to let the user to resize vertically only, then you just have to set both minimumWidth and maximumWidth to the same value (probably to the current width of your QWidget). Qt will take care of indicating the underlying windows manager the rest.
You can do it in the Designer or programmatically using the setMinimumWidth and setMaximumWidth methods. Edit: As mentioned in a comment, there is a setFixedWidth method that simplifies this operation (and make it more explicit in your code).
Of course, you can play with the combinations such as setting a minimum width (or height, or both -minimum size-) to avoid your top-level window to collapse and become unusable, setting a maximum size... One common setting is making minimumSize = maximumSize, so you make the window fixed size (you can use the convenience method setFixedSize).
PS: see that this has nothing to do with the sizePolicy, which simply indicates parent layout which actions can be taken -regarding size- when placing the widget. As a top-level window has no parent layout this policy is simply not used.
My app needs to be small in nature so I make it 500 x 100 px in size.
The problem is the ComboBox selection items are also squeezed into that small window size. Of course, I can scroll it, but it doesn't feel right this way.
Here is the picture:
Is it possible to expand the ComboBox selection list so that it exceeds the parent window? Preferably in XAML if possible
Is it possible to expand the ComboBox selection list so that it exceeds the parent window?
No, this is impossible in UWP apps. While using ComboBox class, it displays the drop-down list in PopupRoot, which is a layer has the same view port as its parent window. Anything outside this view port will be clipped, users can't see them. For example, following is a normal ComboBox:
After I give a Margin="-20,-30,0,0" to the drop-down list, it looks like
The part outside the window is clipped.
Besides, The implementation of ComboBox will also make sure the ComboBox's selection list won't exceeds the parent window. The selection list's max height is calculated at runtime, it will be always less than the parent window's height and we can't change its value manually, so it is not possible to expand the ComboBox's selection list.
It's not possible, but you can extend your page to the title bar to have at least some additional space using CoreApplicationViewTitleBar.ExtendViewIntoTitleBar property.
Take a look here and here. (I know the examples are written in C# but it should be similar in C++)
I am working on a project that totally does not want to use the built-in window/dock state and position saving of MFC. This means that in my main frame, I set EnableLoadDockState(FALSE). As much as I love to change it back to TRUE, I can't.
I plan on getting the position where a CDockablePane was docked through onAfterDock() of my CDockablePane. My problem is I have no idea on how to get whether it was placed on the side, top or bottom, on another CDockablePane.
Is there a way to get this information?
Thanks!
I think there is a way to get it, but it's not going to be easy or pretty.
A you're trapping the OnAfterDock, I guess you're not interested in floating panes. So, for docked panes, you can use CDockablePane::GetDefaultPaneDivider (MSDN here), which returns - as MSDN says:
A valid CPaneDivider object if the dockable pane is docked to the main frame window, or NULL if the dockable pane is not docked or if it is floating.
The CPaneDivider object (MSDN here)
...divides two panes, divides two groups of panes, or separates a group of panes from the client area of the main frame window
The following partial screenshot says more:
So, for a regular pane divider, you can use the methods available on CPaneDivider to find the other pane, or another embedded CPaneDivider (so recursive interrogation necessary here) and check if the divider is horizontal or vertical etc.
For the other case described above, look at the CPaneContainerManager class, which (again as MSDN says)
...manages the storage and display of the current docking layout
From here, you can again drill down through the whole docking hierarchy that starts from your original docked pane.
If I were you, I would really really look again at using EnableLoadDockState or at least browse the MFC source code to see if there are any internal helper classes/functions that you can reuse.
I've just solved this issue. I can check CDockablePane's dwStyle (GetPaneStyle()) for CBRS_ALIGN_LEFT, CBRS_ALIGN_RIGHT, etc. No complex methods. Simple.
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.