main
13
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
   
|
261d46adcf |
Selection like AutoCAD: colour highlight and the Options Selection tab (#808)
Selecting or hovering an object outlined each filled primitive (TrueType glyphs, dimension and leader arrowheads, solid hatches, wide polylines) by the rectangle around its triangles, and dashed everything else. A selected dimension's text became a row of dashed boxes, one per glyph, and its closed arrowheads small rectangles. Selected objects are now redrawn in the selection colour: lines solid, fills filled half see-through (so the lines and text on a highlighted hatch stay visible), and the whole object reads as selected, text and arrowheads included. A wipeout is always outlined, since filling it would hide the drawing under it. The Options dialog's Selection tab is laid out as AutoCAD's, with the settings CADCraft can act on, each one AutoCAD's variable, kept in the user profile: - Selection modes: noun/verb selection (PICKFIRST), Shift to add (PICKADD), Object grouping (PICKSTYLE bit 1, now saved in the profile). - Selection effect color (selectionColor, an interface preference; null is the theme's). - Grips: Show grips (GRIPS) and the object selection limit for display of grips (GRIPOBJLIMIT, 100; 0 no limit): grips are neither drawn nor picked beyond it. - Selection preview (SELECTIONPREVIEW): the object under the cursor is highlighted when a command is active (2) and when none is (1). - Visual Effect Settings: the selection area effect (SELECTIONAREA, WINDOWAREACOLOR 150, CROSSINGAREACOLOR 100, SELECTIONAREAOPACITY 25) and the Selection Preview Filter (PREVIEWFILTER 3: 1 objects on locked layers, 2 xrefs, 4 tables, 8 multiline text, 16 hatches, 32 groups). As in AutoCAD these are typed, not on the dialog: HIGHLIGHT (0 shows only the grips of selected objects; not saved, so every session starts highlighted), SELECTIONEFFECT (1 the selection colour, 0 dashed lines with fills outlined along their real boundary) and PREVIEWEFFECT (the preview dashed 0, thicker 1 or both 2). Left for later, as CADCraft lacks what they control: lasso, grip tips and menus, group grips, grips within blocks, associative hatch selection, command and property preview, PICKDRAG, PICKAUTO and PROPOBJLIMIT. DisplayList::fill_outlines returns the boundary of the region a filled primitive covers as closed polylines (edges only one triangle has; the slab filler's horizontal cuts, which need not line up between trapezoids, are split at every x on their line and kept where an odd number cover them), falling back to the bounding box over 600,000 vertices. The GPU and CPU highlight paths and the drawing comparison overlay share the same looks. The new labels have Ukrainian rows (the required catalog); other languages fall back to English. Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
d826450e03 |
Block Editor on the current drawing; a drawing with authoring elements offers it (stacked on #833) (#885)
* Block Editor: BEDIT, BSAVE, BSAVEAS and BCLOSE for static blocks BEDIT opens a block definition in the drawing's own tab with its base point at the origin, and the block's objects are edited with the ordinary commands. BSAVE writes them back into the definition, so every reference in the drawing updates (one undo step in the drawing); BSAVEAS saves under a new name; BCLOSE goes back to the drawing, asking whether to save unsaved changes. - The drawing waits untouched while the editor is open (blockedit.rs): its undo history, selection and views come back on BCLOSE. Objects left unchanged are saved back exactly, so no coordinate drifts. - Files save the drawing outside the editor; autosave keeps the editor's unsaved changes in the block; the close/quit prompt's Save puts them into the block first. - Right-click a selected block reference: Block Editor. In the editor the canvas is tinted, the base point is marked, and a bar offers Save Block, Save Block As and Close Block Editor (also in the right-click menu). The Block tool set's Block Editor button is now live. BLOCKEDITOR sysvar. - Layout and paper-space commands are refused while the editor is open; a block can't be saved to contain a reference to itself. - Dynamic blocks: their data is kept; the editor says it can't edit their parameters yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Edit Block Definition dialog; BEDIT can start a new block BEDIT typed or started from a menu or the Tool Sets with no block reference selected opens the Edit Block Definition dialog: the drawing's blocks sorted by name, a preview and the description. OK opens the Block Editor on the block named; a name no block has yet starts a new block, which BSAVE creates (`bedit {name, create: true}`). A selected block reference still opens at once, and JSON calls never open the dialog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Edit Block Definition: centred window, list box; gaps.md F3 The dialog opens centred on the window, the blocks are a full-width list in a list box of fixed height, and gaps.md F3 mentions the dialog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * BEDIT: find dynamic block data on the block's BLOCK_RECORD A dynamic block's ACAD_ENHANCEDBLOCK dictionary hangs off its BLOCK_RECORD table entry, not the BLOCK entity, so the "parameters are kept" note never showed for AutoCAD files. Regression test with the data laid out as an AutoCAD DXF has it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * BEDIT: a dynamic block reference opens its dynamic block A dynamic block reference with values of its own shows an anonymous block (`*U12`), so the right-click Block Editor (and BEDIT on a picked or selected reference) refused it and asked for a name. The anonymous block's record names its dynamic block in AcDbBlockRepBTag xdata; BEDIT now opens that, as AutoCAD does. Regression test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Block Editor on the current drawing; opening a drawing with authoring elements offers it A dynamic block's own drawing (model space with authoring elements: its block record's ACAD_ENHANCEDBLOCK) opened from the UI asks, as AutoCAD does, "<file> contains authoring elements. Open in Block Editor?" Yes / No / Cancel. Yes opens the Block Editor on <Current Drawing>: the drawing's own objects, edited where they are; BSAVE keeps them, BCLOSE without saving puts the drawing back. <Current Drawing> heads the Edit Block Definition list. BSAVEAS is not available there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
43972c82e8 |
Edit Block Definition dialog; BEDIT can start a new block (stacked on #824) (#833)
* Block Editor: BEDIT, BSAVE, BSAVEAS and BCLOSE for static blocks BEDIT opens a block definition in the drawing's own tab with its base point at the origin, and the block's objects are edited with the ordinary commands. BSAVE writes them back into the definition, so every reference in the drawing updates (one undo step in the drawing); BSAVEAS saves under a new name; BCLOSE goes back to the drawing, asking whether to save unsaved changes. - The drawing waits untouched while the editor is open (blockedit.rs): its undo history, selection and views come back on BCLOSE. Objects left unchanged are saved back exactly, so no coordinate drifts. - Files save the drawing outside the editor; autosave keeps the editor's unsaved changes in the block; the close/quit prompt's Save puts them into the block first. - Right-click a selected block reference: Block Editor. In the editor the canvas is tinted, the base point is marked, and a bar offers Save Block, Save Block As and Close Block Editor (also in the right-click menu). The Block tool set's Block Editor button is now live. BLOCKEDITOR sysvar. - Layout and paper-space commands are refused while the editor is open; a block can't be saved to contain a reference to itself. - Dynamic blocks: their data is kept; the editor says it can't edit their parameters yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Edit Block Definition dialog; BEDIT can start a new block BEDIT typed or started from a menu or the Tool Sets with no block reference selected opens the Edit Block Definition dialog: the drawing's blocks sorted by name, a preview and the description. OK opens the Block Editor on the block named; a name no block has yet starts a new block, which BSAVE creates (`bedit {name, create: true}`). A selected block reference still opens at once, and JSON calls never open the dialog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Edit Block Definition: centred window, list box; gaps.md F3 The dialog opens centred on the window, the blocks are a full-width list in a list box of fixed height, and gaps.md F3 mentions the dialog. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * BEDIT: find dynamic block data on the block's BLOCK_RECORD A dynamic block's ACAD_ENHANCEDBLOCK dictionary hangs off its BLOCK_RECORD table entry, not the BLOCK entity, so the "parameters are kept" note never showed for AutoCAD files. Regression test with the data laid out as an AutoCAD DXF has it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * BEDIT: a dynamic block reference opens its dynamic block A dynamic block reference with values of its own shows an anonymous block (`*U12`), so the right-click Block Editor (and BEDIT on a picked or selected reference) refused it and asked for a name. The anonymous block's record names its dynamic block in AcDbBlockRepBTag xdata; BEDIT now opens that, as AutoCAD does. Regression test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
767576ec9e |
Block Editor: BEDIT, BSAVE, BSAVEAS and BCLOSE for static blocks (#824)
* Block Editor: BEDIT, BSAVE, BSAVEAS and BCLOSE for static blocks BEDIT opens a block definition in the drawing's own tab with its base point at the origin, and the block's objects are edited with the ordinary commands. BSAVE writes them back into the definition, so every reference in the drawing updates (one undo step in the drawing); BSAVEAS saves under a new name; BCLOSE goes back to the drawing, asking whether to save unsaved changes. - The drawing waits untouched while the editor is open (blockedit.rs): its undo history, selection and views come back on BCLOSE. Objects left unchanged are saved back exactly, so no coordinate drifts. - Files save the drawing outside the editor; autosave keeps the editor's unsaved changes in the block; the close/quit prompt's Save puts them into the block first. - Right-click a selected block reference: Block Editor. In the editor the canvas is tinted, the base point is marked, and a bar offers Save Block, Save Block As and Close Block Editor (also in the right-click menu). The Block tool set's Block Editor button is now live. BLOCKEDITOR sysvar. - Layout and paper-space commands are refused while the editor is open; a block can't be saved to contain a reference to itself. - Dynamic blocks: their data is kept; the editor says it can't edit their parameters yet. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * BEDIT: find dynamic block data on the block's BLOCK_RECORD A dynamic block's ACAD_ENHANCEDBLOCK dictionary hangs off its BLOCK_RECORD table entry, not the BLOCK entity, so the "parameters are kept" note never showed for AutoCAD files. Regression test with the data laid out as an AutoCAD DXF has it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * BEDIT: a dynamic block reference opens its dynamic block A dynamic block reference with values of its own shows an anonymous block (`*U12`), so the right-click Block Editor (and BEDIT on a picked or selected reference) refused it and asked for a name. The anonymous block's record names its dynamic block in AcDbBlockRepBTag xdata; BEDIT now opens that, as AutoCAD does. Regression test. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
62fb5ae79a |
Attributes keep Verify, Preset and Lock position (stacked on #854) (#876)
* Multiline attributes: read, draw and save their text A multiline attribute (DXF attribute type 2, or 4 for a definition) has its text as embedded MTEXT after its own groups (`101 Embedded Object`); its own group 1 is empty. CADCraft read only the own groups, so the attribute drew nothing, and a save wrote it back empty: its text was lost. - `Attrib::multiline` keeps the multiline text; `text.value` holds its plain text, which ATTEDIT and the other value editors change; an edited value replaces the contents (`Attrib::multiline_text`). - DXF read: ATTRIB and ATTDEF split at the marker; the MTEXT parsing is shared with MTEXT entities (`mtext_from`). - Drawn as multiline text; ZOOM Extents counts it. - DXF write (2007 and later; earlier versions get one line): attribute type, alignment point and the embedded MTEXT, only what differs from unrotated text, as AutoCAD writes it. - INSERT and ATTSYNC give references the definition's multiline text placed with them; MOVE/ROTATE/SCALE, Properties rotation and scale, annotative scaling and FLATTEN carry it. - Tests: synthetic multiline ATTDEF and ATTRIB (read, drawn, saved, edited, pre-2007 save, damaged embedded groups); engine INSERT, MOVE, ATTEDIT and ATTSYNC. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Multiline attributes: read MTEXT direction from its own groups (#667, as #834 does) #834 moves these lines' fix into the MTEXT reader; the same fix in the shared mtext_from keeps the two compatible. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Attributes keep Verify, Preset and Lock position ATTDEF/ATTRIB flags 4 (verify) and 8 (preset) and Lock position (group 280 after the tag, DXF 2007 and later) were dropped on save. Without Lock position AutoCAD lets an attribute be dragged out of its reference, and its dynamic block actions no longer carry it. A reference's attributes take Lock position from their definitions, as AutoCAD saves them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
3199de4951 |
Multiline attributes: read, draw and save their text (they were lost on save) (#854)
* Multiline attributes: read, draw and save their text A multiline attribute (DXF attribute type 2, or 4 for a definition) has its text as embedded MTEXT after its own groups (`101 Embedded Object`); its own group 1 is empty. CADCraft read only the own groups, so the attribute drew nothing, and a save wrote it back empty: its text was lost. - `Attrib::multiline` keeps the multiline text; `text.value` holds its plain text, which ATTEDIT and the other value editors change; an edited value replaces the contents (`Attrib::multiline_text`). - DXF read: ATTRIB and ATTDEF split at the marker; the MTEXT parsing is shared with MTEXT entities (`mtext_from`). - Drawn as multiline text; ZOOM Extents counts it. - DXF write (2007 and later; earlier versions get one line): attribute type, alignment point and the embedded MTEXT, only what differs from unrotated text, as AutoCAD writes it. - INSERT and ATTSYNC give references the definition's multiline text placed with them; MOVE/ROTATE/SCALE, Properties rotation and scale, annotative scaling and FLATTEN carry it. - Tests: synthetic multiline ATTDEF and ATTRIB (read, drawn, saved, edited, pre-2007 save, damaged embedded groups); engine INSERT, MOVE, ATTEDIT and ATTSYNC. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Multiline attributes: read MTEXT direction from its own groups (#667, as #834 does) #834 moves these lines' fix into the MTEXT reader; the same fix in the shared mtext_from keeps the two compatible. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
48352f2baf |
Dynamic block grips: show and drag a dynamic reference's grips (stacked on #878) (#883)
* Dynamic blocks: read parameters and actions from AutoCAD files A dynamic block's evaluation graph (kept as foreign data since #528) is read into a typed model, `cadcraft_doc::dynblock`, without changing the kept data: parameters (linear with value sets, point, visibility states, lookup, base point; polar, XY, rotation, alignment and flip by geometry) and actions (stretch with its frame and moved vertices, lookup tables; move, scale, rotate, flip, array, polar stretch by kind), each with its graph id and the parameters it follows. - `blocks.dynamic {name}` returns the model as JSON (handles as hex); `blocks.list` marks dynamic blocks. - Counts and values come from the file: capped by the groups present, non-finite numbers and missing members skipped. - Tests: a synthetic DOOR block (visibility, linear list, stretch, lookup), its survival through a save, damaged data, and the engine commands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: their values and custom properties A dynamic block reference's extension dictionary says which dynamic block it shows (AcDbBlockRepresentation ▸ AcDbRepData) and the values it was given (AppDataCache ▸ ACAD_ENHANCEDBLOCKDATA, one XRECORD per parameter graph id). `dynblock::reference` reads them; a reference to the dynamic block itself has the block's values. - `dynblock::custom_properties`: the Properties palette's Custom section, in parameter order, only parameters shown in Properties: visibility state, lookup value worked out from the lookup tables (their "no match" name, e.g. Custom, when the inputs match no row), distances and point positions in drawing units (block units × the reference's scale), with the choices of each (states, lookup values, a distance's list). - Properties: a dynamic block reference shows its dynamic block's name instead of its anonymous block's, and a read-only Custom section. - `blocks.reference {handle}` returns the definition, values and properties. - Tests: synthetic references (own values, an anonymous block scaled 2, a width no lookup row has), survival through a save, the engine command. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: change the visibility state Choosing a visibility state (or a lookup value whose tables set only visibility states) in Properties ▸ Custom, or `blocks.reference.set {handle, name, value}`, changes a dynamic block reference as AutoCAD does: - The reference gets a new anonymous block: its current one with the state's objects shown and the parameter's other objects hidden (matched to the dynamic block's objects by their AcDbBlockRepETag element tags). The old anonymous block goes when nothing else uses it. - AutoCAD's link data is written: the new block's record carries AcDbBlockRepBTag (the dynamic block's record), copied objects keep their element tags, and the reference's AcDbBlockRepresentation data records the value (an existing value record is updated; a new one copies another reference's record for the same parameter when there is one). - An attribute whose definition the state hides is written hidden (60). - Changes CADCraft can't make yet (distances, positions, lookups that set them) are refused with a message and change nothing; Properties shows only what can change as a dropdown (`CustomProperty::editable`). - Tests: the synthetic DOOR references (own values and an anonymous block), survival through a save, refusals, and the engine command with undo. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: distances, positions, stretch and move actions, lookup chaining Linear distances (snapped to their value sets) and point positions can be changed; the stretch and move actions that follow them run (listed vertices or whole objects, multiplier and angle offset), parameters in an action's selection are carried along, associative hatches refill from their stretched outlines and the reference's attributes move with their definitions. Lookup tables run both ways (a changed input gives its table's lookup value, which sets the other tables' inputs). Connections are read in either group order. Checked against AutoCAD's own references (*U10, *U12). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: record changes in the history as AutoCAD does; full value data for new references A changed reference's ACAD_ENHANCEDBLOCKHISTORY says what was done to it: a visibility state or lookup value by property name, a distance or position as the drag of its grips (GRIPLOC, how far each grip is from where the dynamic block has it). A reference that had no data gets a record for everything other references of the same dynamic block have, with its own values. Templates come only from references of the same dynamic block; anonymous copies have no units; boundary reactors follow the copies. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block history: record only the grips a change moves AutoCAD's history holds the user's own drags; a grip that only moved with another parameter (a stretch carrying it) gets no entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block history: a distance by name, as typed in Properties AutoCAD records a distance typed in Properties as the parameter's name and value in block units (1071 id, 300 Distance2, 40 40.0), replacing drags of its grips; positions stay grip drags. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * DWG: dynamic block lookup parameters keep their name and lookup action AutoCAD writes a lookup parameter's subclass marker as AcDbBlockLookUpParameter; the DWG bridge reads AcDbBlockLookupParameter and matches it exactly, so the parameter's name (303) and lookup action (94) were lost in DWG files and AutoCAD's lookups stopped working (a visibility change no longer resized the block). The bridge DXF now uses its spelling. Found by driving AutoCAD on CADCraft's output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic blocks: carried parameter points are in a stretch frame where the block has them AutoCAD evaluates actions from the dynamic block itself, so a parameter point another action has moved out of a stretch frame still follows it. Testing the current position instead changed a stretched label's width when its visibility changed (Distance2 183.75 became 184.45; AutoCAD keeps 183.75). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block grips: show and drag a dynamic reference's grips as AutoCAD does A selected dynamic block reference shows its grips: an arrow at each end of a distance, a square at a position, a down-pointing triangle for a visibility or lookup list, only those its visibility state lists. Dragging an arrow changes the distance along the parameter (snapped to its values; a typed number sets it), a square moves the position, a list grip offers its choices; actions and lookups follow, with a live preview. doc: dynblock::grips, drag_grip; grip objects by graph id. engine: blocks.reference.grips, blocks.reference.grip, Session::start_dyn_grip. ui: canvas dynamic grips (GRIPDYNCOLOR-like token), list popup. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Tests: read the shared DOOR fixture with LF line ends whatever the checkout gives Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic blocks: carried parameter points are in a stretch frame where the block has them AutoCAD evaluates actions from the dynamic block itself, so a parameter point another action has moved out of a stretch frame still follows it. Testing the current position instead changed a stretched label's width when its visibility changed (Distance2 183.75 became 184.45; AutoCAD keeps 183.75). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic grips: Ukrainian labels for the new commands; copy the hot grip instead of cloning Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
0d138c2954 |
Dynamic block references: distances, positions, stretch and move actions, lookups both ways (stacked on #860) (#878)
* Dynamic blocks: read parameters and actions from AutoCAD files A dynamic block's evaluation graph (kept as foreign data since #528) is read into a typed model, `cadcraft_doc::dynblock`, without changing the kept data: parameters (linear with value sets, point, visibility states, lookup, base point; polar, XY, rotation, alignment and flip by geometry) and actions (stretch with its frame and moved vertices, lookup tables; move, scale, rotate, flip, array, polar stretch by kind), each with its graph id and the parameters it follows. - `blocks.dynamic {name}` returns the model as JSON (handles as hex); `blocks.list` marks dynamic blocks. - Counts and values come from the file: capped by the groups present, non-finite numbers and missing members skipped. - Tests: a synthetic DOOR block (visibility, linear list, stretch, lookup), its survival through a save, damaged data, and the engine commands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: their values and custom properties A dynamic block reference's extension dictionary says which dynamic block it shows (AcDbBlockRepresentation ▸ AcDbRepData) and the values it was given (AppDataCache ▸ ACAD_ENHANCEDBLOCKDATA, one XRECORD per parameter graph id). `dynblock::reference` reads them; a reference to the dynamic block itself has the block's values. - `dynblock::custom_properties`: the Properties palette's Custom section, in parameter order, only parameters shown in Properties: visibility state, lookup value worked out from the lookup tables (their "no match" name, e.g. Custom, when the inputs match no row), distances and point positions in drawing units (block units × the reference's scale), with the choices of each (states, lookup values, a distance's list). - Properties: a dynamic block reference shows its dynamic block's name instead of its anonymous block's, and a read-only Custom section. - `blocks.reference {handle}` returns the definition, values and properties. - Tests: synthetic references (own values, an anonymous block scaled 2, a width no lookup row has), survival through a save, the engine command. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: change the visibility state Choosing a visibility state (or a lookup value whose tables set only visibility states) in Properties ▸ Custom, or `blocks.reference.set {handle, name, value}`, changes a dynamic block reference as AutoCAD does: - The reference gets a new anonymous block: its current one with the state's objects shown and the parameter's other objects hidden (matched to the dynamic block's objects by their AcDbBlockRepETag element tags). The old anonymous block goes when nothing else uses it. - AutoCAD's link data is written: the new block's record carries AcDbBlockRepBTag (the dynamic block's record), copied objects keep their element tags, and the reference's AcDbBlockRepresentation data records the value (an existing value record is updated; a new one copies another reference's record for the same parameter when there is one). - An attribute whose definition the state hides is written hidden (60). - Changes CADCraft can't make yet (distances, positions, lookups that set them) are refused with a message and change nothing; Properties shows only what can change as a dropdown (`CustomProperty::editable`). - Tests: the synthetic DOOR references (own values and an anonymous block), survival through a save, refusals, and the engine command with undo. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: distances, positions, stretch and move actions, lookup chaining Linear distances (snapped to their value sets) and point positions can be changed; the stretch and move actions that follow them run (listed vertices or whole objects, multiplier and angle offset), parameters in an action's selection are carried along, associative hatches refill from their stretched outlines and the reference's attributes move with their definitions. Lookup tables run both ways (a changed input gives its table's lookup value, which sets the other tables' inputs). Connections are read in either group order. Checked against AutoCAD's own references (*U10, *U12). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: record changes in the history as AutoCAD does; full value data for new references A changed reference's ACAD_ENHANCEDBLOCKHISTORY says what was done to it: a visibility state or lookup value by property name, a distance or position as the drag of its grips (GRIPLOC, how far each grip is from where the dynamic block has it). A reference that had no data gets a record for everything other references of the same dynamic block have, with its own values. Templates come only from references of the same dynamic block; anonymous copies have no units; boundary reactors follow the copies. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block history: record only the grips a change moves AutoCAD's history holds the user's own drags; a grip that only moved with another parameter (a stretch carrying it) gets no entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block history: a distance by name, as typed in Properties AutoCAD records a distance typed in Properties as the parameter's name and value in block units (1071 id, 300 Distance2, 40 40.0), replacing drags of its grips; positions stay grip drags. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * DWG: dynamic block lookup parameters keep their name and lookup action AutoCAD writes a lookup parameter's subclass marker as AcDbBlockLookUpParameter; the DWG bridge reads AcDbBlockLookupParameter and matches it exactly, so the parameter's name (303) and lookup action (94) were lost in DWG files and AutoCAD's lookups stopped working (a visibility change no longer resized the block). The bridge DXF now uses its spelling. Found by driving AutoCAD on CADCraft's output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic blocks: carried parameter points are in a stretch frame where the block has them AutoCAD evaluates actions from the dynamic block itself, so a parameter point another action has moved out of a stretch frame still follows it. Testing the current position instead changed a stretched label's width when its visibility changed (Distance2 183.75 became 184.45; AutoCAD keeps 183.75). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
f8521ab299 |
Dynamic block references: change the visibility state (stacked on #853) (#860)
* Dynamic blocks: read parameters and actions from AutoCAD files A dynamic block's evaluation graph (kept as foreign data since #528) is read into a typed model, `cadcraft_doc::dynblock`, without changing the kept data: parameters (linear with value sets, point, visibility states, lookup, base point; polar, XY, rotation, alignment and flip by geometry) and actions (stretch with its frame and moved vertices, lookup tables; move, scale, rotate, flip, array, polar stretch by kind), each with its graph id and the parameters it follows. - `blocks.dynamic {name}` returns the model as JSON (handles as hex); `blocks.list` marks dynamic blocks. - Counts and values come from the file: capped by the groups present, non-finite numbers and missing members skipped. - Tests: a synthetic DOOR block (visibility, linear list, stretch, lookup), its survival through a save, damaged data, and the engine commands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: their values and custom properties A dynamic block reference's extension dictionary says which dynamic block it shows (AcDbBlockRepresentation ▸ AcDbRepData) and the values it was given (AppDataCache ▸ ACAD_ENHANCEDBLOCKDATA, one XRECORD per parameter graph id). `dynblock::reference` reads them; a reference to the dynamic block itself has the block's values. - `dynblock::custom_properties`: the Properties palette's Custom section, in parameter order, only parameters shown in Properties: visibility state, lookup value worked out from the lookup tables (their "no match" name, e.g. Custom, when the inputs match no row), distances and point positions in drawing units (block units × the reference's scale), with the choices of each (states, lookup values, a distance's list). - Properties: a dynamic block reference shows its dynamic block's name instead of its anonymous block's, and a read-only Custom section. - `blocks.reference {handle}` returns the definition, values and properties. - Tests: synthetic references (own values, an anonymous block scaled 2, a width no lookup row has), survival through a save, the engine command. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: change the visibility state Choosing a visibility state (or a lookup value whose tables set only visibility states) in Properties ▸ Custom, or `blocks.reference.set {handle, name, value}`, changes a dynamic block reference as AutoCAD does: - The reference gets a new anonymous block: its current one with the state's objects shown and the parameter's other objects hidden (matched to the dynamic block's objects by their AcDbBlockRepETag element tags). The old anonymous block goes when nothing else uses it. - AutoCAD's link data is written: the new block's record carries AcDbBlockRepBTag (the dynamic block's record), copied objects keep their element tags, and the reference's AcDbBlockRepresentation data records the value (an existing value record is updated; a new one copies another reference's record for the same parameter when there is one). - An attribute whose definition the state hides is written hidden (60). - Changes CADCraft can't make yet (distances, positions, lookups that set them) are refused with a message and change nothing; Properties shows only what can change as a dropdown (`CustomProperty::editable`). - Tests: the synthetic DOOR references (own values and an anonymous block), survival through a save, refusals, and the engine command with undo. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * DWG: dynamic block lookup parameters keep their name and lookup action AutoCAD writes a lookup parameter's subclass marker as AcDbBlockLookUpParameter; the DWG bridge reads AcDbBlockLookupParameter and matches it exactly, so the parameter's name (303) and lookup action (94) were lost in DWG files and AutoCAD's lookups stopped working (a visibility change no longer resized the block). The bridge DXF now uses its spelling. Found by driving AutoCAD on CADCraft's output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
73b8edac61 |
Dynamic block references: custom properties in Properties (stacked on #838) (#853)
* Dynamic blocks: read parameters and actions from AutoCAD files A dynamic block's evaluation graph (kept as foreign data since #528) is read into a typed model, `cadcraft_doc::dynblock`, without changing the kept data: parameters (linear with value sets, point, visibility states, lookup, base point; polar, XY, rotation, alignment and flip by geometry) and actions (stretch with its frame and moved vertices, lookup tables; move, scale, rotate, flip, array, polar stretch by kind), each with its graph id and the parameters it follows. - `blocks.dynamic {name}` returns the model as JSON (handles as hex); `blocks.list` marks dynamic blocks. - Counts and values come from the file: capped by the groups present, non-finite numbers and missing members skipped. - Tests: a synthetic DOOR block (visibility, linear list, stretch, lookup), its survival through a save, damaged data, and the engine commands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic block references: their values and custom properties A dynamic block reference's extension dictionary says which dynamic block it shows (AcDbBlockRepresentation ▸ AcDbRepData) and the values it was given (AppDataCache ▸ ACAD_ENHANCEDBLOCKDATA, one XRECORD per parameter graph id). `dynblock::reference` reads them; a reference to the dynamic block itself has the block's values. - `dynblock::custom_properties`: the Properties palette's Custom section, in parameter order, only parameters shown in Properties: visibility state, lookup value worked out from the lookup tables (their "no match" name, e.g. Custom, when the inputs match no row), distances and point positions in drawing units (block units × the reference's scale), with the choices of each (states, lookup values, a distance's list). - Properties: a dynamic block reference shows its dynamic block's name instead of its anonymous block's, and a read-only Custom section. - `blocks.reference {handle}` returns the definition, values and properties. - Tests: synthetic references (own values, an anonymous block scaled 2, a width no lookup row has), survival through a save, the engine command. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * DWG: dynamic block lookup parameters keep their name and lookup action AutoCAD writes a lookup parameter's subclass marker as AcDbBlockLookUpParameter; the DWG bridge reads AcDbBlockLookupParameter and matches it exactly, so the parameter's name (303) and lookup action (94) were lost in DWG files and AutoCAD's lookups stopped working (a visibility change no longer resized the block). The bridge DXF now uses its spelling. Found by driving AutoCAD on CADCraft's output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
fbc7037a10 |
Dynamic blocks: read parameters and actions from AutoCAD files (#838)
* Dynamic blocks: read parameters and actions from AutoCAD files A dynamic block's evaluation graph (kept as foreign data since #528) is read into a typed model, `cadcraft_doc::dynblock`, without changing the kept data: parameters (linear with value sets, point, visibility states, lookup, base point; polar, XY, rotation, alignment and flip by geometry) and actions (stretch with its frame and moved vertices, lookup tables; move, scale, rotate, flip, array, polar stretch by kind), each with its graph id and the parameters it follows. - `blocks.dynamic {name}` returns the model as JSON (handles as hex); `blocks.list` marks dynamic blocks. - Counts and values come from the file: capped by the groups present, non-finite numbers and missing members skipped. - Tests: a synthetic DOOR block (visibility, linear list, stretch, lookup), its survival through a save, damaged data, and the engine commands. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * DWG: dynamic block lookup parameters keep their name and lookup action AutoCAD writes a lookup parameter's subclass marker as AcDbBlockLookUpParameter; the DWG bridge reads AcDbBlockLookupParameter and matches it exactly, so the parameter's name (303) and lookup action (94) were lost in DWG files and AutoCAD's lookups stopped working (a visibility change no longer resized the block). The bridge DXF now uses its spelling. Found by driving AutoCAD on CADCraft's output. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Dynamic blocks: a work budget on the record cursor, so counts promising missing groups can't make nested loops rescan a hostile record (with regression test) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
28b8160407 |
DXF: associative hatches in blocks keep their boundary; boundaries carry the hatch reactor (#871)
A hatch inside a block was written with no source objects (the writer looked for them in model and paper space only), and no boundary object carried the hatch as a persistent reactor. AutoCAD keeps the two linked both ways; without it a stretched dynamic block in AutoCAD moved the outline but not the fill. Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
|
5ce44acfb2 |
Pick dimensions and multileaders anywhere on their text (#807)
Plain TEXT and MTEXT are picked anywhere inside their box, but a dimension or multileader was only found near its lines: its hit geometry is built without text. Hovering or clicking the words of a dimension found nothing (on a survey plan, 2 of 34 letters of a dimension's text). A point inside the box around the words, turned with the text, now picks the object. A dimension with a block, as AutoCAD saves them, is drawn from that block, so its text box comes from the TEXT and MTEXT in the block, not from the text the dimension's own geometry would place (on the same plan that was a different place, eight times smaller). A multileader's text box comes from its MTEXT layout. Co-authored-by: Cody Vogt <18035288+codyvogt@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |