Preparing your Xojo made Mac app for Big Sur

Just posted part 2 of what was originally only going to be a 3 part series, but now I have enough content for a while!

Part 2 - Sidebars and source lists.
https://ohanaware.com/blog/202030/Preparing-your-Xojo-made-Mac-App-for-macOS-Big-Sur-part-2.html

2 Likes

Thank you for posting this Sam!

1 Like

Can I make a toolbar like in Mail with your code?

Where the toolbar is not all over the window but to the right.

Currently, you can’t (with my code).

I have over-viewed what’s required to make the Apple Toolbar operate like this. It requires quite a bit of work on my behalf as I need to introduce new controls into Xojo, and it will require quite a bit of work on your behlaf as you’ll need to redesign your interface to use specific controls, and hook up certain things in a certain way, hack the SDK and sacrifice a lamb.

Then it might work, but I have to warn you, you’ll be fighting Xojo’s control hierarchy (which as someone who’s done that for years), may work 90% of the time, but it will introduce complications and potential crashes.

There was one API that I could have taken advantage of to make this whole thing a lot simpler, but they deprecated it and removed it from Big Sur :frowning:

I haven’t quite given up, and I am still experimenting with other options.

I’d prefer not to sacrifice a lamb. Messing with the control hierarchy isn’t a good idea.

Whatever Xojo is doing with toolbars it’s majorly messed up windows in BS. Am I the only one who has windows with toolbars and is doing window positioning with .top instead of .bounds.top?

No, your not! Hoping to find an easy solution.

Agreed, it often leads to pain, pain leads to anger and we all know where anger takes us…

So far I found that using the bounds instead of top and height works. I’m not sure if the bugs are a Xojo problem or a BS one. Not even Xojo shows the behaviour I see in my app, where the windows moved up on reopening. Can you reproduce this behaviour:

feedback://showreport?report_id=61129

My bad, I thought you meant about the window changing position when clicking on a toolbar item. I have no idea why I thought that.

I am already using bounds for window positioning, or using the Apple supplied API for pallet windows.

If you’re using .top to position windows then you will have issues since that does not account for the height of the tool bar or title bar

Bounds is the window bounds (the outer enclosing frame rect) where .top, .left, .width and .height are the content area only
The red box in the image is what BOUNDS would return
And the green what you’d get from .top .left .width and .height

This is / was one of the reasons the IDE used to restore state with the title bar tuck up under the menu bar on macOS :stuck_out_tongue:

Sigh… and you don’t think I never noticed that before??? Like ever? Of course, I accounted for the difference. Unfortunately, this doesn’t work in BS at all.

And 61129 also affects Thom’s AnimationKit. Which has the funny effect of moving the window up each time the window is animated.

Here is the code from 61129 that makes the problem:

Self.Top = Self.Top - 100
Self.UpdateNow
Self.Top = Self.Top + 100

Try this in a window with a toolbar. And then tell my why the code doesn’t work anymore.