A connection is a CONNECTION_ARROW block sitting at the midpoint of an arrow
between two TRO markers. It stores the relationship as attributes rather than by
position:
TRO11 ----------> TRO14
UID 0062 UID 0065
Same architecture as the TRO feature, nothing new introduced:
Blockname CONNECTION_* -> c:CONNECTION_EDIT (Lisp/Connection_Edit.lsp)
-> dcl/connection_edit.dcl
The double-click and EATTEDIT hooks already route every INSERT through
SSG_BLOCKEDIT, so this is one more branch in that dispatcher - placed before the
TRO branch since both come from the same annotation run and the patterns must not
overlap. DCL path from DXFM_DCL, ssg-start/ssg-end, ssg-attrib-read and
ssg-attrib-set-on, all text via ssg-text/ssg-textf with 16 new keys in both
language files. Loading is lazy: not preloaded in the MNL, pulled by the menu
macros and the dispatcher with (ssg-ensure "Connection_Edit"), with a fallback to
native EATTEDIT if the module is missing.
CONNECTION_INSERT picks two TRO markers and draws the connection; the new
internal number comes from ssg-id-max/ssg-id-format, so it stays inside the
SSG_LIB number space. It refuses when the block definition is absent - the shape
comes from tro_annotate.py, this command does not invent one.
Menu: SSG_LIB > Connections with Verbindung einfuegen, Verbindung bearbeiten and
Bearbeiten (Auto), plus an entry in the POP501 edit context menu.
On the internal id: the markers keep their visible ID (TRO11) untouched - the
existing TRO_INSERT/tro-naechste-id read it and the request was explicit about
not changing it. The permanent unique number therefore lives in a separate
attribute UID, in the same four-digit space as ssg_id and the CSV TeileId.
Putting it into ID was tried and reverted: IDSCHECK treats ID as numeric and
would have overwritten TRO11 with a number while correcting duplicates.
Connections reference the UIDs, so the relationship survives a renamed or moved
marker.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The TRO markers written by sps_skel (lib/tro_annotate.py) are blocks
TRO_SYM_<type> carrying ID and TYPE as attributes. This wires them into the
existing SSG_LIB mechanisms rather than adding new ones.
The double-click hook and the EATTEDIT override already exist: ***DOUBLECLICK
routes [INSERT] to SSG_BLOCKEDIT, and c:EATTEDIT is undefined and forwarded to
the same dispatcher. So all that was missing was a branch:
Blockname TRO_* -> c:TRO_EDIT (Lisp/Tro_Edit.lsp) -> dcl/tro_edit.dcl
Tro_Edit.lsp follows the conventions of the other edit commands: DCL path from
DXFM_DCL, ssg-start/ssg-end around the command, ssg-attrib-read and
ssg-attrib-set-on for the attributes, all user-visible text via ssg-text/
ssg-textf with keys in lang/de_DE.json and en_GB.json. Implied selection is read
before ssg-start, since ssg-start clears it - the same note Gefaellestrecke.lsp
carries.
TYPE is a picklist rather than free text so it cannot drift from the type
catalogue. The list comes from Lisp/tro_types.lsp, generated on the sps_skel side
by "tro_annotate.py --emit-lisp" into DXFM_LISP. If that file is absent the
dialog offers the block's current type and still works.
Loading is lazy: the module is not preloaded in the MNL. The menu macros and the
dispatcher pull it with (ssg-ensure "Tro_Edit") on first use, and the dispatcher
falls back to native EATTEDIT if the module cannot be found. ssg_load.lsp loads
it for the non-menu path.
Menu: SSG_LIB > TRO with "Marker bearbeiten" and "Bearbeiten (Auto)", plus an
entry in the POP501 edit context menu.
The dialog changes attributes only. The marker shape belongs to the block
definition of the type and FB_BLOCK is derived from it, so both follow on the next
tro_annotate.py run; the dialog states this and the command prints a reminder when
the type was changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bin/on_start.lsp entfernt:
Das Laden aller Module uebernimmt heute vollstaendig SSG_LIB.mnl,
das automatisch beim MENULOAD geladen wird und ssg-ensure fuer
Lazy-Loading sowie alle Kern- und Feature-Module direkt ausfuehrt.
on_start.lsp war nirgendwo mehr referenziert (kein .bat, .mnu, .mnl
oder .lsp rief die Datei oder ssg-lib-startup noch auf).
Lisp/ssg_load.lsp: Pfadermittlung robuster gemacht:
base-path nutzt jetzt 1) DXFM_LISP, 2) findfile, 3) DWGPREFIX.
Vorher schlug findfile "ssg_core.lsp" fehl wenn DXFM_LISP nicht im
BricsCAD-Suchpfad war, load gab still den Fehlerstring zurueck und
ssg-load-config crashte mit "no function definition".
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
data/json/component_defaults.json: Neue zentrale Konfigurationsdatei
mit Standardwerten fuer alle Komponenten (kreisel, eckrad, omniflo,
vario, gefaelle, infrastruktur). Bisher waren Konstanten (Masse,
Farben, Toleranzen, Defaults) hart im LISP-Code eingebettet.
Lisp/ssg_core.lsp: JSON-Parser und Config-Zugriff hinzugefuegt:
- ssg-read-file-lines: Datei zeilenweise einlesen
- ssg-cfg-trim, ssg-cfg-split-comma: String-Hilfsfunktionen
- ssg-cfg-parse-value, ssg-cfg-parse-array: JSON-Wert-Parser
(unterstuetzt String, Zahl, Boolean, Array, null)
- ssg-cfg-parse-section: JSON-Sektion zu Assoziationsliste parsen
- ssg-load-config: Laedt component_defaults.json in *ssg-config*
- ssg-cfg: Wert aus *ssg-config* lesen, nil wenn nicht vorhanden
- ssg-cfg-or: Wert aus Config lesen mit Fallback-Default
Lisp/ssg_load.lsp: (ssg-load-config) wird direkt nach dem Laden von
ssg_core.lsp aufgerufen, sodass die Config beim Laden aller weiteren
Module bereits verfuegbar ist.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
s.ayadi
m.stangl
y.wang