I have a QScrollArea (we'll call it myContainer) that contains and scrolls a child view (we'll call it myChildWidget). All works almost fine - when I change the height of myChildWidget dynamically in response to something, if the height exceeds that of myContainer (the QScrollArea), a vertical scroll bar pops into view, effectively narrowing myChildWidget since I've set it to resize its child using:
myContainer->setWidgetResizable(true);
The problem is that myChildWidget is not actually resized until later, rather than right when I set its new height or try resizing myContainer, so I can't do certain things depending on its new width without subclassing and putting in a whole bunch of extra code. Surely there's something I can call to get the QScrollArea to auto-resize its child right away, right? I can use:
QCoreApplication::processEvents();
but the problem with that is that it causes the widgets to flash and redraw when I'm not done setting things up. I've tried update(), updateGeometry(), and adjustSize(), both on the container and its child, and none work. Anything I'm missing? Thanks for any help.
Related
I'm having a problem where I cannot deterministically tell when a layout takes place.
Simplified example:
I have a widget with two sub-widgets.
Top widget has expanding width and fixed height. Let's say the fixed height defaults to 50.
Bottom widget has expanding height and width
There's a vertical layout set up.
Let's say there's a button somewhere i can click to run code. The button is not on the widget itself to make things simple...
When the button is clicked, i do the following:
I measure the height of the bottom expandable widget. The height is 100.
I then "topWidget->SetMaximumHeight(100)", and "topWidget->SetMinimumHeight(100)"
I measure the height of the bottom expandable widget again. The height is still 100
But I see the bottom expandable widget change height!
this means that when I do step #3, the layout hasn't taken place yet. No matter what I do, update(), updateGeometry() - I cannot get the bottom widget to change height between step #2 and step #3.
The only way for me to resolve this is to have a timer wait, say 250ms, and then measure the height of the bottom widget -- and then It's always correct - meaning the re-layout took place correctly
This is a crazy/dirty solution, but I don't have another. Is there an API I am missing to allow me to deterministically, synchronously change the layout and query for the new size of affected widgets right after?
from user: alexisdm
Try calling QApplication::processEvents() between steps #2 and #3 (it should do what the timer allow the event loop to do)
I have a window containing a QScrollArea with a couple widgets in it.
Until now, I was creating the QScrollArea and its child widgets in the constructor of my window, and then I was resizing the window vertically to fit its content using resize(400, sizeHint().height()). So far, so good.
Now, I'm adding or removing widgets in the QScrollArea at runtime. What should I do, after having added or removed widgets, to make the window fits its content vertically? Should I call adjustSize()? resize(sizeHint())? Should there be a call to layout->activate() or maybe updateGeometry() first? Which size policies actually matter in this case? The ones of the window, or of the scroll area, or both? I tried to set them all to Expanding.
I'm using Qt 4.6 on Windows.
It seems that calling resize(sizeHint()) (without any other magic) after widgets were added to the scroll area actually does the trick. Somehow missed that the first time.
I have such problem: I'm creating a container and it's content at runtime. Here's a rough structure:
--VBox
----Form
-------FormItem
...
-------FormItem
----ControlBar
I have fixed maxHeights for the form container to keep it in bounds of screen. But when I get vertical scrollbar, the horisontal also appears (seems like it's not enough place for this VScrollBar).
To escape this problem, I've created a listener for horisontal scroll appearing, so if it appears, I'll increase container a bit, so it would feet the other scrollbar normally:
form.addEventListener(Event.ADDED, function(event:Event):void{
if(event.target is HScrollBar){
while(form.horizontalScrollBar && form.horizontalScrollBar.visible && !(form.width > form.maxWidth)){
form.width += 10;
form.validateDisplayList();
}
}
});
I've tried also validateNowand other similar methods. What I have here:
1. The HScrollBar is being added.
2. We increase a bit the width of container, so it disappears.
3. When it disappears, the validating throws the null-pointer exception when it tries to measure the non-existing scrollbar. I've also tried to add validateProperties before validation, but it didn't worked either.
Can anyone help to get rid of this annoying scroll? :)
The problem is - if your scrollPolicy is set to auto Flex does not take scroll dimensions into consideration while calculating layout. So when scroll appears it is displayed over the content that it's already there. And when the content is hidden by the scroll a horizontal scroll appears so all content can be accessed via scrolling. The way I usually deal with that is to always set paddingRight (or right when parent is Canvas) style property to 20 (scroll usual width is 16) so when the scroll appears it doesn't overlap anything.
I am trying to use a QTextEdit widget inside of a form containing several QT widgets. The form itself sits inside a QScrollArea that is the central widget for a window. My intent is that any necessary scrolling will take place in the main QScrollArea (rather than inside any widgets), and any widgets inside will automatically resize their height to hold their contents.
I have tried to implement the automatic resizing of height with a QTextEdit, but have run into an odd issue. I created a sub-class of QTextEdit and reimplemented sizeHint() like this:
QSize OperationEditor::sizeHint() const {
QSize sizehint = QTextBrowser::sizeHint();
sizehint.setHeight(this->fitted_height);
return sizehint;
}
this->fitted_height is kept up-to-date via this slot that is wired to the QTextEdit's "contentsChanged()" signal:
void OperationEditor::fitHeightToDocument() {
this->document()->setTextWidth(this->viewport()->width());
QSize document_size(this->document()->size().toSize());
this->fitted_height = document_size.height();
this->updateGeometry();
}
The size policy of the QTextEdit sub-class is:
this->setSizePolicy(QSizePolicy::MinimumExpanding, QSizePolicy::Preferred);
I took this approach after reading this post.
Here is my problem:
As the QTextEdit gradually resizes to fill the window, it stops getting larger and starts scrolling within the QTextEdit, no matter what height is returned from sizeHint(). If I initially have sizeHint() return some large constant number, then the QTextEdit is very big and is contained nicely within the outer QScrollArea, as one would expect. However, if sizeHint gradually adjusts the size of the QTextEdit rather than just making it really big to start, then it tops out when it fills the current window and starts scrolling instead of growing.
I have traced this problem to be that, no matter what my sizeHint() returns, it will never resize the QTextEdit larger than the value returned from maximumViewportSize(), which is inherited from QAbstractScrollArea. Note that this is not the same number as viewport()->maximumSize(). I am unable to figure out how to set that value.
Looking at QT's source code, maximumViewportSize() is returning "the size of the viewport as if the scroll bars had no valid scrolling range." This value is basically computed as the current size of the widget minus (2 * frameWidth + margins) plus any scrollbar widths/heights. This does not make a lot of sense to me, and it's not clear to me why that number would be used anywhere in a way that supercede's the sub-class's sizeHint() implementation. Also, it does seem odd that the single "frameWidth" integer is used in computing both the width and the height.
Can anyone please shed some light on this? I suspect that my poor understanding of QT's layout engine is to blame here.
Edit: after initially posting this, I had the idea to reimplement maximumViewportSize() to return the same thing as sizeHint(). Unfortunately, this did not work as I still have the same problem.
I have solved this issue. There were 2 things that I had to do to get it to work:
Walk up the widget hierarchy and make sure all the size policies made sense to ensure that if any child widget wanted to be big/small, then the parent widget would want to be the same thing.
This is the main source of the fix. It turns out that since the QTextEdit is inside a QFrame that is the main widget in a QScrollArea, the QScrollArea has a constraint that it will not resize the internal widget unless the "widgetResizable" property is true. The documentation for that is here: http://doc.qt.io/qt-4.8/qscrollarea.html#widgetResizable-prop. The documentation was not clear to me until I played around with this setting and got it to work. From the docs, it seems that this property only deals with times where the main scroll area wants to resize a widget (i.e. from parent to child). It actually means that if the main widget in the scroll area wants to ever resize (i.e. child to parent), then this setting has to be set to true.
So, the moral of the story is that the QTextEdit code was correct in overriding sizeHint, but the QScrollArea was ignoring the value returned from the main frame's sizeHint.
Yay! It Works!
You may try setting minimumSize property of the QTextEdit to see if that force the layout to grow.
I don't understand most of Qt's layout scheme but setting minimum and maximum size pretty much does what I want it to do. Well, most of the time anyways.
I have a class which extends UIComponent and draws directly onto a Sprite contained within. Currently I'm (probably incorrectly) listening to the Event.RESIZE event and drawing the contents when the width and height are non-zero. The problem is that even though I've passed percentage widths to the instance tag, it doesn't appear to be resized along with other Flex components on the page, certainly the resize event isn't being fired at all.
I've hacked it for the moment by binding the width and height to a container which does resize, but how should I really be handling this?
Update :
It turns out I was setting the width and height somewhere in the redraw method (I have no recollection of why I did this!). I shall go hang my head in shame now...
I think you need to provide more information. I'm doing exactly the same, and it works smoothly for me. Perhaps the answer lies somewhere else: e.g. exactly what type of container do you use? Isn't it possible that the space gained/lost on resizing gets allocated to some other component within the cointainer? Try substituting your own component with an mx:Box with some colored background, and see if that resizes with the container.