Can anybody please tell me what about visible and includeInLayout properties of a component and what is the state of the component when they are in combination of {false,false},{false,true},{true,false}. Thank you in advance.
Ok, visible is only about visibility of component and includeInLayout is only about taking part in process of component's laying out. Talking about laying out we're talking about such layouts as vertical layout, horizontal layout or tile layout where positions of the children determines by positions of other children.
Well, according to this explanation false,false is about target display object will not visible and will not affect on the position of other objects in layout. It is the same as target display object isn't exist at all.
The case false,true describes the situation where target display object isn't visible but takes part in layout. For end user it is an empty space between other objects in layout. This space has the same dimensions as our target display object.
The case true,false makes target display object visible but with not predictable position (depends on the particular layout implementation). Anyway it is not affect other elements position which laying out the way as target display object doesn't exist. It is very likely some of the other element overlap our target display obje
Related
I have a QStackedWidget (QSW) with 2 child components, both are configured to expand to the size of their parents.
One of the child components (CC) resizes its content based on CC's size. These
calculated sizes are also used to determine the size of components which are always visible in a sibling of QSW. In order for these sizes to be always correct, CC needs to be resized even when it's not the active component in QSW.
What's the most straightforward way to accomplish this?
Edit: CC's sizePolicy is MinimumExpanding/MinimumExpanding, so the requirement is that CC's size is set to expand to the maximum size QSW allows it to, even when CC is not the active component.
This is a fine matter of whether or not the size hint works and what size policy is. In such cases the call of QWdiget::adjustSize is usually helping but to answer with confidence more context of your code is needed. Anyway, the docs say when it helps. I would trap the moment when the size is not correct and apply adjustSize. Mind that the scope where you apply adjustSize matters too.
Using a QStackedLayout with the StackAll stacking mode solves the issue. When the stacking mode is set to StackAll, all child widgets are showing, they just cover each other.
Is there a way to make the layoutStretch property always be obeyed? E.g. I have it set to "1,3,2", but then a widget (a label) in the first part (the "1" in "1,3,2") expands (when more text is added), and then the 1:3:2 ration is no longer respected. That is, the "1:3:2" ratio turns into something more like "3:1:3".
You should take a look at the property QWidget::sizePolicy. It controls how the layout respects the sizeHint() of its children when it updates the geometries.
So what you need to do is: Make the layout ignore the horizontal sizeHints of the child widgets by setting the horizontal sizePolicy of the three child widgets to QSizePolicy::Ignored:
QLabel *label = ...;
...
label->setSizePolicy(QSizePolicy::Ignored, label->sizePolicy().verticalPolicy());
(The second argument will ensure that the vertical policy isn't changed by this statement.
Of course, you should set the size policy of every child widget, this example code is only for the label.)
Note that the contents of your layout have to be widgets; I think nested layouts can't be assigned a size policy (but I might be wrong). At least using QtDesigner, there is no way of applying a size policy to a layout itself (if it isn't the layout of a widget). See comments for details.
In QtDesigner, you can set the sizePolicy of the child widgets like this:
Before:
Shrinked:
Select the items in the layout:
Set the horizontal size policy to "Ignored":
Result:
I am a little confused about the setActualSize method. It appears from what I've read, that if it is not called on a component by its parent, the component will not be rendered.
So it appears that setActualSize is a critical method that is directly bound to rendering the UIComponent. It also appears that the width and height properties of UIComponent override the functionality of the width and height properties of flash.display.DisplayObject, in that they are not directly bound to the rendering of the object but are virtual values that are mainly used by the getExplicitOrMeasured when the parent of the component calls the component's setActualSize method.
So the question are:
1) Why isn't the default behavior of every component to just call setActualSize(getExplicitOrMeasuredWidth(),getExplicitOrMeasuredHeight()) on itself?
2) I guess this question stems from the above question and the behavior as I understand it as described above: does setActualSize change the visibility of the component?
It appears that that the behavior is that a component is not rendered until setActualSize is called, but if it contains display object children itself (expected behavior as it can calculate measure on itself) and is added to the display list, the only reason why flash isn't rendering it, is because its not visible.
The answers to your questions are in the way the Flex component life cycle works, consider these two phases:
measurement:
The Flex framework will call the measure() method of your component. You can override this method to set a default and/or minimum size for your component.
Flex components first measure themselves to provide a default and/or minimum size suggestion to the layout/container classes. Flex does this from a bottom up approach, so that the lowest level objects are measured first. Thus when each parent object measures itself, the preferred sizes of it's child objects has been established.
rendering:
Later Flex calls the updateDisplayList() method of your component. You can override this to size/position your component's child objects. This is where setActualSize() is intended to be used: the parent calls setActualSize() on it's child objects, not on itself.
Note the method signature of updateDisplayList():
protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
Measurement was done from the bottom up. However, rendering is done from the top down. So at render time, updateDisplayList(unscaledWidth, unscaledHeight) gets executed on your component. Flex is telling your component the space it has been allotted to render itself, and your component must size/position it's child objects accordingly and/or do programtic drawing.
The sizes passed in to updateDisplayList() are based on various factors:
how/if you override the measure() method (measure is not called when
your component has a fixed width/height)
the types of sizing
parameters (fixed, percent, constraint) and layouts that you use
An old but good resource on this topic
setActualSize() is one of the crutial and most interesting methods in Flex layout process:
1) Notice that setActualSize() is an entry point for parent's layout to set the component size, and it has to be called by parent (container) almost exclusively!
This is because only the parent knows the amount of space available for each child (this method is being called after all children are measured and the container knows it's own given size).
(note: the example of not calling it by layout posted below)
This method exists because if parent would set 'width' and 'height' on children directly, they would immediately turn into fixed size children, and they won't be measured anymore.
Using this method, only the rendering size is being changed - not the (explicit) width and height but _width and _height - meaning if for some reason the container resizes again, the children will be resized by given rules (percentage of the parent, expanding to child component's children size etc.)
2) Yes, because if this method isn't called at all, the component has a (rendering) size of (0, 0), so this is the reason of it's invisibility (not setting 'visible' to false)! ^_^
Note that THERE HAS TO BE A LAYOUT (even a non attractive one) to trigger this method call. By 'non attractive' I consider the layout that isn't supposed to do anything smart, like CHANGE THE WIDTH AND HEIGHT of children at all (like absolute layout)!
Now, look at the PopUpManagerImpl's class addPopUp() method: there is an interesting case of calling setActualSize():
IUIComponent(window).setActualSize(
IUIComponent(window).getExplicitOrMeasuredWidth(),
IUIComponent(window).getExplicitOrMeasuredHeight());
Explanation: PopUpManager does stuff that layout should normally do, because it WANTS TO KNOW THE POPUP DIMENSIONS IMMEDIATELY, so it could center the popup on stage. It has no time to wait for the layout pass!
If you comment those 3 lines in the framework code, you'll see that popup is being centered with it's top left corner - just like it's size is (0, 0). Anyway, it is rendered with proper width and height because at rendering time the dimensions are known.
Hope this makes things a bit clearer...
Cheers! ^_^
Danko Kozar
How can I change the z axis of components and put one in front of the other? The new layout property in Flex 4 has changed significantly & now not sure how to do it.
It works the same way that it did in Flex 3. A components Z order is defined by the order in which they are placed as child of their parent. The second child will be in front of the first child, and the third child will be in front of the first and second child and so on.
You can still use swapChildren and swapChildrenAt to change the Z-order of children.
The layout property's value will be an instance of a Layout class; which--in a simple form your measure() and updateDisplayList() methods. IT does not, specifically, relate to moving one component in front of, or behind, another.
On a Flex 4 group, you can use swapElement and swapElementsAt, although I would bet if you were to examine the code you'd find that these are just layers of abstraction over swapChildren and swapChildrenAt.
checkout the new depth property introduced in Flex 4 e.g. see http://www.tink.ws/blog/flex-4-uicomponent-depth/
Maybe this help:
container's depth
you can use depth property of flex containers to define which element can overlap other elements.
I am working on a flex app that uses XML templates to dynamically create DisplayObjects. These templates define different layouts that can be used for each page of content in the app (ie , 2 columns, 3 columns etc etc). The administrator can select from one of these and populate each area with their content.
The templates add one of 3 types of DisplayObject - HBox, VBox or a third component - LibraryContentContainer (an mxml component that is defined as part of the app) - which is effectively a canvas element with a TextArea inside.
The problem that I am getting is that I need each of these areas to automatically resize to fit the length of the content but don't seem to be able to find an effective way to do so.
In the LibraryContentContainer, when the value of the TextArea is set, I am calling .validateNow() on the LibraryContentContainer. I then set the height property on both the TextArea and LibraryContentContainer to match the textHeight property of the TextArea.
In the following example, this is the LibraryContentContainer, viewer is the TextArea and the value property of the TextArea is bound to this.__Value. v is the variable containing the content for the textarea
this.__Value = v;
this.validateNow();
this.viewer.height = this.viewer.textHeight;
this.height = this.viewer.height;
This works to a degree in that the TextArea grows or shrinks depending on the length of content, but it's still not great - sometimes there are still vertical scrollbars even tho the size of the TextArea has grown.
Anyone got any ideas?
Thanks
Adam
I think the problem lies not with your dynamically added components, but with the component they're being added to. How is the height of this component being determined? If you set verticalScrollPolicy and horizontalScrollPolicy on this container to off, do your scrollbars disappear? If that's the case, then you'll need to look at how this component is sized rather than your hbox, vbox, or whatever it is you're adding.