I have created a GridControl with a few fixed width and 2 autowidth columns.
I have set the autowidth columns like this:
<dxg:GridColumn
Width="2*" FieldName="Name"
FixedWidth="False" Header="Name" />
<dxg:GridColumn
Width="6*" FieldName="Subject"
FixedWidth="False" Header="Subject" />
I intended to have a 2:6 proportion regarding the widths of those columns, so I set their Width to 6* and 2* as proportional values.
Strangely, the following happens.
When they are set to 6* and 2*:
When they are set to 5* and 2*:
Clearly, if the multiplier is below 6, it works as there are no multipliers (the columns fill equally the remaining space), but when it is over 5, the proportion goes mad and shrinks the lower multiplied column.
According to their support, it supports proportional settings.
How can I create a 6:2 proportion without setting a MaxWidth?
I suggest to set AutoWidth property of TableView to False, it should then work as expected. Also, I believe you don't need to set FixedWidth on columns (it only works in AutoWidth mode).
Hope this helps!
Related
I am implementing a container which algins its children in a row and does kind of a linebreak when there is no horizontal space left. Thus, the required height depends on the available width. For larger widths, more content fits in one line and less lines are needed leading to less height. For smaller widths, less content fits in one line and more height is needed.
I subclassed the container and implemented the needed logic. The minimum width of the container is set to the minimum width of the widest child which would display one extreme case where there are stacked lines, some of them with only a single child inside them.
The problem is as follows: The window displaying the container has a very large height, for some cases even larger than my monitor. I am able to resize the window except that I cannot decrease the width. It turns out that the documentation for height-for width geometry management says:
Next, the toplevel will use the minimum width to query for the minimum height contextual to that width using gtk_widget_get_preferred_height_for_width()[...]. The minimum height for the minimum width is normally used to set the minimum size constraint on the toplevel (unless gtk_window_set_geometry_hints() is explicitly used instead).
Thus, the behaviour is expected as the window uses the height for the minimum width as its minimum height leading to the previously mentioned extreme case. This seems to be counterintuitive as in my case and an example used in the documentation (textflow in labels) the height will be maximal when the width is minimal vice versa. Only when actually allocating the available space, gtk considers to assign smaller heights when a larger width allows that. Even when using high widths in the window's default size and size request only the minimum width of the container is considered to derive the required height of the window.
The documentation already somehow contains a workaround, namely the geometry hints. But this seems to be a verbose and static way of sizing the window when the default width of the window together with the height-for-width-function could theoretically be used to easily determine the size of everything. The size-allocation already works as intended, only the size-negotiation cancels the benefits the height-for-width function could bring here. Is there any nice way of implementing the functionality required to fix the window sizing?
It seems as there is no intended workaround for this problem the way I searched for. The gtk size negotiation goes from bottom to top when requesting sizes and top to bottom when allocating. Thus, my container has no way of knowing how much width its parent could assign to it.
I solved the problem by adding a property which defines the minimum of children per row. This can be used to increase the minimum width and therefore decrease the minimum height. I only use it for the minimum width calculation while actually ignoring it doing the real size allocation which only is a minor detail I will document.
This documentation will be part of the code example I will provide as an answer to my old post which was about implementing a FlowBox with the behaviour described above.
I'm confused with the bar with adjustment in MATLAB, for example, when use bar like:
bar(randsample(0:0.0001:1,100),randn(100,1))
I get an image like this:
It seems like the bar is too thin to have a good look. After searching for help, I can use the code like:
bar(randsample(0:0.0001:1,100),randn(100,1),50)
and I get this:
Seems much better. But if I change the sample number from 100 to 10, the same code won't work.
bar(randsample(0:0.0001:1,10),randn(10,1),50)
I hope I have explained my issue clear. It seems like the third parameter of the bar function is a relative width, which correlates to the input size of the first and second parameter. Can I fix the absolute bar width no matter how many data points input? or there is a better function to draw figures like this? Thanks a lot for any help!
user #am304 is right about the width parameter
What happened in your code is that you set x values to results from randsample(0:0.0001:1,10)
If you give your plot a width of 1 it means that 2 bars which are directly next to each other would touch each other with an equally spaced x.
In your case, you have an irregular x spacing.
The width of the bar is determined by the minimum distance between two x values (which you get from randsample()). Sometimes this space - and therefore the width of your bar - is very tiny. Sometimes it is broader.
Change the with to 1 and make multiple plots. You will notice that two are always touching each other and no one is overlapping and all the others have spaces in between. If you change the width to 50 the plots will somethimes overlap heavily (depending on the randomness from randsample) because your bars are 50 times bigger then the minimum width between two x values.
In case of your randsample(0:0.0001:1,100) example it is just more likely that two values are close to each other, therefore increasing the width helps you see something (because the bars overlap).
From the documentation:
bar(___,width) sets the relative bar width, which controls the
separation of bars within a group. Specify width as a scalar value.
Use this option with any of the input argument combinations in the
previous syntaxes.
The example provided is as follows:
Set the width of each bar to 40 percent of the total space available
for each bar.
y = [75 91 105 123.5 131 150 179 203 226 249 281.5];
bar(y,0.4)
So bottom line is: the width is specified as a % of the total space available for each bar. Yoru problem comes from the fact that you have far too many bars, so the space available for each bar is tiny. Setting the width to 50 or 5000% of the space available just means that each bar will overlap quite substantially on the neighbouring bars. Because you have so many, the middle plot looks "reasonable" as I suspect a lot of the bars are overlapped and a lot of them are at zero, so you just can't see them. If you go down to a sensible number of bars, as in your last example, then setting the width to 5000% looks ridiculous as you found out.
So to summarise: reduce the number of bars and specify the bar width between >0 and 1 (1 being no gap, all the bars touching each other).
A better way to plot things with random x locations is to use stem. By default, it draws a line from the zero line to the datum, with a circle representing each datum. But this can be modified. For example:
stem(randsample(0:0.0001:1,100),randn(100,1), 'Marker','none', 'LineWidth',4)
creates a plot similar to your second attempt, but with bars of a fixed width (4 points).
I am struggling to get my grid to reliably display its column widths evenly when using api.sizeColumnsToFit().
I have configured my grid to resize the columns when the parent div/browser window resizes:
this.gridOptions = <GridOptions>{
onModelUpdated: () => {
this.gridOptions.api.sizeColumnsToFit();
},
onGridSizeChanged: () => {
this.gridOptions.api.sizeColumnsToFit();
}
};
This works, but the resulting column widths are more often than not uneven. Please see the first and second day of the month for week 13 below:
Any suggestions to make this more reliable will be very welcome.
Here is a plnkr with a possible solution for you. In essence here is what you could do:
var windowWidth = document.querySelector('#myGrid').offsetWidth - 170 - 17,
// calculate the window width minus any columns you don't want to size for
and a little magic number for the vertical scrollbar (17 was for chrome on mac)
sizableColumns = gridOptions.columnApi.getColumnState().map(e=>e.colId).filter(e=>e!='athlete'),
// get the colId of only the columns that you want to resize
sizableColumnWidth = Math.floor(windowWidth/sizableColumns.length);
// calculate the width of each column by dividing the available width by the number of columns
sizableColumns.forEach(e=>gridOptions.columnApi.setColumnWidth(e,sizableColumnWidth))
// iterate through the columns you want to resize and set their new column width
However, I think that you might be better off by considering how many users are going to be resizing their browser windows... not only that but resizing their windows slowly multiple times. Check these posts:
http://davidgoss.co/2014/04/15/users-do-resize-their-browser-windows-take-2/
https://medium.com/#stephenkeable/do-users-resize-their-browser-windows-or-is-it-just-developers-and-designers-e1635cbae1e1
Both of these posts indicate that roughly 2% of desktop users are resizing their browsers. And a much smaller portion will be resizing their browsers slowly multiple times. Perhaps you simply tell these <1% to not resize their browsers like they do, or allow for the columns to be manually sized so that if they do notice this odd behavior they can resize the columns themselves.
Technical Note:
Your reported behavior is happening because the algorithm to size the columns to fit is quite sophisticated. It takes into account the relative sizes of all the columns and widens them appropriately, so if you had 4 columns sized 100, 200, 100; and you resized the window, then the middle column will still appear as twice the size of the others.
The algorithm is also placing whatever is leftover in pixels to the first column so if you have 9 columns and 100px to fit it into, 8 columns would be sized at 11 px and one would be sized at 12. That way the columns will truly "fit" and not leave a few pixels not filled by columns (like my suggested option)
I'm trying to make a table which has the exact size of the printing area of my paper. But it seems I can't use specific measurements to make it that. Also, if I delete a row, I'd like it to change the height of every row accordingly so the total height stays the same.
Any advice?
For the table width you may select the table and then choose Table -> Table Properties, select Alignment = Manual and define the exact size of the printing paper.
The automatic height adjustment after a row deletion is not possible (at least at my knowledge)
Is it well-defined in iText to call setMinimumSize(15) on some cells in a row, and setFixedSize(15) on the other cells of the same row?
What I would like is for iText to increase the row height to accommodate the text in the cells whose minimum height is set, while letting text in cells set to a fixed height clip. Is that what iText does?
If not, how do I achieve this? Thanks.
While we're at it, am I correct that calling neither setMinimumSize() nor setFixedSize() is equivalent to calling setMinimumSize(0) -- iText makes the cell as tall as it needs to be to accommodate the text?
This is with iText 2.1.6.
I already explained in a comment that setFixedHeight() always gets preference. If you use setMinimumHeight() and setFixedHeight() in the same row, and you define a minimum height along with a fixed height, the fixed height prevails.
if the minimum height is set to 30pt and the fixed height is 60pt, the height will be 60pt, no matter how much content is added to the cell.
if the minimum height is set to 60pt and the fixed height is 60pt, the height will be 60pt, no matter how much content is added to the cell.
if the minimum height is set to 120pt and the fixed height is 60pt, the height will be 60pt, no matter how much content is added to the cell.
If different fixed heights are defined, the highest value is taken. For instance: if you have a row where one cell has a fixed height (e.g 120 pt) that is higher than the fixed height of another cell (e.g. 60 pt), then the highest value (in this case 120) prevails.
You claim that this isn't mentioned in the book I wrote. Please note that the book counts about 600 pages. A lot of text I wrote was edited away by the publisher. Otherwise the book would have been a thousand pages and more.
You could have written a small test example, such as the FixedHeightCell example. Please take a look at the resulting PDF. In row D all the cells have a fixed height of 60 pt. In row E, most cells also have a fixed height of 60, but the cell in column 4 has a fixed height of 120, hence the height of the row is 120. Then there's row F, with a fixed height of 60 pt and a minimum height of 120 pt. Although we add text that doesn't fit the cell in column 2, the content is truncated.