BetterContacts: Funktionsparameter in Kontaktpunkten, Nachfolger meiner "Codezeile"

Ich denke, meine "Codezeile" dürfte fast jeder kennen. Falls nicht, hier ein Link zum Thema von damals (schon fast sechs Jahre alt ). Damit ist es möglich, in Kontaktpunkten nicht nur einen Lua-Funktionsnamen einzutragen, sondern dieser Funktion auch Parameter mitzugeben.

Diese Codezeile hat nur einen Schönheitsfehler: Der Zugname wird als globale Variable gesetzt, und steht damit im gesamten Skript zur Verfügung, auch ohne ihn als Funktionsparameter explizit mitgegeben zu haben. So eine globale Variable mag zwar auf den ersten Blick praktisch erscheinen, kann dafür aber die Fehlersuche erheblich erschweren. Deshalb mag ich keine globalen Variablen.

Da im Forum immer wieder Beispiele mit der "falschen" Verwendung des Zugnamens auftauchten, probierte ich letztes Jahr etwas herum, wie ich die globale Variable loswerden könnte - und war erfolgreich. Anstatt einer weiteren Variante der Codezeile entschied ich mich diesmal für ein vollwertiges Lua-Modul, das per Modellinstaller installiert und anschließend mit require eingebunden wird.

Die Vorteile von so einem Modul sind unter anderem eine Zentralisierung der Funktionalität (sodass eventuell notwendige Änderungen nur an einer Stelle erfolgen müssen statt verstreut über viele Dateien bzw. alle Anlagen) und vor allem mehr Platz. So konnte ich noch einige nützliche Dinge einbauen wie Konfigurationsmöglichkeiten (dadurch lassen sich alle bisherigen Varianten durch das neue Modul ersetzen) und Hilfen zur Fehlersuche und -vermeidung. Im Endeffekt ist das Modul jetzt 122 Zeilen bzw. 4366 Zeichen lang geworden. Zum Vergleich: Meine Codezeile bestand (je nach Variante) aus nur 142 bis 206 Zeichen.

"Codezeile", "Codeschnipsel", "KP-Parameter", "Funktionsargumente in Kontaktpunkten" - die bisherige Lösung hatte viele Namen und keiner davon passte so richtig. Ein einheitlicher und eindeutiger Name ist aber wichtig, wenn man über etwas reden oder danach suchen will. Und speziell zum Einbinden mittels require braucht ein Modul natürlich auch einen eindeutigen Namen. Nach einigem Brainstorming entschied ich mich für "BetterContacts" - weil dadurch die Kontakte "besser" werden.

Der eigentliche Code war recht schnell geschrieben, aber ohne Doku ist so ein Modul recht nutzlos. Deshalb schlummerte BetterContacts für über ein Jahr auf meiner Festplatte (und auf GitHub), bis ich in den vergangenen Tagen endlich mal Zeit gefunden habe zum Dokuschreiben. So kann ich jetzt endlich verkünden:

BetterContacts ist da!

BetterContacts funktioniert fast genauso wie meine Codezeile, ist aber noch ein Stückchen besser.

Der Umstieg sollte keine Probleme bereiten.

Den Download sowie die ausführliche Dokumentation (inklusive Schnellstart- und Umstiegsanleitung) findet ihr unter obigem Link auf meiner Homepage.

Falls es Probleme (ich hoffe nicht) oder sonstige Fragen gibt, dürft ihr euch natürlich wie immer gerne melden.

Viele Grüße

Benny

PS: Noch eine Bitte an alle fleißigen Helferlein und Tipp-Geber hier im Forum: Ich erwarte natürlich nicht, dass ihr jetzt alle euren alten Beispiele anpasst. Ich würde mich aber freuen, wenn eure zukünftigen Hilfestellungen nicht mehr die nun veraltete Codezeile nutzen, sondern BetterContacts. Dankeschön

Hallo Michael,

wie eep_gogo (RG3) schon gesagt hast, hast du vermutlich beim Einfügen der print-Zeile einen Fehler gemacht.

Die letzte Zeile in meinem Skript lautet return betterContacts. Lua erwartet, dass nach einem return nichts mehr kommt. Wenn du da jetzt noch ein print dahintergeschrieben hast, kommt es zur genannten Fehlermeldung.

Wenn du unbedingt ein print einbauen willst, dann muss es vor das return.

Aber eigentlich sollte es gar nicht nötig sein: Wenn beim Einbinden etwas nicht klappt, kommt eigentlich immer eine Fehlermeldung. Wenn keine Fehlermeldung kommt, kannst du also erstmal davon ausgehen, dass es geklappt hat (solange du nicht explizit das Gegenteil feststellst).

Ich empfehle generell, an fremden Modulen keine eigenen Änderungen vorzunehmen. Es besteht sonst immer die Gefahr, dass bei einem Update des Moduls deine Änderungen überschrieben werden.

Viele Grüße

Benny

Raumpatrouille wrote:

Das sieht so aus, als würde Parrys Toolbox von Zugname als globale Variable Gebrauch machen. Du kannst diesen (von mir ungeliebten) Modus auch in BetterContacts aktivieren (siehe Doku auf meiner Homepage, Stichwort deprecatedUseGlobal).

Oder du lässt die Toolbox unverändert und wartest darauf, dass Parry seine Toolbox anpasst (wobei das wohl auch nichts an der Verwendung der globalen Variable ändert; oder wenn doch, müsstest du alle Kontaktpunkte anfassen, um den Zugnamen explizit mitzugeben).

