If all you need is a log in window, you could use a floating window, and maximize it.
It will cover the entire screen and prevent any access to other parts of the program.
Hi Jack! No, unfortunately this did not solve my problem permanently. When our whole team was using the software on different systems (Apple Silicon Mac’s and Intel Mac’s) crashes started to occur again. I tried forcing the build to Intel only and running it through Rosetta on the Silicon Mac’s, but no luck there either. I’m also experiencing crashes on the Printing windows sometimes, it’s still not working optimal.
I solved my problems with the Search windows by programming around the ShowModal command entirely. It took some fiddling in which the search window puts the found value in a global variable and a repeating timer on the original windows to read that variable. It results in some lag sometimes but it does the trick without the need for a Showmodal command, since I can now use Show and the window closes itself as soon as it puts the found value in the global variable. It’s been a rocky road to get everything smoothed out 
This is for the category „Programming Humor“.
I was getting crash reports involving modal dialogs starting with Monetary 12.1, and recently as last week on 12.4, and I discovered the exact culprit and good workaround and reported it via Issues with a demo app (Issue 68800).
https://tracker.xojo.com/xojoinc/xojo/-/issues/68800
Note the crashes affect both Intel and ARM. Not limited to Apple Silicon as this thread title suggests!
I’ve pinned it down to the precise thing that triggers the issue. It’s very strange…
The crash requires a VERY specific set of items to be true:
- macOS Monterey 12.x
- A modal dialog (of any type, Sheet/Movable/etc.) must be shown.
- The Menu Bar must be hidden, either on Desktop (via optional setting in System Prefs > Dock & Menu Bar) or via Full Screen mode where the Menu is hidden by default.
- Crash occurs when switching apps while the modal dialog is visible.
If you are viewing Full Screen, the crash happens when switching away. If you have the Menu hidden on Desktop, the crash happens when switching back to the app. - And one last very important key ingredient…
Simply calling a method in the dialog window that both shows the modal dialog and returns a STRING causes the crash! That’s it. 
If the “show the dialog” method returns anything besides a String, it works perfectly fine–Variant, Text, Integer, Boolean, and Objects. Of course using no return type also works fine. Why in the world would just a String return type trigger a crash but nothing else? How does that logically tie into the Menu Bar being visible or not? 
An obvious workaround is as simple as switching the method’s return type to Variant or Text!
I’ve uploaded a demo app to my Issues report (68800) that clearly demonstrates the issue, and the workarounds.
4 Likes
OMG! That is EXACTLY what happened with my app! I DID have the menu bar hidden on my development Mac and I was using a string to return the data…
Very good of you to figure all this out! I might return my app to the old way of working, since my current code is too complex, unreliable and sometimes laggy.
Thanks!
Glad I could help! Hopefully you saw the simple workaround of switching the modal dialog’s return type from String to Variant or Text!
KISS principle
2 Likes
I indeed had a function with ShowModal followed by return string. A quick and dirty fix was to convert the function to a subroutine storing the string value in a global location. My app is no longer crashing! Surely Apple can take the problems you’ve isolated it and fix their OS so some of us can undo our quick and dirty! Thanks, Jason!
No need to use a global property or change the Function to a Sub. What I was demoing is simply changing the function’s return type to Variant (or Text) will prevent the crash, and thus will auto-convert back to String on the receiving end, meaning no other refactoring is needed. So it’s even an easier workaround.
1 Like
Thanks, I’ll try that
My app also is affected. Super weird bug. I’m impressed at the use of emojis for window and method names in the example.
1 Like
Sometimes I feel my software would work better without an operating system.
3 Likes
This is for the category „Programming Humor“.
3 Likes