OrcaSlicer icon indicating copy to clipboard operation
OrcaSlicer copied to clipboard

OrcaSlicer locks previewed G-code file which prevents editing and reloading the preview

Open ansonl opened this issue 1 year ago • 3 comments

Is there an existing issue for this problem?

  • [X] I have searched the existing issues

OrcaSlicer Version

2.2.0

Operating System (OS)

Windows

OS Version

Windows 11

Additional system information

No response

Printer

Any printer

How to reproduce

  1. Drag a G-code file into OrcaSlicer to preview it.
  2. Try to edit and save the G-code file in another program.

Actual results

Permission denied to edit the file in the other program because it is locked from editing and deletion by OrcaSlicer.

Expected results

The file should be editable and deletable just like the PrusaSlicer Gcode preview.

When PrusaSlicer detects that the underlying file has changed, it no longer shows the line-by-line preview but still lets you browse the rendered preview layer by layer. The entire file can be reloaded from disk when triggered by the user with F5. The user will only be editing the G-code if they know what G-code is and what they are doing so the current locking behavior is not a safety feature. This is very useful for debugging G-code by hand or through another program. It shortens the change and re-previewing cycle immensely.

Project file & Debug log uploads

export-gcode.zip

Checklist of files to include

  • [X] Log file
  • [X] Project file

Anything else?

No response

ansonl avatar Nov 13 '24 23:11 ansonl

I would not consider this a bug, but rather a feature request. It is normal computer behavior to prevent you from editing/deleting a file while it is currently in use by a program. The fact that PrusaSlicer somehow allows otherwise is VERY uncommon.

MxBrnr avatar Nov 14 '24 04:11 MxBrnr

I'd argue that if a program has a file open for viewing only (e.g. an image viewer, or a text editor like Notepad++ before any changes are made) then it shouldn't lock the file - once it has read it in it should be using it's local cached copy only, with a potential manual reload available if desired. That's the case here.

I'd agree it falls short of a bug, it's more a choice between two behaviours - but I can certainly see a reason not to block background changes/regeneration of the gcode file while Orca has it open for preview, and that behaviour isn't so unusual.

yoyo42 avatar Dec 30 '24 11:12 yoyo42

Orca bot: this issue is stale because it has been open for 90 days with no activity.

github-actions[bot] avatar Mar 31 '25 00:03 github-actions[bot]

Orca bot: This issue was closed because it has been inactive for 7 days since being marked as stale.

github-actions[bot] avatar Apr 08 '25 00:04 github-actions[bot]