Koen Deforche wrote:
Hi Koen, thanks for responding.
> First of all, it seems that you want to achieve the effect that a
> expanding and collapsing items in the treeview resizes the treeview ?
Yes, just like WTree and WTreeTable.
> This is not the default behavior, as by default scrollbars will be
> used to accomodate the contents within a given space.
You're right - setting a vertical size with resize() makes it work
better in the layout. Other similar widgets don't have this problem
though (ie. WTree, WTreeTable), and the overlayed behaviour would seem
to be a bug in WTreeView, since the layout it is in should not let this happen.
Using resize() creates a different problem:
The only effective way of specifying a height seems to be in pixels,
percentage simply doesn't work. Yet in these days of devices with
wildly different screen sizes and pixel density, it's considered
bad GUI practice to specify layouts in pixels. What alternatives are there ?
Is there any way of getting a widget or the overall windows current size,
so that the widget size can be specified as a percentage of window size ?
> That you see the text mingling with what comes below would suggest to
> me that you are not correctly deploying Wt's CSS files,
> since the CSS overflow attribute should prevent that.
I've checked that it's got a full set of Wt's CSS files and that they
are being used.
> It might not, but layout management in 3.2.2-p1 has considerably
> improved (although the migration may require some work).
I'm afraid my impression is quite the contrary - lots of things
that seemed to work in 3.2.0, don't seem to work anymore. At first blush:
the stretch factors don't seem to work anymore - container
sizes that were stretched proportionally to the factors now
seem to do something unconnected with the stretch factors.
The alignment flags seem to do things other than what they
specify i.e. AlignTop seemed to stop the new unwanted default vertical
justification of my buttons, but positioned them centrally
rather than at the top. I didn't investigate further than that since
it is unclear whether these are bugs, or what has fundamentally changed
here, but if these things are not bugs then the layout controls seem
even more puzzling and inscrutable than they were.
> That is because in non-Ajax mode, there is now active layout management.
I guess I don't understand that. Doesn't Ajax use layout management ?
> With the new implementation of layout management in 3.2.2-p1, you
> should be able to get the same behaviour by putting a maximum height
> on the treeview, which will have the effect of resizing itself up to
> that maximum size given what its contents needs.
That sounds a bit strange. I would have though "maximum hight" would
be the maximum height available to it, whereas "auto" would be the
minimum height it needs to display without using scroll bars.
> These only return what has been previously set.
Is there some way of retrieving the actual height of things.
so that some intelligent layout can be performed (ie.,
not pixel based) ?
Thanks,
Graeme Gill.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