Viele Grüße

Benny

Hallo Dieter,

wenn ich sage, dass Zugname global ist, dann meine ich das auch so. Die Variable steht während des KP-Aufrufs (also während das, was im Kontaktpunkt drinsteht, von Lua abgearbeitet wird) global im gesamten Skript zur Verfügung. Wenn du währenddessen print(Zugname) machst, wirst du den Zugnamen auch sehen.

Nach dem KP-Aufruf wird (durch die von dir zitierte Zeile, wobei der Kommentar nicht von mir stammt) die globale Variable Zugname unmittelbar wieder zurückgesetzt auf das, was vorher drinstand, um ungewollte Effekte möglichst klein zu halten. Wenn die Variable vorher "nicht definiert" (=nil) war, wird sie das hinterher auch wieder sein.

Ich will keine Angst machen vor globalen Variablen. Aber ich persönlich mag sie nicht, und habe das meiner Meinung nach auch begründet. Wenn die Begründung nicht ausreichend war, kann ich bei Bedarf (und wenn ich Zeit finde) noch mehr dazu schreiben.

Ich verlange nicht, dass du meine Meinung bezüglich globaler Variablen teilst. Ich denke, es ist offensichtlich, dass wir da unterschiedlicher Meinung sind.

Und wenn du irgendeinen Grund hast, vor dem Einsatz von BetterContacts zu warnen, darfst du das auch gerne machen. Dann wäre es aber schön, wenn du den Grund auch nennen würdest. So eine unbegründete Warnung finde ich doch etwas befremdlich.

Parry36 wrote:

Wer weiterhin mein rus Paket nutzen möchte, sollte das Modul nicht in seine Scripte einbinden.

Das akzeptiere ich so erstmal. Wobei ich mir (bis zum "Beweis" des Gegenteils) sehr sicher bin, dass bei entsprechender Konfiguration (Stichwort deprecatedUseGlobal) auch mit BetterContacts alles so funktioniert wie vorher.

Viele Grüße

Benny

Hallo Jörg,

meiner Meinung nach sollte es nicht nötig sein, jedesmal die Versionsnummer auszugeben. Da alle deine Anlagen auf die gleiche Datei (BetterContacts_BH2.lua) zugreifen, laufen auch alle Anlagen mit der gleichen Version. Wenn du von einem Update erfährst, kannst du diese eine Datei einmal ersetzen, danach ist das Update erledigt und du musst dich nicht mehr drum kümmern.

Darüberhinaus kannst du auch "von außen" (also aus dem Anlagenskript heraus) auf die Versionsnummer zugreifen:

Der erneute require-Aufruf tut nicht weh, da sich Lua das "Ergebnis" gemerkt hat und somit der Code innerhalb der eingebundenen Datei nicht erneut ausgeführt wird.

Wenn du trotzdem an deinem Wunsch festhältst und auch andere dies wollen, könnte ich eine weitere Option namens printVersionInfo hinzufügen, die dann die gewünschte Info ausgibt.

Eine standardmäßige Ausgabe will ich nicht, weil ich gerne selbst bestimme, was im Ereignisfenster steht (am besten möglichst wenig).

Hallo Dieter,

dann war das wohl ein Missverständnis. Ich hatte deine Aussage so verstanden, dass du generell von der Benutzung von BetterContacts abrätst. Dass du nicht willst, dass in deinen Skripten "rumgefummelt" wird, kann ich voll und ganz nachvollziehen. Vielleicht liegt das ganze Missverständnis auch nur an einem kleinen Tippfehler, und statt...

Parry36 wrote:

Ich kann nur ausdrücklich davor warnen, Benny´s neue Mammut Konstruktion in seine Scripte einzubinden.

meintest du "... meine Scripte"?

Parry36 wrote:

Mir entzieht sich das Verständnis, das bisherige kleine Script, mit gerade mal 15 Zeilen, ein aufgeblähtes Script mit sagenhaften über 100 Zeilen gegenüber zu stellen.

Nunja, man könnte den 15 Zeilen* auch die eine require-Zeile gegenüberstellen. Du sollst ja nicht das gesamte BetterContacts in dein Anlagenskript oder rus-Pakt reinkopieren.

* Ich weiß nicht mal genau, wo du deine 15 Zeilen überhaupt her hast. Ich habe auf meiner Homepage einen Einzeiler bereitgestellt.

Die ganze "Aufblähung" kommt übrigens hauptsächlich durch die ganzen neuen Komfort- und Sicherheitsmerkmale zustande.

Dein(?) Codebeispiel ist die Essenz von dem, was meine bisherige Codezeile und jetzt BetterContacts macht. Nur halt ohne alles drumherum.

Parry36 wrote:

Da frage ich mich, warum der ganze Zauber?

Ich meine, die Gründe habe ich im Ausgangsbeitrag genannt.

Viele Grüße

Benny

Nachtrag, weil erst nach dem Abschicken gesehen:

moebelplus wrote:

aber warum kann [...] nicht Beide sich zusammensetzen und gemeinsam ein Modul konstruieren.

Ich wüsste nicht, was es "gemeinsam zu konstrieren" gäbe. Mein Modul ist fertig.

Außerdem sind unsere Vorstellungen von verschiedenen Dingen doch recht unterschiedlich. Aber an mir soll es nicht scheitern.