Files
OrcaSlicer/src/slic3r/GUI
Tommaso BianchiandClaude Opus 5 33275f2c74 Design tab: sheet pickers targeted the wrong body; guard Delete Face's face list
The sheet-only pickers filtered correctly and then threw the filtering away. Their
rows are the SHEET bodies, but GetSelection() was passed straight through as an
index into m_doc.bodies. With a solid at 0 and a sheet at 1 — the normal order,
since you extrude a solid before making a surface — the single row is row 0 but
body 1, so Surface Offset and Thicken Surface targeted the SOLID. The kernel then
refused with "target is not a sheet", which reads as a kernel bug rather than a
picker bug, and the row's own label ("Body 2") disagreed with what was targeted.
Four sites per tool were wrong, including the re-edit path, which compared a body
index against the sheet-only row count and so restored the wrong row.

populate_sheet_body_choices() now carries the real body index in client data, and
two helpers make the row/body distinction hard to get wrong again:
sheet_choice_body() reads it back, select_sheet_choice() finds the row holding a
given body. No caller touches GetSelection()/SetSelection() on these pickers.

This is the third instance of the same index-space confusion in this file, after
the 0-based body labels in the interference report and the Rib sketch picker. The
kernel suite cannot catch any of them: the kernel receives whatever index the GUI
computed, and its own tests pass correct ones.

Delete Face was structurally right — its picker uses the all-bodies populate, so
its indices genuinely match, and accumulation appends with a running list. Two
gaps closed: clicking "Add picked face" with nothing picked was a silent no-op,
indistinguishable from a broken button, and the same face could be added twice,
putting a duplicate id into delete_faces that the defeaturing has no reason to
cope with. Re-adding is now a no-op with a message, not an error.

Both confirmed working on hardware. Kernel untouched: 139 cases / 1960 assertions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-25 23:46:14 +02:00
..
2026-06-18 09:13:51 -03:00
2025-10-05 16:02:17 +08:00
2026-04-20 19:27:38 -03:00
2026-01-03 23:06:57 +08:00
2026-07-11 20:24:03 +03:00
2025-07-06 11:34:47 +08:00
2026-06-07 13:12:51 +08:00
2026-06-18 09:13:51 -03:00
2026-07-18 03:15:11 +08:00
2026-07-14 13:10:42 +08:00
2026-07-20 18:14:01 -03:00
2026-06-18 09:13:51 -03:00
2025-08-22 20:02:26 +08:00
2026-07-02 17:49:36 +08:00
2025-09-21 13:47:51 +08:00
2025-10-02 09:30:48 +08:00
2026-07-24 09:41:24 -03:00
2026-06-18 09:13:51 -03:00
2026-07-25 12:15:30 +02:00
2025-10-02 09:30:48 +08:00
2025-10-28 15:29:56 +08:00
2026-07-17 08:30:22 +08:00
2025-10-28 15:29:56 +08:00
2025-09-21 23:01:08 +08:00
2026-04-25 18:14:51 +08:00
2026-04-25 18:14:51 +08:00
2026-07-02 17:49:36 +08:00
2026-07-02 17:49:36 +08:00
2026-04-25 18:14:51 +08:00
2026-01-23 17:05:56 +08:00
2026-07-02 17:49:36 +08:00
2026-07-02 17:49:36 +08:00
2026-07-02 17:49:36 +08:00
2024-07-23 18:00:21 +08:00
2026-05-21 09:04:26 +08:00
2026-06-18 09:13:51 -03:00
2026-01-03 23:06:57 +08:00
2026-01-23 17:05:56 +08:00
2026-01-03 23:06:57 +08:00
2026-07-24 09:41:24 -03:00
2026-02-04 11:40:02 +00:00
2026-01-23 17:05:56 +08:00
2026-01-23 17:05:56 +08:00
2026-07-02 17:49:36 +08:00
2026-07-02 17:49:36 +08:00
2025-10-28 15:30:06 +08:00
2025-10-28 15:29:56 +08:00
2026-04-25 18:14:51 +08:00