SegmentedControl height

It seems like setting SegmentedControl.height does not work as expected. It won’t grow past 18. Any numbers higher, and the control’s height doesn’t increase, it just moves lower on the screen. This height value only affects the control programmatically, too, btw.
It has resize handles and you can type in a height value in the designer, but they don’t resize the control at all!

The height of the segmented control is defined by the operating system.

Thank you for your reply!

Ok, then why is there a height setting, and why can you use it to shrink the control but not grow it?

[quote=452054:@Andy Broughton]It seems like setting SegmentedControl.height does not work as expected. It won’t grow past 18. Any numbers higher, and the control’s height doesn’t increase, it just moves lower on the screen. This height value only affects the control programmatically, too, btw.
It has resize handles and you can type in a height value in the designer, but they don’t resize the control at all![/quote]
What system/version are you on, Andy? I’m not seeing the problem on 2019r1.1 on Windows 10. I can set the SegmentedControl to any size in the IDE and resize the control either in the IDE or in code and am not limited to a height of 18.

The segmented control on macOS is a system provided one and has less customizability
On Windows & Linux (I believe its both) its a custom control Xojo created as neither OS UI SDK provided one so it has more customizability

Yes, I’m looking at it on MacOS.
Thanks, Norman. What an odd choice for software that has as it’s entire reason for being (IMHO) as cross-platform that they would have a control that works differently across OSes. Slowly picking up on Xojo’s quirkiness…

This isnt Xojo’s quirkiness
This is macOS and the native control having these quirks
Xojo just uses that
Xojo could write a custom version for use x-platform but then you’re not using the actual real OS control which has other issues (like you being able to use OS level declares to alter it in expected ways)
The listbox is like this
While highly customizable since it is not a native control there are things that only Xojo can fix or add because its not an actual OS level native control so you cannot use declares to alter its appareance or behaviour like you can with buttons, windows, and so many other controls that are based on the OS UI SDK controls

Well, it kinda is. I think it would make more sense that if you’re going to add an OS’s native control to an OS that doesn’t have one, you would make it the same. If you want to have a control that works differently, as in the Listbox, create a custom that is custom everywhere.
It’s not a real problem the way they’ve done it, except that the designer doesn’t match the control’s capabilities in the OS you’re designing in. I call it quirky because it’s sloppy and unexpected. Obviously if you have years of Xojo experience, you already “know” these things. I’m figuring it out as I go along.

@Andy Broughton — When working cross-platform, you often have to rely only on the lowest common denominator between platforms.

Totally. Why Xojo isn’t following that rule in their designer is a mystery…

@Andy Broughton — Well I think they do, but by keeping a native SegmentControl on macOS, they also allow us to use all the native system calls to use text, images, add menus, select a segment, change its shape, enable/disable it, set a tooltip…

that is not 100% correct. there are some controls (especially in iOS) where Xojo decided to constrain the developer and not expose or limit the functionality of some attributes… And for iOS there is no “lowest common denomiator” between platforms

[quote=452112:@Andy Broughton]Well, it kinda is. I think it would make more sense that if you’re going to add an OS’s native control to an OS that doesn’t have one, you would make it the same. If you want to have a control that works differently, as in the Listbox, create a custom that is custom everywhere.
It’s not a real problem the way they’ve done it, except that the designer doesn’t match the control’s capabilities in the OS you’re designing in.
[/quote]
Sure but I might be designing on macOS to build & run on WIndows
The IDE doesnt know that when you’re designing things

They mostly have
Where a control doesnt actually exist or behave like they want they created a custom one
The toolbar on Windows is nothing like the one in the IDE - thats a completely custom one created for the IDE so it looks and behaves similarly x-platform
There are many controls that are custom ones just for the IDE
Xojo gives you that ability

But in the IDE its actually drawing using the OS where it can and, in this case, when you are on macOS the segmented control does what you note. but run your app on windows & it will behave

Well, the only reason I would ever use Xojo is because I can create a cross-platform app in one step. In the IDE, when I check off the OS’s I’m designing for, the IDE should react appropriately, limiting me to designing for the lowest common denominator. If I click ONLY “Windows”, then a custom control for that OS can do anything Xojo wants it to do, but cross-platform it should do it’s best to look the same. (except of course for things like menus and window icons which would be weird if they looked the same)
As I say, it’s unexpected and a learning process, but I’ll figure it out.

Appreciate all the help from these forums!

[quote=452125:@Andy Broughton]Well, the only reason I would ever use Xojo is because I can create a cross-platform app in one step. In the IDE, when I check off the OS’s I’m designing for, the IDE should react appropriately, limiting me to designing for the lowest common denominator. If I click ONLY “Windows”, then a custom control for that OS can do anything Xojo wants it to do, but cross-platform it should do it’s best to look the same. (except of course for things like menus and window icons which would be weird if they looked the same)
As I say, it’s unexpected and a learning process, but I’ll figure it out.
Appreciate all the help from these forums![/quote]

Those check boxes arent an indicator of what platform your designing for though
They are an indicator of what you are compiling for
Thats a VERY significant difference

Its fairly easy to have multiple windows that are designed for different OSes and then only the correct one is used depending on platform you compile for
Having the IDE designer limit what you can design for based on what OS you are on would be really limiting

There are only a handful of spots where the IDE does that - OLE controls for instance since there is not way to support them on a non-Windows OS (you actually need to be able to select & instantiate one to use it on a layout etc)

@Andy Broughton — I am sure Xojo could do that… if they charged 3000$ per license. I understand your point of view but I am happy that Xojo has chosen something in between.

I’m happy they use mostly native controls so I can extend & enhance the controls with native OS API’s

Me too!
I think you get though that that wasn’t my point.

Sure
I suppose Xojo could have made the segmented control more consistent x-plat since they did implement the Windows & Linux ones as custom controls. They could have restricted the sizing there like it is on macOS so its more consistent.
File a feature request for that I guess ?