Feature Request: Change a control height / width without resizing

I’ve just filed a feature request in feedback fo an option to allow Window (or any other control that can contain other controls) to have it’s height / width adjusted without adjusting the contained controls that happen to be locked to bottom or right:

<https://xojo.com/issue/64046>

Here is the text of the request to explain why such a thing would be useful. Please sign on if you think it would be helpful.

The current system of locking controls to edges of windows is excellent, however it would be even better if there was a method of overriding these constraints in the window editor for a period of time without the need to turn on and off each setting on the controls.

For example take the attached project. Open it in the IDE and select Window1. It is a complex layout for a dialog or sheet window. On the window you can see there are three panels. The top “variables” panel, the middle “filters” panel and a lower “options” panel. In the window editor increasing and decreasing the height shows that the “Filters” panel grows and shrinks, while the top and bottom stay the same size and stick to their respective locations. All of that is fine and as desired.

Consider now that you wish to adjust the design of the window. You decide to increase the size of the listbox in the “Variables” panel. So you do the following:

  • Drag the height of the “Variables” panel deeper.
  • Drag the “Filters” panel, “Options” panel and buttons lower on the window, so they are not underneath the “Variables” panel.

All good so far. However, now the tricky bit. If you look at Window2 you can see the same window after the above controls are moved. As you can see some controls are now hanging off the bottom of the window. So we need to make the window taller. You select the window and drag its height and rather than getting a larger window that encompasses the controls the “Options” panel gets lower still and the “Filters” panel grows in size. The same thing happens if you enter a new value for the height of the window in the inspector.

In order to solve this problem you end up having to:

  • Turn off the lock bottom on all controls that are set that way.
  • Adjust the window height
  • Turn back on the lock bottom settings that you removed.

The last step can be quite challenging. In my example it was relatively simple as I have a few group boxes and buttons to adjust. However, if the controls weren’t laid out in groups it would be much harder.

What I would like is a method of resizing the window and temporarily telling the system to ignore any lock bottom / lock right settings. For example if I could hold down the options key and drag the window size and it just changed the window size, that would achieve the goal. Preferably I would like a way of doing it via the inspector panel too. For example, enter the new height for the window and pressing Option-Return to change the height of just this control. Equally changing the width would also benefit from the same options.

Equally valid but not as attractive would be an inspector option that allowed the constraints to be turned on and off. I think this would be more obvious to a beginner but somewhat more clunky in use.

I thought for a moment that the “lock position” option was going to allow me to do what I wanted. However, it doesn’t. Locking the position of all control and dragging the window height still changes the location of the controls. Which you would think is a bug.

Finally, this issue doesn’t just apply to Window the height / width, it also applies to any control that contains other controls, such as a group box or canvas. The same lock bottom right applies to the the contained controls and thus would benefit from a temporary way of ignoring the lock properties while resizing their container. In my example “option-dragging” the height of the “Variables” group box would not adjust the height of the Y Variables listbox, even though the list box is locked to the bottom of the group box.

Isn’t that called Group / Ungroup ?

@Emile_Schwarz
Sorry, I don’t follow. How would you ungroup the controls from the window they’re in to resize the window?

Edit: I mean you could cut all the controls from the window and then resize it and paste them back and reposition them. somewhat drastic and you loose all your guides.

Edit: If you download the project from the feedback request and open Window2. How do you adjust the window height to encompass all the controls.

Group, in your case.

Do you know about RubberView ?

If no, check of they do provide this feature.

RubberViews is a runtime thing is it not? It only comes into play when the user of your app changes a window size? That’s not what I am asking for here, sorry if that wasn’t clear.

I’m talking about the Xojo window / layout editor. I want a way of adjusting my window size (in the Window editor) without controls changing size / location based on their LockBottom and LockRight settings. I want to do that without having to:

  • Find all controls that have LockBottom, LockRight set and turning them off
  • Change the window size
  • Change all the LockBottom, LockRight settings and putting them back.

I’m only concerned with the Xojo window editor, not how the runtime operates.

what you need is somehow a ignore Locks(Left,Top,Right,Bottom), some toggle icon in the ide toolbar,
and for the toolbar button you can assign any key if you want.

1 Like

There is already a Lock Controls button in the Window editor toolbar, however, it doesn’t prevent changes in window height from affecting the controls. It only prevents you accidentally moving controls using the mouse / trackpad. If it also prevented the Lock(B/R) from working then I would be happy.

1 Like

that was discussed a lot this days what the meaning of this lock should mean.

Disclaimer: I did not open or look at the sample project, so this is based on my interpretation of what you are saying.

If I follow they request right, you should consider moving the three “panels” into “container controls”. In each container control you lock embedded controls however you want to edges of that container object. And in doing so, you can make a listbox locked to both bottom and top so that it’s height varies with the height of the container.

Now back in Window 1, remove all the controls that are now in the container controls, and drag your container controls to Window 1 and lock the container control edges how you like. If container controls 2 & 3 should remain static in height, just lock them to the bottom of Window 1 but allow container 1 to lock to top and bottom.

Viola!

As you change the height of the window, the top “panel” aka container changes size, and be virtue of it changing size, so does the listbox.

Containers 2 & 3 just move down to follow the bottom edge of Window 1.

Container controls are a little like invisible nested windows, but give you another layer of ability to lock edges of a related set of controls independently from other sets of controls.

It is not the flexibility of iOS style constraints, but then it is not near as complex of interactions either…

Please don’t make it about the layout of the example window, it’s just that an example.

The point is there are times when you want to redesign a window control layout and when you do you need to adjust the height or width of the window. When this happens you can come up against the issue described and you will need a way of making the window larger or smaller without disturbing the control locations, while not destroying you work is setting the LockBottom / LockRight settings.

Amazing how many people just answer without even understanding the question :roll_eyes: Maybe they saw lot of text and just answered to the title.

Anyway, I have being in that spot, and YES, this would be a great option to speed up changing the UI when having control sizes locked to thair parent sizes AT DESIGN TIME on the IDE

*You sould edit the title and add an abstract at the start of the post to avoid users not reading it. Same goes to the Feature request case.

Can’t see a way of changing the title. Will check again when back on desktop. My initial paragraph was an attempt at a summary. Will update later

Nope I just can’t edit the title. In hindsight it’s a very bad title.