Ok – sorry for yet another stupid question:
I am trying to make a very, very simple stupid app.
2 buttons and 2 textfields on a form. I want them to
re-size if someone grabs the corner of the form to
fit the area of the form.
I “lock” all 4 corners of all of the controls thinking
that would make them re-size properly. Silly me.
When I do that nd run the code the controls are all
in strange places, and then if I try to make the form
smaller, at some point the code just locks up like its
1994 all over again.
What am I missing here?
What is the easy way to do this? I bought RubberViews,
but it doesn’t work right either. (tab panel will not scale
second to last page properly on RPI linux - but thats
a whole other problem)
What do I have to do to get SOME sort of error message
from this damn language – as opposed to just a hard lock
up? of the app?
Sorry for the frustration – but it is just killing me that
this is the “state of the art” in 2019. Feel free to flame me
for that statement. I feel like an animal that has been
ripped from its home and put in to a kennel.
The lockup is a bug with resizing a TextArea to smaller than 1x1 on macOS. I saw it ages ago when I was making an app. As I recall, the only thing that really can be done is prevent the user from making the TextArea that small.
As for locking, you probably only want to lock the top, left, and right of these text areas - leaving the bottom unlocked. I would recommend playing with all of the locking options, it’s the best way to learn how they work.
You can control the minimum size of the window as well so that users cannot shrink it so small it destroys the layout. I usually design the window at it’s smallest size, and set the locks so the interface expands appropriately.
I must be having some other sort of problems.
I have two controls, side by side. If I lock all 4 corners,
the second control is straight-up not there. It dissapears
This is true on RPI as well as linux.
Locking all four corners tells the window to resize those controls in every direction. Your control is being covered up by the other control. It’s easiest to design a window when only one control on the window has all four sides locked.
If you play with any other configuration of locking you might begin to see how the locking mechanisms work.
So how do the “real” programmers do this?
Are they writing code in the re-size event that dose this
with algebra for all of the windows? Please tell me there
is a much better way, and that I just missed it?
I remember in VB under VS 2018 there were “springs”
that you could insert between objects on the screen, but
that had itsown problems too…
Well, 18 years of using Xojo says that most of my resizing issues can be solved with the control Lock properties. For those times where I need something more complex I will use the Window.Resized and Window.Resizing events and doing the math can solve the rest.
I know that some people have used RubberViews and similar solutions. I have not had the need and I can’t tell you how many client apps we’ve made in all those years. So take that for what it’s worth.
Xojo has said that some time in the far future we’ll have AutoLayout for web and desktop apps similar to what we have in iOS right now. AutoLayout gives you much more power and flexibility on how things work but it’s also more complex to setup. But until then the Lock properties and doing the math are what I use.
but HOPEFULLY, it will be an option and not mandatory like it seems to be for “Xojo for iOS”. Even Apple allows the developer the choice of what layout features to use or not
OK, so what am I missing then?
I want a foldertab with 2 text boxes int he first tab that scale to fit
the size of window1, as window 1 is re-sized?
How do I do that with just the padlocks?
if you place two text boxes side by side and lock all 4 edges… those will resize and not overlap.
basically if each took up 50% of the width of the window (just for discussion)… then if you resize it will still take up 50%
never mind… see below
[quote=446572:@Dave S]if you place two text boxes side by side and lock all 4 edges… those will resize and not overlap.
basically if each took up 50% of the width of the window (just for discussion)… then if you resize it will still take up 50%[/quote]
Dave, you are completely wrong. If you lock all four edges of both text boxes they will overlap each other.
This image shows how the overlap occurs. There are four TextFields and four TextAreas, all of which have all four edges locked. The transparency of Dark Mode really helps point it out, but I’ve also selected a text field so the focus ring can highlight the overlap as well.
To get a 50 / 50 split to evenly occur, you must implement your own size and positioning with the Resizing and Resized events.
you are right… if you lock any one side… .it will maintain the original distance from that side…
I just do the math. My base window class has the code in its Resizing and Resized events. Every window in every project inherits from that base class. Solve it once and forget it.