Here is the response to my original post (questions) from ChatGPT 5.2 Thinking:
What you’re describing is very consistent with a native-side crash caused by “camera updates happening while a big edit transaction is actively mutating lots of entities”—and it can absolutely present as pure BugSplat with no Ruby Console output. Ruby exceptions won’t catch this because the process is dying in SketchUp’s C++/render/driver/input stack, not in Ruby.
There are two overlapping risk factors in your report:
- Large, bursty geometry mutation (regen/redraw of an assembly with lots of groups/instances).
- Concurrent navigation input (mouse orbit/pan, and especially continuous 3Dconnexion camera input) during that mutation.
SketchUp is single-threaded, but that doesn’t prevent re-entrancy / timing-sensitive interactions between the UI/render loop and model changes—particularly when a device is continuously pushing camera transforms.
What to do in your code (highest leverage)
1) Wrap the entire regen in one operation with UI disabled
Make sure the regen is inside a single start_operation(..., true, ...) so SketchUp doesn’t redraw incrementally while entities are being created/erased/exploded.
The Ruby API explicitly supports this via disable_ui in Sketchup::Model#start_operation. (SketchUp Ruby API Documentation)
Pattern:
def with_undo(op_name, disable_ui: true)
model = Sketchup.active_model
model.start_operation(op_name, disable_ui, false, false) # disable_ui = true
yield
model.commit_operation
rescue => e
model.abort_operation
raise
ensure
# If you disable UI updates, some inspectors may need a refresh:
UI.refresh_inspectors
end
UI.refresh_inspectors is specifically noted as useful when UI updates were disabled. (SketchUp Ruby API Documentation)
Why this helps: it reduces the amount of “half-built geometry” that the renderer and selection/outliner/etc. might touch mid-flight.
2) Actively prevent navigation tools while regen is running
Dan Rathbun’s suggestion in the very thread you posted is solid: push a “wait tool” and/or attach a ToolsObserver that immediately pops Orbit/Pan/Zoom tools while you regenerate. (SketchUp Community)
Tool IDs for camera tools are listed in the ToolsObserver docs (Orbit 10508, Pan 10525, Zoom 10509, etc.). (SketchUp Ruby API Documentation)
Simple approach: attach a temporary ToolsObserver
class MedeekNoNavObserver < Sketchup::ToolsObserver
NAV_TOOL_IDS = [10508, 10525, 10509, 10526, 10523].freeze # orbit, pan, zoom, zoom window, dolly
def onActiveToolChanged(tools, tool_name, tool_id)
if NAV_TOOL_IDS.include?(tool_id)
tools.pop_tool
end
end
end
Then during regen:
model.tools.add_observer(obs)- run regen
model.tools.remove_observer(obs)
Caveat: 3Dconnexion navigation might not always show up as those camera tools (depending on how the 3Dx integration feeds camera changes), so this is not a guaranteed catch-all—but it does stop the classic mouse pan/orbit/zoom pathway, which you’ve already identified as a trigger.
More robust: push a “wait tool” that absorbs mouse/key events and makes it obvious the user should pause. That also matches your own “pause briefly” workaround, but enforced.
3) Avoid “regen while still inside a dialog callback” re-entrancy
If your Submit button is coming from an HtmlDialog callback, consider scheduling the heavy regen to run on the next tick:
UI.start_timer(0, false) { do_regen_now() }
This can reduce re-entrancy where UI is still unwinding from the click event while you begin destructive edits.
(You still want start_operation(..., true) and no-navigation during the actual regen.)
What’s not a Ruby “mistake,” but still worth tightening
- Explode + erase + add_instance in a tight window is inherently stressful for SketchUp (lots of entity invalidation). That doesn’t mean your approach is wrong—parametric regen often requires it—but it’s exactly the kind of workload where “don’t let the camera move right now” matters most.
- If you’re calling
view.refresh repeatedly inside rebuild loops, try to remove that and refresh only once after commit. (Frequent refreshes increase the chance of intersecting camera redraw with half-mutated state.)
Why Windows 7 (and even older SketchUp) makes this worse
Windows 7 is long outside current support/testing, and SketchUp explicitly notes older Windows versions are unsupported, and that behavior may be untested. (help.sketchupaustralia.com.au)
So your “old machine Win7 SU2017–2020” crashes are very plausibly an environment/driver/render-stack fragility that your workflow triggers more easily.
What to ask your affected user to do (practical triage)
- Update 3Dconnexion drivers / try a different driver version if the crashes correlate strongly with the SpaceMouse (there are multiple reports of SketchUp instability tied to 3Dconnexion components). (SketchUp Community)
- Have them submit BugSplats with a clear comment like: “Medeek Wall – regen after Submit while SpaceMouse moving camera” (SketchUp can correlate crash signatures if the report text is consistent).
Bottom line
This is very likely an inherent stability edge-case in SketchUp’s native side that’s being triggered by “navigation input during heavy model mutation.” You can’t fully “fix” that from Ruby, but you can dramatically reduce the trigger surface by:
- One operation, UI disabled during regen (
start_operation(..., true, ...)) (SketchUp Ruby API Documentation)
- Temporarily block navigation (wait tool + ToolsObserver) (SketchUp Community)
- Kick regen to next UI tick if initiated from a dialog callback
If you want, paste your regen wrapper method (the one that calls your create_*_assembly / edit path) and I’ll point out exactly where to place the “disable_ui + no-nav window” with minimal changes.