Hi,
I want to implement the usage of viewState in our application. Therefore i run into other bugs, but besides that i have the problem that most of our listgrids we are using are defined with a width of 100%. So if the user has a small display the ListGrid fills the whole width and if he has a large display it also fills the whole width.
The current implementation of viewState does always return some absolute-pixel-width per ListGridField. After doing the calculation with width-attributes in percentages for each field it's understandable and easier to get the pixel-width insted of the percentages.
But if we are using the current implementation it will break the users listgrid if he ever switches the display-size (or resizes the browser). Then the listgrid is resized to the pixel-sizes fields which were saved after resizing on a large screen. This responds to a result, where some fields are hidden on the right, because the viewstate indirectly indicated that the listgrid is also large. So if you switch from a small to large screen, the white-space at the right side is always visible (and not needed) and switching from a large screen to a small screen you maybe not seeing all fields because they are only visible by scrolling there.
One solution to this would be before saving the viewState replacing all pixel-width in the fields wih a percentage-width.
This could be done by this snippet:
If this "relativeViewState" is saved in the backend this could be delivered at the initilaization of the view. But it seems that the viewState is fixed to a absolute-pixel width per field, so the whole viewState is ignored.
To build a workaround for this, we could send the proportionalViewState to the client and do the reverse-calculation (percentage-width to absolute-width) and after this do setViewState.
This doesn't seems to be a good solution. Is there a solution to work with differend screen-resolution (display-sizes)?
I have tested this behavior in all current browsers (IE 11, Firefox 34, Chrome 39) with the latest nightly build (SmartClient_v100p_2014-12-17_Pro)
Best Regards
I want to implement the usage of viewState in our application. Therefore i run into other bugs, but besides that i have the problem that most of our listgrids we are using are defined with a width of 100%. So if the user has a small display the ListGrid fills the whole width and if he has a large display it also fills the whole width.
The current implementation of viewState does always return some absolute-pixel-width per ListGridField. After doing the calculation with width-attributes in percentages for each field it's understandable and easier to get the pixel-width insted of the percentages.
But if we are using the current implementation it will break the users listgrid if he ever switches the display-size (or resizes the browser). Then the listgrid is resized to the pixel-sizes fields which were saved after resizing on a large screen. This responds to a result, where some fields are hidden on the right, because the viewstate indirectly indicated that the listgrid is also large. So if you switch from a small to large screen, the white-space at the right side is always visible (and not needed) and switching from a large screen to a small screen you maybe not seeing all fields because they are only visible by scrolling there.
One solution to this would be before saving the viewState replacing all pixel-width in the fields wih a percentage-width.
This could be done by this snippet:
Code:
var viewstate = listGrid.getViewState(); a = viewstate.replace(/width:(\d*)/g,function(s,aWidth){ var theListGridWidth = listGrid.width; if(aWidth != ""){ return "\""+Math.round((parseInt(aWidth)/theListGridWidth)*100)+"%\""; } else{ return "" } }); console.log(a);
To build a workaround for this, we could send the proportionalViewState to the client and do the reverse-calculation (percentage-width to absolute-width) and after this do setViewState.
This doesn't seems to be a good solution. Is there a solution to work with differend screen-resolution (display-sizes)?
I have tested this behavior in all current browsers (IE 11, Firefox 34, Chrome 39) with the latest nightly build (SmartClient_v100p_2014-12-17_Pro)
Best Regards
Comment