abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 
abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 
BIM Coordinator Program (INT) April 22, 2024
Gehen Sie den nächsten Schritt Ihrer Karriere als zertifizierter Graphisoft BIM Koordinator!
Programmierung
Alles über Programmierung in GDL und Python

Request-Befehle in alten Archicad Objekten.

graber
Booster
Gemäß http://gdl.graphisoft.com/reference-guide/request-options
entfallen offenbar Stück für Stück diverse Request-Befehle?!

1.) Wie geht man / geht ihr daher mit diversen Objekten um, die diese Befehle beinhalten?
2.) Sind diese umzuprogrammieren, und wenn ja wie? (Gibt es alternative Befehle?)

P.S.: Was tun mit Objekten die in alten Projekten eingebettet sind, da bleibt die Kompatibilität dann auf der Strecke?!
12 ANTWORTEN 12
Frank Beister
Advisor
if used in parameter script

Ebenda und auch im Master Skript nict mehr verwenden.
bim author since 1994 | bim manager since 2018 | author of selfGDL.de | openGDL | skewed archicad user hall of fame | author of bim-all-doors.gsm
graber
Booster
Ok, (bei neuen Objekten und im Parameter-Skript) nicht mehr verwenden...
Was aber tun mit alten Objekten?

Hab' unter anderem auch mit der Glob_Context-Variable in einigen meiner Objekte zu kämpfen: Sind die alle umzuprogrammieren (-sofern möglich)?
Zudem kommt diesbezüglich ja keine Meldung, sondern merkt erst ind er Anwendung, dass diese nicht mehr (ganz) so funktionieren.

Konkret zur oben erwähnten Glob_Context-Variable, welchen Roundabout gibt es da?

Danke
Frank Beister
Advisor
Was aber tun mit alten Objekten?

Hab' unter anderem auch mit der Glob_Context-Variable in einigen meiner Objekte zu kämpfen: Sind die alle umzuprogrammieren (-sofern möglich)?
Ja.
Wie man aus Deiner Tabelle sieht, zeichnet sich die Problematik seit drei Jahren ab, kommt also nicht überraschend.
Das gibt keinen globalen Workaround. Das hängt von dem Einsatzbereich in dem Objekt ab.
Du kannst schon 90% fixen, wenn du alles, was nicht im Masterskript stehen MUSS in die übrigen verlagerst. Wann brauchst Du denn GLOB_CONTEXT im Parameter Skript?

[Objekte sind nun mal Programme. Und bei mir laufen Objekte mit 20 Jahre altem Quellcode auf der aktuellen Version. Da finde ich nicht, dass man sich beklagen kann, wenn GS mal aus Geschwindigkeitsgründen (!) alte Zöpfe "abschneidet". ich sag mal "A20 Gate", wem das noch was sagt.]
bim author since 1994 | bim manager since 2018 | author of selfGDL.de | openGDL | skewed archicad user hall of fame | author of bim-all-doors.gsm
graber
Booster
Liebe GDL-Profis,
Wie oben erwähnt, muß ich meine Objekte umprogrammieren.
Wie kann ich folgenden Skriptaufbau nun ändern:
.) im UI-Script:
ui_button ui_function, "^",0,20,16,13,101

.) im Parameter-Script:
if GLOB_CONTEXT=5 AND glob_ui_button_id = 101 THEN 
PARAMETERS bez1=bez2, bez2=bez1
endif
glob_ui_button_id=0


Wenn ich also den Knopf drücke, sollen die Parameter bez1 und bez2 ausgetauscht werden.
graber
Booster
Dieses Problem ist schon gelöst. (Einfach GLOB_CONTEXT=5 weglassen)
graber
Booster
Für alle dies interessiert: Für Glob_Context habe ich als "Ersatz" Glob_View_Type gefunden:
http://gdl.graphisoft.com/gdl-style-guide/general-scripting-issues#GDLExecutionContext_section
Anonymous
Nicht anwendbar
Ein Blick ins GDL-Handbuch sagt uns:

GLOB_VIEW_TYPE - Typ der aktuellen Sicht - (sichtenabhängig, nicht im Parameter-Script verwenden)

Es ght nicht darum andere Parameter zu verwenden, sondern schlicht keine kontextabhängigen Strukturen im Parameter Skript zu verwenden. Das geht auch mit teilweise etwas mehr Aufwand.
graber
Booster
@kontextabhängige Strukturen:
Wieso soll ich im Master- (oder auch im Parameter) Skript nicht auf das UI-Skript oder auf die graphische Eingabe reagieren können?
("Wenn Eingabe im UI-Skript, dann tu das, und wenn graphisch dann das, und wenn...")
Leider sind - bestehende Objekte (bei mir) in der Eingabe - manchmal genau davon abhängig.


Beispiel (bitte mir gerne alternative Lösungsvorschläge zu schicken):
Eine Leitung von A nach B, (B ist "tiefer" als A) mit Ausgabe der Leitungsneigung und der Tiefendifferenz.

.)Im Grundriss ist diese als Abwicklung (im Seitenriss) dargestellt und die Tiefe kann graphisch editiert werden. -> Umrechnung zur Angabe der Neigung
.)Im UI-Skript wird dagegen die Neigung der Leitung eingegeben -> Umrechnung zur Angabe der Tiefe.
-> d.h. das Master-/Parameterskript muß wissen, in welchem Skript gerade gearbeitet wird?! (Ich kann ja in den anderen Skripts keine Parameter zuweisen)
Anonymous
Nicht anwendbar
Wieso soll ich im Master- (oder auch im Parameter) Skript nicht auf das UI-Skript oder auf die graphische Eingabe reagieren können?


Weil du nicht auf Skripte reagieren kannst, sondern nur auf Parameter, die einen bestimmten Wert haben. Sind die Skripte abgearbeitet haben sie in ihrem Kontext was bewirkt. Und das User Interface Skript hat nun mal keine Auswirkung auf die Parameter, sondern das Parameter-Skript das sofort ausgeführt wird, sobald Du eine Eingabe im UI oder Parametertabelle gemacht hast.

Das Master ist dafür da, dass Du dort Teile unterbringst, die alle Skripte betreffen. Z.B. die Berechnung der Neigung einer Leitung. Aber das Zuweisen (PARAMETERS neig=neig) dieser berechneten Neigung gehört ins Parameters Skript. Die Abfrage, ob Du im Parameter-Skript bist und das dann im Master unterzubringen ist ohnehin witzlos, da NUR im Parameter-Skript-Kontext der Befehl PARAMETERS etwas bewirkt. In allen anderen kontexten wird der ignoriert. Dann kannst Du die Zeile gleich ins Parameter Skript packen.

Selbst wenn Du Skriptteile hast, die in mehreren Skripten benötigt werden, du diese aber in einem speziellen Kontext nicht verwenden willst, ist das ohne GLOB_CONTEXT und ohne Redundanz lösbar:

MASTER:
x = A
y = zzyzx

GOTO "masterend"

! --------------------------
! SUBS

"calcNeigung":
neig = y/x
RETURN

! --------------------------
"masterend":


2D-Skript:
GOSUB "calcNeigung"
text2 0,0,neig


3D-Skript:
GOSUB "calcNeigung"
LIN_ 0,0,0, 1,0,0
ROTy neig
LIN_ 0,0,0, 1,0,0


Parameter-Skript:
IF GLOB_MODPAR_NAME = "neig" THEN
zzyzx = A * TAN(neig)
PARAMETERS zzyzx = zzyzx
ENDIF


AC ist es nämlich egal, wo das Unterprogramm steht. Zur Ausführung des Skripts wird Master- und Kontext-Skript quasi wie zu einem zusammengefügt. Nur musst Du natürlich die Ausführung erstmal umgehen, indem Du den Teil überspringst. Stilistisch nicht der Bringer, aber mitunter besser als mit Makros anzufangen.

[Das Beispiel oben ist nicht das sinnvollste, erklärt aber das Prinzip]

Im UI gibt es auch nicht solche Beschränkungen wie im Parameter Skript. Poste mal genau die Skripte und ich zeige Dir, dass das problemlos geht.

Wenn Du anfängst für jeden Kontext die Programmierung separat zu betrachten und das Master zu entschlacken, entwirrt sich das Ganze.
Einschreiben und zertifiziert werden!