We've run into a conflict between the fix applied for issue #21459 and our application that has lead to some examination of that patch and we believe that it is not correct. Since the issue is closed I chose to start out discussion here. If desired I can enter a new issue.

We agree that OSX does not easily supply a method for doing non-modal over modal but we disagree that setting up the non-modal as a sheet on the modal is the correct response. Doing so allows the non-modal to remain active but it essentially makes the non-modal form a modal form (as it is attached to the modal form).

Similar behavior on VCL/Windows/Qt is that the non-modal form can be activated independent of the modal form (example: a floating toolbar). In the issue comments Jaco Voorham indicates that StayOnTop does not work because it doesn't allow the window to move backwards when it is not focused. The current fix does not allow that either. When the form drops down as a sheet on the modal form, nothing can be done with the modal form until the sheet goes away (because sheets are modal).

The wikipedia article pointed to in issue 21459 comments says that in OSX sheets are used to present some modal forms (not non-modal). They are modal dialogs that are modal to a specific window.

So it doesn't appear that the patch does what was really intended or matches OSX intent.

In addition it conflicts with the use of sheets that we already have in our app (which do match OSX intent). One affect we see is that if we open a sheet inside of a window (i.e. a dialog modal to a specific window), any other windows that we open now open themselves as sheets within the existing sheet. In other words when we open a compare window and then open a window specific modal dialog (sheet) inside that first compare window we cannot open a new compare window without it opening up as a sheet attached to the existing sheet. This should not be.

We'd be happy for the patch to be removed.

Regards
David Jenkins
scootersoftware

Then the applied fix needs to be reimplemented. The need to show a non-modal form on top of modal is needed even for LCL components - for TDateEdit and TCalcEdit as they use forms for dropping down editors. Similar needs exists in many other component sets.

I hope you will be able to change the carbon implementation yourself soon.

Best regards,
Paul Ishenin

Paul Ishenin wrote

Then the applied fix needs to be reimplemented. The need to show a non-modal form on top of modal is needed even for LCL components - for TDateEdit and TCalcEdit as they use forms for dropping down editors. Similar needs exists in many other component sets.

TDateEdit and TCalcEdit both worked correctly prior to the patch.

TDateEdit is shown non-modally, but its PopupMode is pmAuto, which parents it to the modal form. Since it's owned by the modal form it works correctly, but stays on top.

TCalcEdit just shows its form using ShowModal.

The original bug reporter was asking for the ability to show a non-modal form while a modal form is active, with the ability for the non-modal form to go into the background. As far as I can tell, Carbon doesn't support that because SetWindowModality works program-wide.

A possible solution would be to replace the calls to SetWindowModality in TCarbonWindow.ShowModal and CloseModal with a loop over all of the open forms to manually enable/disable them. I wouldn't recommend that as change to the official Lazarus distribution though, since it bypasses the OS-provided behavior and would probably have side effects. It wouldn't be hard to register a custom TCarbonWindow descendant in his application code to do that. Alternatively, he can just set PopupMode to pmAuto like TDataEdit and accept that the non-modal dialog will stay on top of the modal one.