Die interaktiven Editier-Pfade riefen den Neuaufbau ueber
vl-catch-all-apply auf. Der alte Block ist dort per entdel schon
entfernt, und der Catch faengt einen Abbruch (ESC -> (exit)) VOR
*error* ab - der Abbruch-Wickler vfl-modus-abbruch-sichern kam damit
nie zum Zug. Ergebnis: die komplette Kette blieb als lose Einzelteile
ohne VF_n-Block liegen und war nicht mehr per Doppelklick editierbar.
- vfl-edit-ent (Sektions-Zweig) und vfl-edit-ent2 rufen
vf-linienzug-modus/-modus2 jetzt DIREKT auf. Nur der
nicht-interaktive Batch-Konverter vfl-konvertiere-ent behaelt den
Catch (die Batch-Schleife muss weiterlaufen) und meldet den
betroffenen Block statt still zu scheitern.
- Beide Abbruch-Handler setzen *ssg-ils-dim* zurueck. Das tat bisher
nur der Aufrufer, der nach einem Abbruch nicht mehr erreicht wird -
der Dim-Override blieb fuer die restliche Sitzung stehen.
Wiederherstellung aus der Zeichnung (Sektions-XDATA):
- vfl-segment-xdata-sichern schrieb nur die Slice des LETZTEN Glieds
einer Schleifen-Iteration. Eine VF-Einheit mit eingebetteten
Vario-Kurven verlor dadurch ihre eigenen Eingaben. Jetzt wird der
komplette Journal-Abschnitt der Iteration geschrieben, indiziert mit
dem ersten Glied-Index darin (neu: vfl-journal-ab-glied,
vfl-steps-zaehlen). Ein Glied ohne Geometrie verbraucht seinen
Abschnitt nicht mehr - er wandert in den naechsten Record, der
Entities bekommt.
- Neue XDATA-App SSG_VF_EDIT_PRE haelt die Praeambel (Startpunkt,
Starthoehe, AS ja/nein + Winkel/Seite) auf den Entities der ersten
Iteration. Ohne sie fehlte der Kopf des Journals in jeder Sektion.
- Neuer Befehl VF_SEKTION_RESTORE: Auswahl der losen Geometrie ->
Sektionen lueckenlos ab Glied 1 zusammensetzen -> stummer Replay ->
interaktiv weiterbauen. Die alte Geometrie wird erst NACH
erfolgreichem Neuaufbau geloescht, ein Abbruch laesst sie samt XDATA
stehen (Versuch wiederholbar). Altbestand ohne Praeambel-XDATA wird
danach gefragt.
Die .dbg-Dateien bleiben reine Ausgabe und werden von keinem Befehl
gelesen - Wiederherstellungs-Daten gehoeren in die XDATA der Zeichnung.
tests/testdata/vfl_journal_hm05_abbruch.json: Journal der Session vom
2026-08-31 (9 Glieder), gegen das die Slice-/Join-Logik geprueft wurde.
Reine Daten, wird von keinem Befehl gelesen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Konflikt in lang/de_DE.json und lang/en_GB.json aufgeloest: beide Seiten
haben nur Schluessel ergaenzt (con-*/cmd-connection-* hier, sens-* aus
origin). Beide Saetze uebernommen, Einrueckung von origin (2 Leerzeichen)
beibehalten, tro-edit-fb mit UID-Anzeige uebernommen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- lib/dxf_scan_components.py: erkennt ILS-/Omniflo-Komponenten in fremden
Projektzeichnungen und schreibt sie im Testdaten-JSON-Schema aus
- lib/dxf_abbild.py: getreue Abbildung der Bauteile einer Fremdzeichnung
(Attribute, Weltkoordinaten, Unterkomponenten) ohne Interpretation
- tests/test_hundm05.{lsp,py}, testdata/hundm05.json, conftest-Fixtures und
alltests.json-Eintrag fuer den Kreisel-Abschnitt aus ST500592_05.dxf
- menu: TEST_HUNDM05 im Testmenue, Connection_Insert/Edit in SSG_LIB.cui
- Doku: hartkodierte Pfade durch (getenv "DXFMAKRO") ersetzt
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
Lets the TRO menu insert a fresh TRO_SYM_<Typ> marker (point + type +
auto-suggested TROnn id) by reusing a block definition tro_annotate.py
already created, instead of only editing markers it placed.
Analog zur bereits in df96071 nachgetragenen "ES-Element setzen?"-Antwort:
die in Commit 3e23003 neu eingefuehrte Frage am Einlauf fehlte noch in
linienzug_tests.json und hat die restliche Eingabe-Queue verschoben.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mubea:build-vario(-one) liest jetzt ein optionales "typ"-Feld ("standard"
Default, "etage") und dispatcht auf berechne-etage/etage-foerderanlage-
einfuegen bzw. vf-block-erstellen mit dem passenden Typ. Neuer Testfall
VF_Mubea_Etage_0061 bildet Objekt-ID 0061 aus Mubea_Quali.dxf nach
(deltaL=12790, deltaH=0, seite=links, Winkel=9, L_GF1=1602.4).
Co-Authored-By: Claude Sonnet 5 <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>
Baut aus export.csv ein gerichtetes Graph-Modell der Anlage und schreibt
es als .json (vollstaendig), .dot (GraphViz) und .mmd (Mermaid).
Statt der CSV-Spalte "Nachbarn" (ungerichtet, Strecken werden dort
absichtlich nicht gegeneinander getestet, und ein langer Kreisel
ueberdeckt flaechig die halbe Anlage) arbeitet das Modul mit
Anschlusspunkten: eine Kante entsteht nur, wenn ein Elementende im
Grundriss auf der Flaeche eines anderen Elements liegt.
Richtung exakt aus K1/K2 (KS_EIN/KS_AUS), sobald der Export diese
Spalten fuellt; solange sie leer sind heuristisch aus Schwerkraft
(Gefaellestrecke) bzw. dem Merkmal Antriebfahrtrichtung (Foerderer).
Jede Kante traegt die verwendete Quelle in "richtung_quelle".
Warnt zudem, wenn Insertpoint-Werte an der 24-Bit-Fixed-Point-Grenze
von csv:kos-encode (+-8388.607 Einheiten) abgeschnitten sind.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
build_variofoerderer_merkmale las noch die alten Attributnamen ohne
_mm-Suffix (HOEHE_VON, HOEHE_BIS, DELTA_H, DELTA_L) sowie SEITE/WINKEL.
Umbenannt wurden diese in *strecke-attr-front* (ssg_core.lsp) zu
HOEHE_VON_mm/HOEHE_BIS_mm/DELTA_H_mm/DELTA_L_mm bzw. aufgeteilt in
SEITE_AS/SEITE_ES und GF_WINKEL/VF_WINKEL. Da attribs.get() still den
Default "" liefert, blieben die Felder in der Merkmale-Spalte leer statt
einen Fehler zu melden - betroffen waren alle VF_n- UND GF_n-Zeilen
(beide nutzen denselben Builder). export_sivas.py war bereits nachge-
zogen, export_csv.py nicht; aufgefallen ist es nicht, weil
tests/reference/export_raw.json noch die alten Namen enthaelt.
- Attributnamen korrigiert, Alt-Namen per att()-Helper als Fallback,
damit aeltere export_raw.json-Dateien und noch nicht neu aufgebaute
Bloecke weiter Werte liefern
- Seite_AS/Seite_ES ersetzen das immer leere Seite
- VF_Winkel neu neben Winkel (= GF_WINKEL)
Geprueft gegen results/export_raw.json (neue Namen) und
tests/reference/export_raw.json (Alt-Namen); Pflichtfelder aus
tests/test_foerderer.py bleiben vorhanden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Unter Windows 11 traf ein blankes "python" den WindowsApps-Platzhalter
(kein echter Interpreter, Exitcode 49). Der Export schrieb die JSON, aber
nie eine CSV - ohne jede Fehlermeldung, da "fire and forget" per startapp.
- export:python-exe: Aufloesungsreihenfolge cfg/export.cfg [python]
interpreter= -> DXFM_PYTHON -> Projekt-venv -> %SystemRoot%/py.exe ->
"python"; WindowsApps-Platzhalter werden verworfen
- export:run-python: synchroner Aufruf per WScript.Shell.Run, stdout/stderr
nach DXFM_LOG/export_python.log, Exitcode-Auswertung
- export:log-ausgeben: erste Logzeilen in die BricsCAD-Kommandozeile
- setenv.bat setzt DXFM_PYTHON (venv oder py-Launcher)
- cfg/export.cfg: neue Sektion [python]
- lang/de_DE.json, lang/en_GB.json: neue Meldungstexte (exp-python-exe,
exp-export-done, exp-python-error, exp-python-store-hint, exp-csv-missing,
exp-python-call-failed)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Samer AyadiandClaude Opus 5