Hallo,
geht ja runter wie Öl
Die Aktionen sind zugegebenermaßen spärlich dokumentiert.
check_titleblock füllt Zeichnungskopf neu aus, sofern in Aktion eingefütterte Zeichnung gerade geladen ist (ProcessDoc(Reserviert Laden), danach Speichern, wenn Rechte mitspielen, der PWGenerate macht Laden und befüllen automatisch).
Historisch gesehen waren die mdbscripts rein editierbar per Notepad und gedacht für diverse "lightweight"-Kopplungen, sowie zum Abbilden des MaxxDB2-Verhaltens trotz deaktiviertem MDB2_Fallback. Im Laufe der Zeit kam dann der Aktionseditor, Flußsteuerung(if,allow,while), Stringparsing, spezielle Platzhalter und Rückgabewerte hinzu (hat Makro funktioniert? Was enthält Katalog zu Feld xy an Stelle 2?)
In der 3 ist jeder manuell hinzugefügte Status erstmal blank und kann dann mittels Aktionen verfeinert werden. Gerade der call_intern enthält etliche Verweise auf bereits vorhandene 2er-Funktionen, für uns in der Entwicklung sind Begriffe wie "check_titleblock" allgemein bekannt.. so mangelt es an jenen Stellen auch an Doku. die call_intern-Befüllung geschieht vornehmlich durch die 3er-Migration wenn diese auf einen Status trifft, der schon in der 2er bekannt war.
Wenn Sie über eine losgelöste Testumgebung auf separater Datenbank (und entsprechend Zeit zum Spielen) verfügen, können Sie gern mal ausprobieren welche Einflüße eine Migration bei bestimmten 2er-Optionen vorweist. (Release_Only_All_Released, Normung, Generate_pdf, pwusers.cfg... usw.)
MaxxDB ist ein ständig wachsendes System, wo ab und zu kundenspezifische Erweiterungen einfliessen. Dies hatte auch Einfluss auf das Wachstum an vorhandenen Aktionen.
Wenn spezielle Wünsche auftreten, lösen wir diese üblicherweise über Dienstleistung als Aktionsworkshop. Jeder hatte soweit andere Zielsetzungen und es war spannend herauszufinden, ob diese per Aktion wirklich abbildbar sind.
Gruß
omoll
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP