Phrontistes Geschrieben 19. Oktober Teilen Geschrieben 19. Oktober (bearbeitet) Hallo @Neo, diese endlose Diskussion veranlasst mich, im richtigen Forumsbereich anzuregen, ein print (wahlweise error) eines beliebigen Textes ins Ereignisprotokoll als Auswahlmöglichkeit in die graphische EV aufzunehmen. Vielleicht als vorletzten Punkt vor dem Skript aber nach der waagrechten Linie. Man würde sich dadurch sparen, den gleichen Text zweimal eingeben zu müssen, einmal beim Lua-print und einmal bei der Beschreibung damit man gleich sieht, was passiert. Beste Grüße Phrontistes Bearbeitet 19. Oktober von Phrontistes typo Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Neo Geschrieben 19. Oktober Teilen Geschrieben 19. Oktober Hallo Phrontistes, die bessere Lösung wäre doch, wenn die Skript-Aktion die erste Nicht-Kommentarzeile im Subtext anzeigt. Dann spart man sich ebenfalls die doppelte Schreibarbeit und hat zugleich bei allen Skripten einen Vorteil, nicht nur bei print oder error. Viele Grüße, Neo Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Anlagendesigner Geschrieben 19. Oktober Teilen Geschrieben 19. Oktober Interessant, wenn jemand anderes exakt den gleichen Wunsch äußert kannst du also vernünftig darüber sprechen? Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Neo Geschrieben 19. Oktober Teilen Geschrieben 19. Oktober Hallo Anlagendesigner, wir reden hier über Lua. Viele Grüße, Neo Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Phrontistes Geschrieben 19. Oktober Autor Teilen Geschrieben 19. Oktober Hallo @Neo, vor 2 Stunden schrieb Neo: die Skript-Aktion die erste Nicht-Kommentarzeile im Subtext anzeigt. Vielleicht besser die erste Zeile wiedergeben auch wenn es eine Kommentarzeile ist, denn dann kann man auf diese Weise den angezeigten Text beeinflussen. Sonst hast Du das Problem, was Du sinnvollerweise machst, wenn mehrfach editiert wird. Allerdings hast Du ein Übergangsproblem, weil man bisher einen Anzeigetext hinterlegen konnte. Beste Grüße Phrontistes Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Anlagendesigner Geschrieben 19. Oktober Teilen Geschrieben 19. Oktober Zitat wir reden hier über Lua. Zitat ein print (wahlweise error) eines beliebigen Textes ins Ereignisprotokoll als Auswahlmöglichkeit in die graphische EV aufzunehmen Wirklich? Es geht eher darum in der grafischen EV eine Auswahlmöglichkeit einzubauen - genau was ich auch geäußert hatte. Aber macht was ihr wollt. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Neo Geschrieben 19. Oktober Teilen Geschrieben 19. Oktober Hallo Anlagendesigner, bitte die Beiträge genau lesen. Ich möchte eben nicht die grafische EV um eine Auswahlmöglichkeit für "print" oder "error" erweitern, sondern die Skriptaktion verbessern, um den Zugang zu Lua noch leichter zu gestalten. Viele Grüße, Neo Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
EASY Geschrieben 19. Oktober Teilen Geschrieben 19. Oktober Hallo, vor 7 Stunden schrieb Neo: die bessere Lösung wäre doch, wenn die Skript-Aktion die erste Nicht-Kommentarzeile im Subtext anzeigt. Dann spart man sich ebenfalls die doppelte Schreibarbeit und hat zugleich bei allen Skripten einen Vorteil, nicht nur bei print oder error. ... ein mehrzeiliges Skript beginnt nicht zwingend mit einer aussagekräftigen Zeile (... kann sogar für verschiedene Skripte gleich sein) Deshalb würde ich dies auch bevorzugen.... vor 5 Stunden schrieb Phrontistes: Vielleicht besser die erste Zeile wiedergeben auch wenn es eine Kommentarzeile ist, denn dann kann man auf diese Weise den angezeigten Text beeinflussen. Gruß EASY Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
BahnLand Geschrieben 20. Oktober Teilen Geschrieben 20. Oktober (bearbeitet) Hallo aufgrund der Diskussion hier und ab hier habe ich in mein kleines Demo-Programm verschiedene Trace-Varianten eingebaut. Diagnose-Beispiel2.mbp Neben dem Aufruf des Benutzer-definerten Ereignisses "Trace" gibt es nun weitere Benutzer-definierte Ereignisse "Print" und "Error", in denen die print-Funktion und die error-Funktion von Lua aufgerufen werden, und die Ausführung dieser Lua-Funktionen in einem Script. Bei der Ausführung in einem Script wird die print-Anweisung direkt in der aufrufenden Ereignis-Definition ausgeführt. Dasselbe gilt für die Error-Funktion von Lua, die zum Abbruch der Ausführung der Ereignisdefinition führt. Ist die Ereignisprotokollierung eingeschaltet, wird auch die Anlage insgesamt pausiert. Um auch bei nicht geöffnetem Script zu sehen, was innerhalb passiert, muss auch eine entsprechende Beschreibung hinzugefügt werden. Beim Benutzer-definierten Ereignis "Print" habe ich wie beim Ereignis "Trace" einen Parameter vorgesehen, der an den Aufruf der Lua-print-Funktion weitergereicht wird. Beim Benutzerdefinierten Ereignis "Error" habe ich aufgrund eines unten beschriebenen Fehlers erst einmal auf diesen Parameter verzichtet und stattdessen einen festen Ausgabetext hinterlegt. Das obige Ereignisprotokoll enthält alle zuvor beschriebenen Trace-Varianten. Sowohl der Aufruf des Benutzer-definierten Ereignisses "Trace" ([1]) als auch der Schript-Aufruf mit dem Lua-print ([2]) geben eine einzige Protokollzeile aus, die beim Lua-print farblich hervorgehoben ist. Diesem Vorteil gegenüber dem Trace-Ereignis steht allerdings die Notwendigkeit gegenüber, neben dem eigentlichen print-Aufruf im Script auch dessen Beschreibung hinzufügen zu müssen, wenn man bereits in der Ereignisdefinition ohne Aufklappen des Scripts wissen möchte, welche Funktionalität dort realisiert ist. Ändert man das Script ab, muss damit auch die Beschreibung angepasst werden, um mögliche Inkonsistenzen zu vermeiden. Auch bei der Lua-print-Ausgabe über das Benutzer-definierte Ereignis "Print" ([3]) genügt wie beim Ereignis "Trace" der Aufruf selbst, um die Information direkt in der aufrufenden Ereignisdefinition anzuzeigen. Die dadurch ebenfalls erzielte farbliche Hervorhebung im Ereignisprotokoll erkauft man sich hier jedoch mit einer zweiten Ausgabezeile (Auflistung des Aufrufs und print-Ausgabe), wodurch das Ereignisprotokoll unnötig aufgebläht wird. Die error-Funktion von Lua kann wie die print-Funktion entweder direkt durch Ausführung eines Scripts ([4]) oder über ein einschalendes Benutzer-definertes Ereignis ([5]) aufgerufen werden. Während der Script-Aufruf [4] wie erwartet die im error-Befehl hinterlegte Information ausgibt, bekomme ich bei der Einschalung durch das Ereignis "Error" ([5]) eine Fehlermeldung angezeigt, obwohl die Syntax in beiden Lua-error-Aufrufen identisch ist. Frage an die Experten @Goetz und @Phrontistes: Was mache ich da im Benutzer-definierten Ereignis "Error" falsch (siehe die obige mbp-Datei)? Viele Grüße BahnLand Bearbeitet 20. Oktober von BahnLand Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Phrontistes Geschrieben 20. Oktober Autor Teilen Geschrieben 20. Oktober (bearbeitet) vor 6 Stunden schrieb BahnLand: Was mache ich da im Benutzer-definierten Ereignis "Error" falsch Hallo @BahnLand, im Ereignis kein Parameter definiert + reserviertes Schlüsselwort pur? Aber ich weiß es nicht, ohne zu testen, das kann ich erst später. Beste Grüße Phrontistes Nachtrag: Nein, das war es nicht. Man darf error offenbar nicht in einem benutzerdefinierten Ereignis auslösen (was im Übrigen ja so auch in der Fehlermeldung steht ). Wir haben hier übrigens auch kein reines Lua, sondern ein von @Neo kastriertes. Bearbeitet 20. Oktober von Phrontistes Nachtrag Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
BahnLand Geschrieben 20. Oktober Teilen Geschrieben 20. Oktober Hallo @Phrontistes, vor 2 Stunden schrieb Phrontistes: was im Übrigen ja so auch in der Fehlermeldung steht das konnte ich aus der Fehlermeldung "Scriptfehler (9)" nicht heraus lesen. Gibt es irgendwo einen Hinweis, welche Scriptfehler-Nummern es gibt, und was diese bedeuten? Viele Grüße BahnLand Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Neo Geschrieben 20. Oktober Teilen Geschrieben 20. Oktober Hallo BahnLand, die 9 ist keine Fehlerkennzeichnung, sondern die Zeilennummer, in der der Fehler aufgetreten ist. Aber soweit ist alles korrekt, "error" triggert immer einen Scriptfehler, das ist seine Funktion. Es gibt lediglich einen kleinen Anzeigeunterschied im Protokoll, je nachdem wo error aufgerufen wurde, ob im Hauptereignis oder in einer Unterroutine. Ich kann die Anzeige gern angleichen. Viele Grüße, Neo Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
EASY Geschrieben 20. Oktober Teilen Geschrieben 20. Oktober Hallo, ... mal neugierig nachgefragt... vor 29 Minuten schrieb Neo: Es gibt lediglich einen kleinen Anzeigeunterschied im Protokoll, je nachdem wo error aufgerufen wurde, ob im Hauptereignis oder in einer Unterroutine. ... kann ich das nicht auch noch mit "level" beeinflussen? oder worauf bezieht sich...? vor 33 Minuten schrieb Neo: Ich kann die Anzeige gern angleichen. P.S. Da ich nur mit lua arbeite... gibt es da noch einen Unterschied, wenn ich es (als Skript) aus der grafischen EV aufrufe? Gruß EASY Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Phrontistes Geschrieben 20. Oktober Autor Teilen Geschrieben 20. Oktober (bearbeitet) Hallo @BahnLand, vor 5 Stunden schrieb BahnLand: das konnte ich aus der Fehlermeldung "Scriptfehler (9)" nicht heraus lesen. ❓ Die Meldung geht weiter: "Script error (9): Pfad3b: Abbruch durch 'Error' in Benutzer-Ereignis". Genau das hast Du ja versucht. 9 ist die Zeilennummer der aufgerufenen Routine, dort wo "error ("Pfad3b: Abbruch durch 'Error' in Benutzer-Ereignis")" steht. Dass wir in der aufgerufenen Routine angelangt sind, sieht Du an der blauen Zeile ("Error") darüber. Die Ereignisanzeige hat korrekt mitbekommen, dass wir ins benutzerdefinierte Ereignis "Error" gesprungen sind und dann in Zeile 9 den Fehler gemacht haben, "error" in einem benutzerdefinierten Ereignis aufzurufen. Ereignisse mit Schlüsselwörtern zu benennen (Print, Error) kann etwas missverständlich sein, auch wenn das etwas anderes ist als die Schlüsselwörter print bzw. error. Beste Grüße Phrontistes Bearbeitet 20. Oktober von Phrontistes typo Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Neo Geschrieben 20. Oktober Teilen Geschrieben 20. Oktober vor 3 Stunden schrieb EASY: kann ich das nicht auch noch mit "level" beeinflussen? Ja das funktioniert. Bei 0 liefert Lua keine Zeileninformation und das Studio zeigt entsprechend auch keine Zeilennummer an. Ein Wert > 1 führt aber nur dann zu dem gewünschten Ergebis, wenn dein Skript selber aus Unterfunktionen besteht und error in so einer Unterfunktion aufgerufen wird. Zeileninformationen von übergeordneten Ereignissen werden dadurch aber nicht angezeigt, das Level wird von Lua verarbeitet, was keine Informationen über die Studio-Ereignisse hat. Viele Grüße, Neo Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Phrontistes Geschrieben 20. Oktober Autor Teilen Geschrieben 20. Oktober vor 3 Stunden schrieb EASY: gibt es da noch einen Unterschied, wenn ich es (als Skript) aus der grafischen EV aufrufe? Nein, das kannst Du beliebig mischen. Ausgeführt wird der Lua-Code, den Du sehen kannst, wenn Du in der graphischen Oberfläche auf <> klickst. Nur nebenbei: Der erzeugte Code ist aus nachvollziehbaren Gründen manchmal nicht ganz so elegant, wie direkt programmiertes Lua. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Phrontistes Geschrieben 20. Oktober Autor Teilen Geschrieben 20. Oktober Am 19.10.2024 um 15:31 schrieb Neo: die Skript-Aktion die erste Nicht-Kommentarzeile im Subtext Bitte auch bei der Skript-Bedingung. Und wie gesagt, die erste Zeile, auch wenn es eine Kommentarzeile sein sollte. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
BahnLand Geschrieben 20. Oktober Teilen Geschrieben 20. Oktober Hallo @Neo, vor 7 Stunden schrieb Neo: Es gibt lediglich einen kleinen Anzeigeunterschied im Protokoll, je nachdem wo error aufgerufen wurde, ob im Hauptereignis oder in einer Unterroutine. Ich kann die Anzeige gern angleichen. ja, das wäre sinnvoll. Denn genau dieser Unterschied im Protokoll hat mich irritiert. Danke für die Erklärung (auch an @Phrontistes). Viele Grüße BahnLand Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Phrontistes Geschrieben 20. Oktober Autor Teilen Geschrieben 20. Oktober Hallo @Neo, vor 43 Minuten schrieb BahnLand: ja, das wäre sinnvoll Ich weiß nicht, wie Du genau angleichen willst, aber es wäre schon sinnvoll, wenn man weiterhin mitbekommt, dass man verbotenerweise in einem benutzerdefinierten Ereignis error aufgerufen hat. Beste Grüße Phrontistes Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Neo Geschrieben 20. Oktober Teilen Geschrieben 20. Oktober vor einer Stunde schrieb Phrontistes: dass man verbotenerweise in einem benutzerdefinierten Ereignis error aufgerufen hat. Was meinst du damit, es ist doch nicht verboten, error in einem benutzerdefinierten Ereignis aufzurufen? Du kannst an jeder Stelle error oder print aufrufen. Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Phrontistes Geschrieben 20. Oktober Autor Teilen Geschrieben 20. Oktober Hallo @Neo, ich glaube jetzt verstehe ich Dich erst: Der "Skriptfehler" ist gar keiner und Du willst diese (fehlerhafte ) Angabe rausnehmen und stattdessen schreiben, was in error("xx") steht, also xx wie sonst auch? Das ist natürlich gut. Beste Grüße Phrontistes Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Neo Geschrieben 21. Oktober Teilen Geschrieben 21. Oktober Technisch ist jeder Aufruf von "error" ein Skriptfehler. Das Wort Fehler wird in diesem Zusammenhang aber gern falsch interpretiert. Es handelt sich nicht um einen Programmierfehler, sondern um ein explizites Stoppen des Skriptes durch Aufruf der Funktion "error" (= "Fehler"). Für gewöhnlich wird die Funktion vom Nutzer aufgerufen, um einen Fehlerzustand zu signalisieren. Es geht hier am Ende also nur um das Wording. Viele Grüße, Neo Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Phrontistes Geschrieben 21. Oktober Autor Teilen Geschrieben 21. Oktober Klar, aber es gibt ja auch noch die "echten" (selbst verschuldeten) Skriptfehler wenn man z.B. die Syntax nicht beachtet oder sonst etwas unerlaubtes tut und daran dachte ich als ich meinte, es sei verboten einen error in einem benutzerdefinierten Ereignis aufzurufen. Verwirrend für mich (und für @BahnLand) war nicht der error an sich, sondern die Meldung "Script error ...". Das steht da sonst ja nicht, wenn man einen error bewusst auslöst. In der Tat geht es nur um das Wording. Du darfst nicht vergessen, dass auch der programmiererfahrende User nicht wissen kann, wo und wie genau Du Lua kastriert hast. Vielen Dank für die Mühe, die Du Dir hier machst und für Deine Geduld. Beste Grüße Phrontistes Link zu diesem Kommentar Auf anderen Seiten teilen More sharing options...
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren
Du musst ein Benutzerkonto besitzen, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen.
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden