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