[Feature-12920]Determining size of View

Is there a way to get the current size (width and height) of a View? Or the size of the web browser window that the view is being displayed in?

I can access the defaultSize property but this value is constant. My intention is to have the view’s root set to percent mode to fit the window it is in, and then use its size to scale and position other components. The main reason for this is to bind this size value to label’s font size as they do not shrink as their containing view shrinks.

I’m expecting something along the lines of the Vision method system.gui.findWindow(‘window name’).width/height.

I don’t know about getting the specific dimensions of a view (I’m not sure what the use case is - could you elaborate?) but I do see some utility in getting the overall browser ‘viewport’ dimension - which is actually very easy to access in pure Javascript. I’ve added an internal feature request to see if we could expose this property, or maybe more properties on Javascript’s built-in Window object to users; either through session props or some scripting method.

1 Like

The use case for this would be (in Perspective) to scale text (of a button or other label) along with a button size. For example, if the parent view is in percent mode the child components (ie button and label) will shrink as the web browser window shrinks, however the actual size of the text will not shrink. This causes issues like the text of a button to extend past the inside of the button graphic.

In other words, when a parent view is in percent mode, children’s height/width are percent values but other properties are not. I would like to use the web browser’s dimensions to scale those other properties.

Has there been any progress on this feature, or any work around for the time being?

While components might not be aware of the Viewport size, they are aware of their own size. You should be able to create new Styles (something along the lines of “dyn_font_sm” and “dyn_font_lrg”), and use an expression structure to bind the PROPS.style.classes property to POSITION.width and POSITION.height.

This is close to what I am trying to do. The problem is that since the POSITION.height and width are percentages those values don’t change as the browser size changes. Ie if a buttons POSITION.width is set to 0.5 (50%) it will scale its width to take up half the screen but it’s value will always be 0.5.

If I knew the size of the open web browser in pixels, I could convert those percent values to pixel values for any component and based on that I could scale the PROPS.style. accordingly.

Ah, yes, that wouldn’t be much help then, would it?

You are trying to do something that modern web browsers try very, very hard to hide from the webserver. Good luck.


You could do that, but we’re not likely to add this as a feature for a couple reasons:

  1. It’s becomes a very expensive operation to try and track sizes of DOM elements. The performance hit is not insignificant for simple pages and for large pages, could result in a much slower system. While technically possible, it’s a bad idea.
  2. Your goals are far better served by using style classes and media selectors. This will result in a more maintainable project structure if done correctly, and is far far more performant.

Phil is right, the browser simply isn’t optimized to do this sort of thing. Yes, it’s possible, but that means the browser is drawing these components at least twice, and realistically probably more than that just due to event cascades as components shift and resize.

Have you tried using style classes to satisfy this need? It will be far faster than what you are asking for. Far faster than even setting the font size in the style: { } block of the component since ‘style classes’ end up rendering via pure page-loaded css, instead of an inline-style.

1 Like

Did you find the solution for getting run-time browser resolutions?

No, I didn’t unfortunately

To add to this since It looks like its fallen by the wayside – React has very simple ways to poll browser width and height.

While this is an expensive operation if done on the component level, and exposing those parameters in mobx(what I think you’re using for JS state management) so that they aren’t calculated by every component.

Since there is a single source of truth, and a single set of calculations made this costly operation becomes almost negligible. Components I’m building don’t need to calculate anything, but will need references to overall width.

Currently my structure for a top app bar with responsive design has 8 breakpoint containers nested in various ways because it needs different looks based on width and this is the only way to accomplish the task.

I have a left side docked container view that need to change its nav items based on various breakpoints, but that container doesn’t change size. It get disqualified for a breakpoint container. The only thing that needs to change is what is visible based on window width. Currently this seems like an, impossible task without window width, or any way to reference it.

BIJC do a free module here which seems to do what @scott.key is describing.

I have used it to determine what the screen orientation is for different types of dashboards (my original thread: [Feature-16079]Perspective screen orientation).



Has “this.position.width” prop been removed in later versions? Or do we need to add a value to the position set? If so, how to get it to update itself?

Found the “page.props.dimensions.viewport.width”, all good! :smiley:

No, but it does assume that the container in which the component referenced by this lives is a coordinate container.

Does that mean I cannot access {this.position.width} while the component is inside a flex container (does not seem available).
For my case, I'm attempting to show (or hide) columns in an AlarmStatusTable component based on what side of the responsive>breakpoint setting the current width is... or is there a better way to detect if that AlarmStatusTable is in in table mode or card mode?

Correct. Within a Flex Container you would have access to grow, shrink, and basis within the position object. You'd actually be beter served using the following structure:

L_ BreakpointContainer
   L_ AlarmStatusTable
   L_ AlarmStatusTable

This would allow for configuring the AlarmStatusTable differently for either side of a responsive breakpoint without having to adjust that configuration based on size.