After almost 4 years of use, one of my testers noticed something strange with my update panels.
Let's say I have a display mode and it takes 100 pixels in height. The user then switches to edit mode and the updatepanel updates. The window is now 500 pixels in height. The user clicks save and it turns back to display mode, which is only 100 pixels.
Now the dom only takes 100 pixels, but there still is a scrollbar all the way to 500 pixels. If the user shrinks the screen down to 100 pixels, he/she will still see a scrollbar, despite the fact that there's nothing down there anymore.
What the hell is causing this and how do I fix it? It's like the updatepanel doesn't tell the window it doesn't need all that height anymore.
Sounds to me like your control maybe using visibility="visible|hidden" instead of display:"none|block".
Use IE Dev Toolbar or Firebug to see what the DOM structure is during your page state.
It also may just be that your edit mode is too big for its fixed height container. Try not constrain the outermost container so it can grow with the dynamically changing internal content.
The visibility property determines
whether a given element is visible or
not (visibility="visible|hidden").
However, when visibility is set to
hidden, the element being hidden still
occupies its same place in the layout
of the page.
CSS Properties: Display vs. Visibility
Related
I am testing a godot app, where there is a text heading along the top, and there are buttons along the bottom. For now I have a spacer in the middle to keep the heading at the top and the buttons at the bottom.
If I set Project Settings -> Display -> Stretch to disabled, then I can set a font and button size that looks reasonable for my laptop, and the font size for the heading and button doesnt shrink smaller and larger when the window is adjusted.
How do I guarantee and/or test that the size will be appropriate when the application is exported to iOS and Android? Is there some kind of guide that will help choose appropriate (non scaleable) button sizes for all devices?
How Controls are positioned
There are three intended ways to position a Control in Godot:
Placed in a Container. In this case the Container will control position and sizing of the child Control, taking into account "Size Flags".
See also Using Containers, and Containers.
By anchors (anchor_*) and margins (margin_*). They determine the position of the edges of the Control. The anchors are factors, and the margins are offsets.
For example, the leftmost part of the Control will be positioned at anchor_left * parent_width + margin_left, relative to the parent Control.
You will find presets in the "Layout" menu that appears in the tool bar when you have a Control selected.
See also Size and anchors.
By rect_position and rect_size. These are relative to the top left corner of the parent Control.
Ultimately the other ways to position the Control are changing these. And you can also change these even if you positioned the Control by other means… Which is not intended, but supported (because it is useful to add animations to the UI among other things).
Regardless of which one you use, Godot will respect rect_min_size. And yes, there is also rect_rotation and rect_scale which throw a wrench on the above explanation, but they works as you would expect.
And yes, it is not the easier to use system. Because of that, the designer is being improved for Godot 4 (currently on Alpha 3 at the time of writing).
To answer the question the title: If your stretch mode is set to disabled, and your UI is anchored to the top left (which is the default), you would resize the window and the UI would not scale or adapt to that change. I don't think you don't want the UI to adapt.
Making a top and bottom bars with containers
You can use a VBoxContainer, since we will have three bars stacked one on top of the other, vertically. And yes, the second one is a spacer.
First of all, you want the VBoxContainer to take the whole screen. So set it to the Layout preset "Full Rect". So, yes, we are placing the Container by anchors and margins.
And second, we want the spacer to take as much space as possible. To archive this we set "Expand" flag on size_flags_vertical of the spacer. This is what Size Flags are for.
And, of course, what you place inside the Container might or might not be more Containers.
Making a top and bottom bars with anchors and margins
Give the top bar the "Top Wide" preset. It will set the margins and anchors to have it stay at the top, take the full width, and take its minimum height.
And give the bottom bar the "Bottom Wide" preset. It will set the margins and anchors to have it stay at the bottom, take the full width, and take its minimum height.
You would need no spacer.
And, by the way, I remind you that anchors are margins are relative to the parent. So you can nest this approach. And yes, Controls that are not containers can also have children Controls
About stretch modes
As you know you have a choice between:
viewport: All the sizes will be computed with the original resolution, and then the resulting sizes are scaled to the resolution of the device.
2D: will also compute all the sizes with the original resolution, but instead of scaling the resulting sizes, it renders at that size and scales the image.
disabled: It will compute all the sizes with the actual resolution of the device. No scaling will happen.
Since both viewport and 2D, the size of the UI will not be computed with the actual resolution of the device. This makes the approaches I described to have the UI adapt less effective (less useful or less necessary, depending how you look at it). And thus, if we want to use those approaches effectively we will want the stretch mode set to disabled.
And, of course, there is also the aspect setting.
See also Multiple resolutions and Support multiple form factors and screen sizes.
Designing for small resolution
You can test on the editor how the UI adapts to the resolution, either by resizing the window, or by setting the Test Width and Test Height in Project Settings. You can, of course, also test on an actual smartphone. For instance, I often launch the game in my Android from the Godot editor when developing mobile games.
Circling back to the stretch modes, this is what happens with the text:
disabled: The text stays the same size. This means that the UI can become too small for the text.
viewport: the text scales. This means that the text can become too small to be legible.
2d: the text scales too… except since it is a image scaling it can become blurry, even harder to read.
If we only consider the text, there is no good option. Now, either design the UI for the specific target resolution… Or make one that can adapt. And for one that can adapt, I believe disabled is the best stretch mode as I was arguing above.
And of course you can script it
If you need to run some code when the resolution changes, you can connect to the "size_changed" signal of the root Viewport. And if you need to figure out if the device is in landscape or portrait mode you OS.screen_orientation, and if you really have to, you can create a custom Container.
This Stackblitz example opens a simple dialog which contains a radio group in the mat-dialog-content div.
You can see that the dialog-content shows an ugly scrollbar:
This does not happen when other components are used: e.g. input, etc.
Using chrome dev-tools, I can see that the mat-radio-buttons have a height of 20px:
but the mat-radio-group only has a height of 17px:
Is this a bug in angular material components (the example uses version 12.0.4), or is there a simple workaround/css that we can use to get rid of the scrollbar?
I've tried explicitly setting the height on the mat-radio-group, but this has no effect.
Notes:
in production we do of course have many dialogs and some of them are large and need the scrollbars
we need an application wide solution/workaround
simply hiding the scrollbars is not okay: it must remain auto so that the dialog can react to size changes (e.g. user rotates device, some items are shown/hidden dynamically, etc.
For now we came up with a workaround that fixes the issue in all our 30+ dialogs.
The nice thing is that we can apply it in one place, in styles.scss:
.mat-dialog-content {
padding-bottom: 10px !important;
}
We just add a padding to the bottom of the dialog content area and then scrollbars: auto works as expected in all our dialogs (small and large). i.e. when you make the browser window larger/smaller, the scrollbar is automatically shown/hidden.
And it also works when there are multiple mat-radio-groups in one dialog.
The additional padding between the content and bottom dialog-actions is acceptable for our ui.
Stackblitz example with workaround
The reason this happens is due to the ripple effect on the radio button - which takes up additional space and causes the scrollbar to show. See https://github.com/angular/components/issues/20344
There are a number of ways to resolve this, such as using padding or margins on the components or on the dialog content itself like you did. The important thing is that there is enough space added to accommodate the ripple.
I have a long form in a panel with lots of controls, however the Canvas/panel editor has a limited height of about 1000px and refuses to scroll to allow adding more controls.
I am able to make the panel 2000px and enable overflow to get the panel itself to scroll once the app is deployed, but how do I manage to drag/drop new controls/widgets?
TIA
At the bottom of the canvas is a round control which allows it to be extended beyond the default and therefore allows long controls.
A page's main panel should have a dimension property in the property editor, that specifies height and width. I'm able to set it to much larger values (e.g. 5000 pixels).
Once the main panel is large enough, you should be able to scroll down in it and drop new widgets where you need them to be.
It's also easy to accidentially drop in new panels and then stuff new widgets into the wrong panel, so make sure the panel structure is really what you believe it is (e.g. via the structure editor).
I have a TextInput in a container. I need the horizontal scrolling capabilities of the container so that when the textInput is to big it allows me to scroll to see the text on the left and right. The scrollbar track and thumb were set to null so I can see the text.
trackSkin: ClassReference(null);
thumbUpSkin: ClassReference(null);
thumbOverSkin: ClassReference(null);
thumbDownSkin: ClassReference(null);
thumbSkin: ClassReference(null);
Now I want to listen to an event or watch a property that changes when the horizontal scrollbar activates. Then I would like to set a padding on the container or left and right property on the text input so that the left and right arrows do not get in the way of the user to see the first and last characters.
Thanks
Before adding listeners and accessing the HScrollBar of the Scroller, you may find this setting/variable of some use: measuredSizeIncludesScrollBars
From the API: (Please forgive the terrible formatting)
If true, the Scroller's measured size includes the space required for the visible scroll bars, otherwise the Scroller's measured size depends only on its viewport.
Components like TextArea, which "reflow" their contents to fit the available width or height may use this property to stabilize their measured size. By default a TextArea's is defined by its widthInChars and heightInChars properties and in many applications it's preferable for the measured size to remain constant, event when scroll bars are displayed by the TextArea skin's Scroller.
In components where the content does not reflow, like a typical List's items, the default behavior is preferable because it makes it less likely that the component's content will be obscured by a scroll bar.
In the event this doesn't work, I would probably add an event listener attached to the lifecycle of the Scroller. During that event handling, I would check to see if the Scrollbar was null or not. If it wasn't, I would store it off to the side, but not before adding a listener to its "show" and "hide" event. That way, you can kick off whatever you need to whenever the scrollbar changes its state.
I have a class which extends UIComponent and draws directly onto a Sprite contained within. Currently I'm (probably incorrectly) listening to the Event.RESIZE event and drawing the contents when the width and height are non-zero. The problem is that even though I've passed percentage widths to the instance tag, it doesn't appear to be resized along with other Flex components on the page, certainly the resize event isn't being fired at all.
I've hacked it for the moment by binding the width and height to a container which does resize, but how should I really be handling this?
Update :
It turns out I was setting the width and height somewhere in the redraw method (I have no recollection of why I did this!). I shall go hang my head in shame now...
I think you need to provide more information. I'm doing exactly the same, and it works smoothly for me. Perhaps the answer lies somewhere else: e.g. exactly what type of container do you use? Isn't it possible that the space gained/lost on resizing gets allocated to some other component within the cointainer? Try substituting your own component with an mx:Box with some colored background, and see if that resizes with the container.