ShowModalWithin on macOS - now centered, used to drop down from the top

General
21

You could also create a class to hold all the information required. Store an instance in a property and then the buttons can access that. It could be easier than doing lots of extra properties. The action event methods can go in the class also.

22

Thanks, that’s a good idea. Making a class as a workaround isn’t my favourite thing to do, but it may be what should happen to keep things clean.

23

Are you sure? I have a xojo app and on Ventura and Sonoma, modal dialogs that are shown using ShowModalWithin() are showing up centered on the parent window. They look different than before in terms of style, but they are definitely centered and modal to a single window.

24

The problem is with the centred over the window they are placed on. The Op wanted it at the top, as before.

25

I don’t know why you think you can’t do it that way but here’s a function:

Public Function ShowMesssageDialog(parent as DesktopWindow, message as string, defaultbutton as string, cancelbutton as string) As String
  dim md as new MessageDialog
  md.ActionButton.Caption = defaultbutton
  md.CancelButton.Caption = cancelbutton
  md.CancelButton.Visible = (cancelbutton<>"")
  
  md.Message = message
  
  dim mdb as MessageDialogButton = md.ShowModal(parent)
  
  return mdb.Caption
End Function

it would be used like this, assuming it was run from within a control on a window:

if ShowMessageDialog(self, "Confirm or Reject", "Confirm", "Reject") = "Confirm" then
// here’s more code after confirming
else
// reject code
end if

if you’re using a Window object, you’ll want to duplicate the method and change the first parameter’s type to Window.

26

Ahh, the OP wrote “they appear in the center of the screen” perhaps they meant “center of the window”? That would be different.

1 Like
27

Sorry, yes I meant the center of the window. I’m normally working with the window maximised, so mixed up the language a little there.

28

That still shows in the centre of the parent window, not at the top as before.

29

Perhaps the window was maximised.

30

I just did a quick test where I try to override the Window.Top position to 0 of a Sheet window, both before and after calling ShowWindowWithin() and it appears to have no effect in Ventura and Sonoma - the sheet window is still centered vertically on the parent window. You can change the Width and Height of the sheet, but it appears that the .Top value is ignored.

31

Right. It’s the same on Monterey. Apple changed it apparently to make the user experience the same as iOS.

32

Yes. And this is a source of extreme irritation, since the iOS device I have sits on the desk by itself all day, and if I go out, sits in my pocket all day.

33

Is that real code? If so, I would recommend making the dialog much more verbose, e.g.:

Are you sure you want to Delete the frazzle biz bug? You will be deleting the biz bug that has foo bar razzles. Once deleted, the naxblogs that belong to the razzles will also be deleted. This action is not Undoable. [Delete] [Cancel] "

Remember, the user could be using your app on a small window, in which case the Sheet would occlude the content anyway. This way, the user should not need to see what’s underneath the dialog.

(Though of course this does depend on just what your app does, not all apps are the same)

34

No. (I wrote above it: “In pseudocode:”)

1 Like
35

You’re fighting an uphill battle if you want control over the location of a sheet. Apple changed the location and appearance of modal sheets and your app needs to adapt to the change if your app is going to look native in the newer OSs.

2 Likes
36

You’re absolutely right - a sheet window is no longer the answer here due to the changes Apple insists on making to macOS. But if not sheets, than what? I’ve been thinking about this problem ever since I read the original post, and outside of a self-contained modal dialog, I can’t think of a standard approach to this.

Sam’s suggestion of a popover is excellent, if non-standard, but I hesitate a little to make a popover modal. Most popovers I deal with self-close if you click away from them. I don’t think that’s the right solution here, as the user is required to make a decision to continue. They’re generally informative, or present extra options not needed for the primary function of whatever is in play.

Popovers also don’t ever seem to contain default buttons, activated by the Return and Escape keys, like modal dialogs can, and this can be tiring to the user who now must mouse over to the popover to deal with it.

37

In case anoyone else is suffering over this – one thing I’ve done is to take a hint from the LR and change any windows I had set to type Sheet to type MovableModal instead. This changes the aesthetic of the Mac app, but at least then the behaviour will be basically the same x-platform.

### Understanding sheet windows

A *Sheet Window* is the official name for a type of macOS window that is modal to a parent window. On other platforms, they behave as an ordinary movable modal dialog box.

The above text is from the DesktopWindow. For many reasons I still use the old Window class. The text in the LR is a little different there, describing the old behaviour of sheets, which doesn’t apply any more.

Obviously, this doesn’t fix the problem for Xojo’s MessageDialog class, which has no option to make it movable. Seems like a reasonable feature request. I tried navigating the (new for me) Xojo issue tracker and didn’t see a way to submit a feature request, but I saw a request to use native dialogs for the class, which should also (sort of) solve the problem, since Apple does provide an option for their NSAlert windows to be movable.

38

So the function you need to override is below. It’s part of the NSWindowDelegate. Xojo already creates a NSWindowDelegate, called “XOJWindowController” and due to the dynamic nature of Objective-C, you can “Swizzle” the function pointers to steal that function from Xojo (or in this case, handle that function yourself).

The code below includes the function description, which is needed for this kind of hacking as we can’t just create a XojWindowController subclass and override it like normal people.

call class_replaceMethod( delegateClass, NSSelectorFromString( "window:willPositionSheet:usingRect:" ), _
addressOf windowwillPositionSheetUsingRect, "{NSRect}@:@{NSRect}" )

I’ll leave the rest up to you folk to figure out.

Oh and don’t forget that Xojo’s co-ordinate system is the vertical opposite of Apple’s, so Zero is the bottom of the window and not the top.

1 Like