I have a .rdlc report with grouping (4 levels).
In the last level, I have a pretty complex design of textboxes/images that can't be done with rows/cols. For example, they overlap on some points.
So what I have to do is to put a Rectangle on the cell and then, inside the Rectangle, put all the components.
The problem I have now is that some of these components can be hidden depending on the data, and because of that, sometimes there is a lot of white space inside the report that I don't want.
Is there any way to shrink the Rectangle if it doesn't have any visible data?
Unfortunately, by design Rows and Columns will not shrink below its definition height/width, therefore, a Rectangle can only be as small as its Cell.
However, you could try to make it as small as possible, and rely on the CanGrow property of Textboxes ("Property" window, under "General" tab), as suggested in the link given above.
Related
I have a number of UI elements like panels, edit fields, buttons, labels etc. so panels contain other panels which contain input fields, editors and so on. Most of the elements are editable and/or resizable which means whenever I change anything, a lot of adjacent UI elements should change their width, height and x/y position on the pane. It works fine with a small number of elements but incredibly slow when the number of elements is thousands.
Is there a fast layout algorithm which can be used in this case? Note that I cannot use any existing layout managers and should come up with my own implementation.
I'd suggest taking a leaf out of the Android playbook and have a larger 'grid' and keep everything sized in modular multiples - this avoids you needing to solve the knapsack problem everytime!
For example, instead of having a button with an width of 80 and a height of 40 you store this as metadata as {2:1} (assuming your layout grid is 40^40 squares).
This way if you have a work panel with space of, say, {2:12} this could be filled with two objects of size {2:6} or maybe 3 of size {2:4}.
It's pretty simple to fit-to-max too as any available space can just be scaled up (say you delete a {1:1} item you can just expand the one next to it to take the space etc - you can of course create your own rules around whether objects can scale in single directions etc.
The other advantage of this approach is that you can easily manage different screen sizes and resolutions too while still keeping the same framework and look and feel.
Since Jason Smith didn't recommend Relative layout and said that we should use Absolute layout I have a question how can we deal with RelativeToView concept?
Absolute Layout sets proportional coordinates and sizes of the elements within itself relative to itself not to each other as RelativeLayout. What to do if I need some elements to be relative to each other? Creating additional Grids and StackLayouts? I would rather use RelativeLayout then or I am missing something.
Decided to add a simplest example and consider we are talking ONLY about Relative and Absolute layouts, no Stack, no Grid. I have 2 buttons and I want to place them as shown in the picture
With absolute layout I could define the position of the top button and say it's height 10% of the screen. Now I could shift the bottom button by saying it starts at 11% of the screen. BUT this will change my top button height. If I want my top button to be it's natural "auto" size I cannot do that. So, how can I put my bottom button under top one if I have no idea how much top button occupies on screen? I know how to do it with Relative but how I can do it with Absolute Layout?
It looks like the solution is nest bunch of layouts https://developer.xamarin.com/guides/xamarin-forms/user-interface/layouts/absolute-layout/
Is that the only way? Is that performance still better than Relative layout?
By its nature RelativeLayout is powerful and offers layouting options that no other Layout on its own does. But that power comes at a cost in performance. Resolving the constraint dependencies consistently and obtaining a final layout doesn't come cheaply.
The point is not necessarily that RelativeLayout should never be used, rather that often times other Layouts can do the job, and yes, even 2-3 nested Layouts can be more performant than a single equivalent RelativePanel.
Grid in particular is a powerful option with which similar effects can be achieved by astute use of Auto, Star, and/or absolute-sized rows and columns as appropriate, plus RowSpan and ColumnSpan, plus element margins, etc.
To consider your specific example, I don't know of a way to achieve what you want with an AbsoluteLayout, at least without the added complication of attached properties. But it seems like a natural fit for a Grid with RowSpan="Auto" on the first row. From a diagram alone I can't tell exactly what other constraints you're going for.
I have a report showing one graph, and another separate report showing another graph. I then have a "master" report which combines these two reports as subreports, side by side.
However, I don't seem to be able to easily make them the same size. This means that the master report looks a bit odd, as one subreport will be just a bit smaller than the other.
I can make them roughly the same size just by repeatedly adjusting the heights of the individual subreports until it looks "alright", but this method is never going to make things exact and is also very tedious.
Surely there's a way to make two reports exactly the same size so that they display fine when includes in the master report?
While subreports aren't aware of each other during the render process, if you're dealing with fixed size elements like charts there's a simple way to accomplish this.
First, make sure you have the properties pane enabled.
Then when you click on a chart you can set its height and weight numerically and be exact:
Set the same size of subreports, but instead of using graphical designer, use properties on the right side. In master report you can mainly just set location of subreports, but size of subreport component does not count.
Hard code the dimensions of your reports/graphs/charts in the properties pane. Make sure your background (parent) level is large enough to contain the other elements.
I am creating a report which contains tables at the top and bottom that are always visible. However, between these are 12 tablixes which optionally appear based on the existence of data for them. When they do not exist there is a considerable amount of whitespace in the middle section of the report which makes the report look awful.
I've tried two strategies to fix this:
Set up one rectangle to hold all tablixes. Set all tablixes to have the hidden property set to be true if CountRows() < 1. Leave no gaps in between the tablixes so as to not leave cumulative gaps.
Set up one rectangle per tablix. Set all rectangles and all tablixes to have the hidden property set to be true if CountRows(dataset for tablix) < 1. Leave no gaps in between the rectangles so as to not leave cumulative gaps.
I can think of no other setting to rid the report of gaps for hidden tables.
How about a table with separate rows that contains all your tablixes (tabli?) .
Hide the row based on the tablix's no data condition.
It doesn't help for left to right though since hiding a column leaves space.
So, I noticed that there were warnings about overlapping objects. I went back through and removed overlaps and my report did much better at reducing white space. It's not perfect, but acceptable.
Overlapping objects screw up the whitespace on reports! I don't get any warnings about overlapping objects but I tried adjusting the report to ensure no objects were overlapping and it fixes the whitespacing issues without the need for tables!
I want to have 6 objects (buttons) laid out inside one view. They should, however, follow some constraints:
Two top buttons should have the same vertical distance from superview (A)
Two bottom - the same (C)
Two in the middle should have their centers at the superview's center line
The vertical distances between all buttons (E) should be the same
and last but not least - the buttons should be square (so the width and height should be the same)
A = C
B = D
Is it possible to have this effect just in the IB, or should I use some additional code for the constraints?
This is a logical request, but constraints are defined using the attributes of views, but cannot not be defined in relation to other constraints. That having been said, there are a number of approaches:
Layout guides: An approach which doesn't require predetermining the any spacing is to have UILayoutGuide objects or, if using iOS versions before 9, just use hidden views, i.e. views with clear background or alpha of zero, in between the buttons.
The idea is to add these layout guides with addLayoutGuide (or add invisible views with addSubview if supporting iOS versions predating iOS 9) in between your six buttons as "spacers", and define the spacers to be the same size as each other, and with constraints between the spacers, the superview, and the buttons that will go in between the spacer. Once you lay that out (showing the horizontal spacer views in blue, vertical ones in red, just so you can see them):
The equivalent VFL for the constraints for those red UIView objects, called vspacerX, would be:
H:|[vspacer1][button1(100)][vspacer2(==vspacer1)][button2(==button1)][vspacer3(==vspacer1)]|
H:|[vspacer1][button3(==button1)][vspacer2][button4(==button1)][vspacer3]|
H:|[vspacer1][button5(==button1)][vspacer2][button6(==button1)][vspacer3]|
And constraints on the blue UIView objects, called hspacerX, like:
V:|[hspacer1][button1(100)][hspacer2(==hspacer1)][button3(==button1)][hspacer3(==hspacer1)][button5(==button1)][hspacer4(==hspacer1)]|
V:|[hspacer1][button2(==button1)][hspacer2][button4(==button1)][hspacer3][button6(==button1)][hspacer4]|
You don't have to use VFL to define these constraints, as any way you define these constraints will work, but it's just a concise format for describing the collection of constraints that I employed.
Anyway, when the view is rendered with those layout guides (or invisible views), it yields evenly spaced buttons like so:
Another approach is to have six "container" views, that would look like:
The equivalent VFL for these six container UIView objects might look like:
H:|[container1][container2(==container1)]|
H:|[container3(==container1)][container4(==container1)]|
H:|[container5(==container1)][container6(==container1)]|
V:|[container1][container3(==container1)][container5(==container1)]|
V:|[container2(==container1)][container4(==container1)][container6(==container1)]|
You can then add your buttons to that, centering one on each of the six little containers and then make your containers clear:
This works, too, but just a slightly different spacing (where the margins are half of the spacing between the views, whereas the other approach keeps the margins the same as the spacing between them.
Stack view: In a permutation of the prior point, in iOS 9, you can also use UIStackView, designed precisely for evenly spacing views. In this case, put two buttons each in three horizontal stack views, and then place those stack views within a vertical stack view. This achieves six evenly sized container views.
See WWDC 2015 video What's New in Cocoa Touch.
The problem with stack views is that they can be used to ensure even spacing between the arranged subviews, they don't ensure spacing before the first arranged view nor after the last arranged view. So, the kludge to get around that is to, for horizontal stack view, include two more zero width views (or zero height for vertical stack views). Then when you use even spacing on the stack view, it also give you what will appear to be spacing before and after all of the arranged subviews.
NSLayoutAttributeCenterX with multiple: Another technique involves defining the attribute:NSLayoutAttributeCenterX and attribute:NSLayoutAttributeCenterY attributes for your six buttons, but rather than using the constant values, use the multiplier field. This technique enjoys a little simplicity, but doesn't always render the desired effect, so I won't describe it unless it's something you definitely want to pursue. I've already entered tl:dr territory here.
Collection view: Another approach is to use a UICollectionView, which handles this scenario gracefully. It's well designed to let you layout cells in a grid.
Hardcoding values: For the sake of completeness, I'll note that you could simply specify specific values for A, B, C, and D (as well as the width and height constraints). You don't even have to worry about setting the E constraints, but rather just set the vertical center constraint of the middle two to their superview, and you're effectively done (because the spacing represented by E should be a natural result of the previous steps, assuming A=C and B=D). If you want to adjust these values on the basis of device size and/or orientation, you can then implement a viewWillLayoutSubviews to adjust the constants for these constraints according to the size of the view.
Update: I have a better solution that does not use spacers. Check it out here.
Ok, this can be achieved very quickly in IB. It's so so simple. Here's a diagram that will help illustrate.
Assume v1-6 are your buttons, and s1-5 are your spacers.
1) in IB control drag out all of the connections shown by the red lines.
2) shift click v1-6 and pin icon (looks like |-I-| ) set the width and height to a definite value. also, set the height and width to be equal.
3) shift select s1-4 (not 5) and set the height to equal. do not give it a definite height, since this should be calculated by the system. you might also need to set the widths of s1-4 to be equal, but don't give them a definite width.
4) control drag from the centre views to the leading and trailing edge and set the centre constraint.
So, you might think, ok, this should work now. It doesn't. Here's my app running in portrait with slightly different colors. Looks good. (Notice, you would make the spacers invisible once you get it setup).
But when I rotate, oops!
What's happening here? The problem is incredibly easy to solve once we understand what's gone wrong. What we want is for IB to not shrink our views. We want IB to make the spacers and the spaces to shrink and grow as necessary, but to leave our views alone. Basically, IB has shrunk the spacers down as far as it can in portrait and to attempt to make everything fit IB has shrunk our views. But we wanted IB to shrink the vertical spaces between views and spacers, not our views. The solution is so easy. All we have to do is adjust the priority of the vertical spaces and all is well. So, select the vertical spaces in IB and adjust the priority to 750. The vertical spacing lines will show as dashed. Done.
Ok, so here's everything as we expect it.
And with the spacers made clear: