Wenn ich im GUI einen Timer Event für eine (Float/Integer) Variable anlege (rechte Maustaste etc.) und bei der Aktion „Variable ändern“ auswähle, „Vorlage“ mit 10 Multiplizieren, bekomme ich bei jeder Ausführung die Fehlermeldung
„Undefined Variable: IPS_VALUE in D:\IPS- on Line 1“
Funktioniert bei mir. Kannst Du mal Die genauen Schritte beschreiben?
BTW. Wenn man ein Ereignis bei „Variableänderung“ hinzufügt und als Vorlage mit 10 multiplizieren angibt, sollte dies dann nicht nur 1 x passieren? Es kommt dann zu einer Kettenreaktion.
Sinnhaftigkeit hin oder her, die habe ich gar nicht geprüft sondern bin an einer ganz anderen Baustelle: der Dokumentation.
Und da ich alle möglichen Fälle abfangen muss, musste ich alle möglichen Konstellationen ausprobieren. Da bin ich drüber gestolpert.
Eigentlich sollte die GUI „sinnlose“ Dinge gar nicht zulassen. Ich habe da ne Liste von „Blödsinn“ bzw, Ungereimtheiten erstellt, wollte ich gesammelt zur Verfügung stellen.
Z.B. geht auch, „am 50. Tag“ auszuwählen, wenn „Monatlich“ als Hauptintervall ausgewählt ist. Das ist ebenso Schwachsinn, oder?
Warum sollte es für diese Werte ein Maximum geben? Der 35. Tag im Monat existiert nicht und braucht daher eine Sonderregelung, übrigens die einzige für den Bereich Events, aber alle 224234 Stunden kannst Du gerne etwas machen ;).
Die 57. Woche im Jahr bietet das Event-System gar nicht an, sondern nur alle 57 Wochen, was frei von Jahren ist. Den Sonderfall gibt es nur in der Form Am X. Tag alle Y Monate.
Ich habe mir die Mühe gemacht die irrsinnigen Timer, die man erstellen könnte, entsprechend der dann ausgeführten Funktion in der Dokumentation nachzupflegen.
Spitzfindigkeiten:
(Monatlich) Bei der Variante „Am X. Tag alle Y Monate“ bedeutet X >= 31, dass der letzte Tag im Monat gewählt wird.
(Monatlich) Bei der Variante „Am X. Wochentag alle Y Monate“ darf X nur die Werte 1-4 enthalten. Auch wenn es in manchen Monaten z.B. den 5. Freitag gibt, so wird dieser Spezialfall nicht unterstützt
(Jährlich) Bei der Variante „Am X. Monat“ wird ein Timer nur ausgeführt, wenn X ein gültiger Tag in diesem Monat ist, andernfalls wird der Timer nicht ausgeführt. Der Spezialfall des 29. Februars wird nicht unterstützt.
Ich denke, dass jemand, der IPS wirklich ganz begreifen will, da einfach drüber stolpert und dass das mit Spitzfindigkeit nix zu tun hat.
Wie schon oben gesagt: Bei mir ist’s, weil ich gerade Doku-Scripte schreibe. Und da muss ich halt aufpassen, dass mein Doku-Script in einem Spezialfall nicht aussteigt oder Unsinn produziert. Also muss ich alle Eventualitäten einstellen und meine Scripte testen.
Der sauberere Weg wäre m.E., dass die GUI und den Funktionen solches schon abgefangen, damit (auch versehentlich, das soll’s ja geben!) solcherlei „unzulässige“ Werte erst gar nicht entstehen.
Ihr habt das jetzt abgefangen, ist auch ein Weg.
Gibt es Warnings im LOG, damit ein Benutzer den „Fehler“ erkennen kann?
Sei mir bitte nicht böse, du hast sicherlich Gründe, jede kleinste Funktion bis ins Detail nachzustellen, zu testen, zu dokumentieren, usw. Ich will auch nicht wieder eine Grundsatzdiskussion entfachen, ob eine Software für xxx € das nun können muss oder nicht. Aber auf diese Weise bringt man jeden Softwareentwickler zum Verzweifeln … es wird immer irgendwas an irgendeiner Stelle einer Software geben, die vom UI nicht abgefangen wurde oder nur mit großem Aufwand abgefangen werden kann. Die Entwickler unter euch werden mir da zustimmen.
Ich könnte jetzt mit unendlich vielen Beispielen kommen, dass z.B. in Excel bis vor kurzem „nur“ 32768 Zeilen möglich waren. Es gibt sicherlich immer User, die mehr brauchen … bewegen sich dann aber in der Anzahl < 1%. Oder wenn ich bei einem Brief in Word die Enter-Taste nicht benutze, sieht dieser halt sch… aus, weil keine Absätze drin stehen. Das muss ich mit meinem gesunden Menschenverstand ausgleichen.
Genau so ist das, wenn ich den 32. Januar eingebe. Klar kann man das abfangen, aber ich glaube, es gibt in IPS wichtigeres Entwicklungspotenzial. Mit diesen Sachen bindest du die Entwickler an Prozesse, die für 99,5 % der IPS-User uninteressant oder unwichtig sind. Es gab seinerzeit Windows-Versionen, wo ich eine IP-Adresse 300.100.0.400 eingeben konnte und er hat nicht gemeckert. Es hat einfach nicht funktioniert.
Eine Software vollkommen „Idiotensicher“ zu machen, würde eine mehrstufige Qualitätssicherung und ausgiebige Tests nach sich ziehen, welches nur mit einer vielfachen multiplikation von Programmieren und Testern machbar wäre … das ginge zunächst zu Lasten des Preises und natürlich auch zu Lasten von Innovationen und Update-Zyklen …
Um - wie gesagt - keine Grundsatzdiskussionen zu entfachen, ist dies mein einziger Kommentar zu diesem Thread …
Ich kann mich meinem Vorredner nur Anschliessen. Irgendwo ist hier Grenze zwischen theoretischem Anspruch und praktischer Realisierbarkeit überschritten. Wenn jemand mutwillig oder unbewußt Müll eingibt bekommt er genau das, was er erwarten kann: nichts oder auch nur Müll. Wer all die schönen Muster aus der Software-Theorie umsetzen möchte, kann das gerne in einem Diplom-Thema verwirklichen. In der Praxis ist die konsequente Umsetzung dieser Methoden aber i.d.R. unwirtschaftlich und unproduktiv, d.h. es muss immer einen Kompromiss zwischen Aufwand (Kapazität/Geld/Zeit) und Ergebnis geben.
Tommi
Ich bin hier keinem Gram, der seine Meinung kundtut …
Und: Hmmm. Ja, kann man so sehen.
Nun war Dein Beitrag halt der erste zu einer Grundsatzdiskussion. Da hilft auch der Satz nichts „ich will nicht …“. Und dann muss man auch antworten dürfen …
Da „die Softwareentwickler unter Euch“ angesprochen sind (ich habe ziemlich viele Jahre eine Software-Company aufgebaut, börsengelistet und weltweit mit vielen Millionen von Nutzern, mission-critical im E-Mail Bereich. Wir wären mit einem „lass es gut sein“-Approach sicher niemals zu einem führenden Softwarehaus in unserer Branche geworden):
Ein dokumentiertes LIMIT (Excel Zeilen) mit einem GUI „Fehler“ zu vergleichen ist Äpfel mit Tannenzapfen. Das IP-Beispiel ist ok. Ich habe keine Probleme damit, wenn ein Produkt Limits hat (Excel) wenn diese offen dargelegt werden. Nun kannman eine „nicht-ganz-ordentliche“ Oberfläche natürlich auch als „Limit“ verpacken.
Die Diskussion über „was muss eine Oberfläche leisten“ muss sich halt m.E. u.a. an der ausgerufenen Zielgruppe orientieren.
Wenn ich an anderer Stelle klar sage „Endkunde“, dann muss ich an dieser fraglichen Stelle die „Blöden-Benutzer“-Fehler abfangen.
Und zwar NICHT primär wegen dem Mist, der Raus kommt und vielleicht falsch funktioniert, sondern weil mich solche Fehler später einen Heidenaufwand an Support kosten werden (wenn ich denn erfolgreich in die Masse gegangen bin).
Nicht nur beim Hersteller sondern ggf. auch bei den Partnern (Elektroinstallateur etc. - Benutzer KÖNNEN nicht die Finger weg lassen).
Ich sehe ein, dass diese Diskussion an dieser Stelle hier nicht geführt werden kann, das ist eine Frage der Positionierung und damit Sache des Herstellers intern.