I am trying to accomplish something and I am not sure if it is completely possible.
I have a Telerik MVC Grid using ASP.NET MVC.
The default paging size for the grid is 10, however I want to be able to adjust the size the page (the number of rows) based on the size of the user's resolution. Is this possible?
Thanks,
Paul
It is definitely possible.
I created a solution that accomplishes the same thing - however you will have to tinker with it to get the proper height of your grid on it's own (excluding any menus/headers/footers etc.)
These steps should get you there:
Firstly - you will need to add an "onLoad" event to your MVC Grid:
.ClientEvents(events =>events.OnLoad("onLoad"))
Next - Create a Javascript event to handle the "onLoad" in your $(document).ready():
function onLoad(e)
{
//Bread and Butter will go here.
}
Finally - the last step will be to calculate the space that is not taken up by the grid (Firebug can be helpful) and tinker with it until your "formula" works out in most browsers:
function onLoad(e)
{
//Gets the height of the Window. ($(window).height())
//Subracts the height of any menus/headers/footers (in this case 275)
//Then divide by our "magic number" which you will need to tinker with
//to determine how the grid looks in different browsers. (in this case 28)
var height = Math.floor(($(window).height()-275)/28);
var grid = $("#YourGrid").data("tGrid");
grid.pageSize = height;
}
Formula :
$(window).height() - [Occupied Space] / [Magic Number]
[Occupied Space] - Total CSS Height of all objects above the Grid.
[Magic Number] - You will have to play with this one and try it out on
different browsers until you get the expected results.
That should automatically adjust your your number of rows based on your window height.The only tricky part is figuring out your own "formula" using the amount of occupied space and then picking a magic number to divide by.
Hope this helps!
Related
I need the points of my chart to have a fixed width (say, 100px each). If the needed space exceed the width of the chart, I just want to be able to scroll horizontally (with the scrollbar.enabled parameter set to true).
This is the basic setup, without setting the points width:
http://jsfiddle.net/wxxdne19/
If I set the column width like this:
http://jsfiddle.net/wxxdne19/1/
The tickPixelInterval parameter is ignored (as the documentation says, of course).
I tried a bunch of other things, but none of them worked, and I ran out of ideas. How can I do what I need?
Update
To clarify what I need, think of it as if I have a column chart, and I need to force all the columns to have a fixed width. Something like this:
http://jsfiddle.net/4rx4snjh/
But, instead of the columns overlapping each other, I'd like the scrollbar to do its job :-) Furthermore, I need it to work with any kind of series (lines, areas...), not just columns.
It seems that the solution here is to compute extremes manually and set them in load event:
load: function() {
var chart = this,
xAxis = this.xAxis[0],
visibleColumns = (xAxis.width - pointWidth) / pointWidth;
xAxis.setExtremes(pointStart, pointStart + pointInterval * visibleColumns);
}
Live demo: http://jsfiddle.net/kkulig/mpancrbc/
For some reason (bug probably) xAxis.min value must be initialized when the container width is a small value (in my example it's less that 400 px or so).
API reference: https://api.highcharts.com/class-reference/Highcharts.Axis#setExtremes
Hi I'm using a GridPane thats 3x3 each one with different widths (some are percentage based, some are flat numbers) so with respect to the ones that are percentage based, is there a way to get a DoubleProperty of the width/height of a specific cell within a GridPane?
This isn't the preferred solution but I was able to throw another GridPane within the cell, set fill width/height to true for that, and bind to the width/height of the inner grid cell.
I just had a look at Firemonkey's grid implementation and it turns out that it is a very simple implementation (only 1800 lines which seems not much for a grid implementation). It does almost no custom painting but does instead aggregate a lot of other controls - which seems to be the Firemonkey style of doing things.
For example, each column keeps an array of controls - one for each cell. For a normal text column with 1,000,000 rows, the grid would keep 1,000,000 edit controls in memory - which seems a little crazy to me. (EDIT: not so sure now if that assumption is right. It seems to take the visibility of cells into account, which could mean it does provide something like a virtual mode, but I'm not quite sure...)
My question: Without any doubt, this component-aggregating design of Firemonkey seems simple and elegant but does it really scale well with the amount of data that has to be displayed in the grid? I cannot imagine that it does perform well with a large number of rows. What is the Firemonkey way of handling large amounts of data?
Thanks for any input.
The FireMonkey grid only has controls for the number of visible lines.
So if you have a grid with 10 visible rows and 3 columns, it will create 30 cell controls.
Filling the grid with 10.000 records is no problem: when you scroll the 30 cell controls are reused and mapped to the new visible rows.
And yes: I did some tests with this because we have TMS grids with 100.000 records :-).
If you use OnGetCellText (so not TStringgrid, which is very slow with lots of records, especially TMS grid (based in VCL stringgrid)) it is very fast (OnGetCellText only retrieves data of visible cells). We use this technique in combination with our data objects (these are already loaded, so no need to fill each cell of the grid with the string value again...) and both TMS and FMX grids are very fast with 100.000 records or more!
Although the question seems simple, I couldn't find the answer to it.
I have a DBGrid component with lots of columns, and as a result they don't fit into the page and scrollbar appears. I also have column-autofix mechanism, which makes each column have width of the longest element in the table. When I scroll DBGrid to the right-end there is an empty space after the last column. How to get rid of this space?
One solution that I see is to stretch the last column to fit the empty space. But I don't know how to find the length of this empty space! DbGrid.Width and DbGrid.ClientWidth only give length of the component part, but not the real length of the table. Any hints??
It's not always easy to get DBGrid to behave the way you want it to behave. I decided to use alternative db grids after one project with the standard implementation and I never looked back.
If you can use an alternative grid, you have many options to choose from. There's even a topic here on SO with lots of pointers. Among the free-with-source options, I've always been quite fond of the JVCL project.
Just one last tip: there are grids that offer options and customizing possibilities beyond what you can dream of. Be aware that there's a cost attached to this degree of freedom, e.g. it can make the component slow, hard to integrate in your code, or both.
I think I have found a solution (although it seems a little strange). In order to find the difference between column widths and real width of the DBgrid (that means find the width of the empty space left after last column), we need to keep track of which column is shown on the left now (what is current column that is scrolled to). We can do that using OnDrawColumnCell event, since it will draw only columns which are scrolled on now. Then we need to calculate sum of widths of all visible columns, and subtract that from DBGrid's width. P.S. Sorry for bad english
Ex code:
For i:=0 to Last do
if Vis[i] then
Begin
Sum:=Sum+DBG.Columns[i].Width;
Inc(Cnt);
End;
if dgColLines in DBG.Options then
Sum := Sum + Cnt;
//add indicator column width
if dgIndicator in DBG.Options then
Sum := Sum + IndicatorWidth;
Dif:=DBG.ClientWidth - Sum;
The below answer is quite good, but not effective at all because it is placed in the OnDrawColumnCell event, so if there are a large number of rows and/or collumns, the performance might fall.
Instead of that, place the same code not in a painting event, but int the AfterOpen (and AfterRefresh) event of the source dataset in order to execute it only once for each resultset.
A lable sized like a rectangle with no text but has a border and is invisible (for a visual rectangle on the form around controls but not to contain the controls) or a panel?
What you want to use is a GroupBox. Not that it really matters, most likely, but a label should be cheaper than a panel.
The answer is; it doesn't matter which has the smaller footprint, and if it does you have a design problem (i.e., you have way too many controls on your form). Anyhow, you should just use the control that fits the job, in this case, a Panel or a GroupBox.
If this is really a problem, then the best way to provide a visual separation between controls is to handle each tab page's Paint event, and use e.Graphics.FillRectangle(...) to draw the separator. You would get rid of a very large number of controls that way.
If you can't do something as simple as just drawing a rectangle underneath each control on each tab page, you can write a code-generating routine that you run one time on the form, and for each tab page you generate something like this (by iterating through all the separator controls on the page):
List<Rectangle> rects = new List<Rectangle>();
rects.Add(new Rectangle(10, 40, 200, 5)); // position of first separator
rects.Add(new Rectangle(10, 80, 200, 5)); // position of second separator
// etc.
Then you copy-and-paste these generated code routines into your application, and use them for each page's Paint event, like so:
SolidBrush brush = new SolidBrush(Color.PeachPuff);
foreach (Rectangle rect in rects)
{
e.Graphics.FillRectangle(brush, rect);
}
Then you delete all the separators from your tab control. What you should end up with is an array of type List<Rectangle> (one list for each page) that you instantiate and fill in the form's Load event or its constructor (using the generated code).
I have to reiterate what Ed said, though. .Net forms can have a lot of controls on them without any real problems, so if you're running into problems stemming from having too many controls on the form, you might be better off redesigning the whole thing.