You should also post this over on SketchUcation, which is where TIG provides most of his extensions and is more likely to see it.
Edit: On a Mac, when an app is aborted the OS offers to send a report to Apple. Much of the time an abort is triggered by a known but unrecoverable error in the OS, such as a fatal error in a graphics driver, and Apple wants to know about such. But a manual force quit also generates an abort and gets the same handling. I usually tell macOS not to bother reporting an abort I know happened because I chose force quit - Apple won’t learn anything of value from the report.
No Colin, I do not use Rosetta. macOS Ventura indicates that SU 2023 is a fully ‘universal’ applications. In that situation, Rosetta is not needed, is it?
The extension itself may be taking advantage of something pre M1 that isn’t there.
Or more likely , something had changed in a recent OS update that has caused the extension to not work
The common theme to these issues in multiple input points in a tool - e.g. when drawing a 3-point rectangle
The first two points are OK, but after that the beach-ball-of-death starts…
These tools work fine in other MAC OS versions and on all PCs, so something must be different with particular MAC OS !?
I don’t have a MAC with this OS/version to test with, so if anyone else wants to mess on with the coding, then feel free…
The RB files in the subfolder are not encrypted, so you can see what they are doing, and try your own edits etc…
I would like to get to the bottom of this, as I have another [confidential] commercial toolset that’s failing on these newer MACs, with input point issues that are very similar… On other MACs or PCs there’s no issues.
I reproduced the issue on macOS Ventura 13.3.1 on my Intel-based 2019 MBP 16" using both SketchUp 2023.0.396 and SketchUp 2022.1.165. So it is not specific to Apple Silicon nor to SketchUp 2023. I don’t have a pre-Ventura version of macOS running, so I can’t verify whether the issue also happens on Monterey or earlier.
After some testing, I found that the extension was looping in the draw (view) method after the second point is picked (in the @state > 1 clause.) I think the problem is that the code calls view.invalidate from within the draw method, triggering an immediate call again to draw - endless loop! I commented out the view.invalidate, and the problem went away.
I’m not clear why the view.invalidate was needed in the first place, even on Windows. @TIG, perhaps you can explain? If it is needed on Windows or older versions of macOS, a simple branch test based on OS version could fix it?
Edit: I posted this also on SketchUcation and TIG replied there. He is on the case!
Purely a guess, but I wonder if there is a difference in how events are queued on the two platforms, somewhat like how webdialogs were asynchronous on Mac but not on Windows.
I’ve had SketchUp running in Xcode all day, and been looking at this. I could see that it was getting stuck on the second draw_polyline, and I had noticed the invalidate line (and wondered about that).
Deleting that line does make the tool work.
Curious that it doesn’t affect older macOS, if that is the case.
