Zeitvariablen werden nicht initialisiert

Bugreports und Updatewünsche an die Firma contronics
Keine allgemeinen Fragen!

Moderator: Co-Administratoren

SpiRu
Beiträge: 74
Registriert: 18.09.2012, 23:05
Wohnort: Deutschland.Freiburg

Zeitvariablen werden nicht initialisiert

Beitrag von SpiRu » 04.10.2012, 10:51

Ganz schwerer Bug! Von dem ich eigentlich gar nicht glauben kann, dass der bisher noch keinem aufgefallen ist!

Ändert man im Muster-Objekt für einen Betriebsstunden-Zähler von buempi den Typ der Variablen AktuelleLaufzeit und TotalLaufzeit von Real in Zeit, werden diese nicht mehr mit den eingetragenen Startwerten initialisiert. Egal was ich dort eintrage: 00:00:00 oder "00:00:00" oder 0 oder 0,00000000. Als Variablen vom Typ Real (Zahl mit Startwert 0,000000) werden diese korrekt mit 0,0 initialisiert, wie man mit der Ablaufverfolgung nachprüfen kann. Die selben Variablen als Typ "Zeit" werden zwar auch initialisiert, aber anscheinend mit der Startzeit des Gesamtprogramms! :roll: Ich glaube kaum, dass dies ein beabsichtigtes Feature ist!

Code: Alles auswählen

** Makro im Aktor - Ausführung bei Änderung
** EinschaltZeit ist eine Variable vom Typ Zeit
** AktuelleLaufzeit und TotalLaufzeit sind Variablen vom Typ Zahl, Startwert 0,0

wenn Aktor eingeschaltet dann
   EinschaltZeit    := Zeit
sonst
   EinschaltZeit    := Zeit
   AktuelleLaufzeit := Zeit - EinschaltZeit
   TotalLaufzeit    := TotalLaufzeit + AktuelleLaufzeit
endewenn
Zuletzt geändert von SpiRu am 04.10.2012, 11:54, insgesamt 2-mal geändert.
FHZ 1000 PC, Homeputer Studio V2.0 Rel. 120301
FHT80b-Raumregler, Windows XP (SP3)

Bugs? - Das sind keine Bugs! Das sind Features!

fsommer1968
Beiträge: 230
Registriert: 16.02.2008, 17:05
Danksagung erhalten: 9 Mal

Re: Zeitvariablen werden nicht initialisiert

Beitrag von fsommer1968 » 04.10.2012, 11:03

Also....,

ich habe mir angewöhnt alle wichtigen Variablen im *Init-Script entweder mit sinnvollen Werten zu initialisieren oder per Laden() wiederherzustellen:

Code: Alles auswählen

** Zuerst alte Variablen wiederherstellen
warte ("00:00:6")
laden ("*ALL")
laden ("*ALLV")
warte ("00:00:6")

** Sinnvolle Zustände setzen
RolladenMiZu.Sema :=1

buempi
Ehrenmitglied
Beiträge: 12194
Registriert: 29.07.2006, 15:58
Wohnort: Schweiz
Danksagung erhalten: 5 Mal

Re: Zeitvariablen werden nicht initialisiert

Beitrag von buempi » 04.10.2012, 11:27

SpiRu hat geschrieben:werden diese nicht mehr mit den eingetragenen Startwerten initialisiert
... wenn man als Startwert "0,0" oder "Mist" oder "Blödsinn" reinschreibt!

Du begreifst es nicht? - Zeitvariablen sind Variablen, um Zeitpunkte im Format "dd.mm.yy hh:mm:ss" aufzunehmen und keine Real-Variablen!

Viele Grüsse
Bümpi

SpiRu
Beiträge: 74
Registriert: 18.09.2012, 23:05
Wohnort: Deutschland.Freiburg

Re: Zeitvariablen werden nicht initialisiert

Beitrag von SpiRu » 04.10.2012, 11:51

fsommer1968 hat geschrieben:ich habe mir angewöhnt alle wichtigen Variablen im *Init-Script entweder mit sinnvollen Werten zu initialisieren
Und warum verlässt Du Dich nicht auf die Vorbelegung der Objektvariablen mit einem Startwert im Objekt selbst? Weil Du auch festgestellt hast, dass dies öfter nicht so funktioniert wie es sollte?
FHZ 1000 PC, Homeputer Studio V2.0 Rel. 120301
FHT80b-Raumregler, Windows XP (SP3)

Bugs? - Das sind keine Bugs! Das sind Features!

fsommer1968
Beiträge: 230
Registriert: 16.02.2008, 17:05
Danksagung erhalten: 9 Mal

Re: Zeitvariablen werden nicht initialisiert

Beitrag von fsommer1968 » 04.10.2012, 12:07

Nein, weil ich alle Variablen und Objektzustände per Laden() restauriere - bei mir stehen da u.a. Werte für die aktuellen Zustände der Rolläden, und ob die Heizungsregler in "meinem" Abwesenheitsmodus laufen, drin. Anschließend werden wichtige aber nicht temporäre Variablen (z.B. Semaphoren) mit sinnvollen Werten vorbelegt. Temporäre Variablen werden natürlich im entsprechenden Objekt übers GUI oder im Makro initialisiert, und das funktioniert auch - Dein "Problem" mit der Variablen vom Typ Zeit hat Buempi ja schon kommentiert. Eine Variable vom Typ Zeit habe ich auf die schnelle bei mir nicht gefunden- kann deshalb nicht sagen ob dort die Vorbelegung nicht funktioniert. Aber bei allen anderen Vorbelegungen habe ich kein Problem gefunden.
Ich habs lieber zentral an einer Stelle als verteilt übers ganze Projekt. Deswegen nutze ich auch nicht die Anwesenheitssimulation.

SpiRu
Beiträge: 74
Registriert: 18.09.2012, 23:05
Wohnort: Deutschland.Freiburg

Re: Zeitvariablen werden nicht initialisiert

Beitrag von SpiRu » 04.10.2012, 12:14

buempi hat geschrieben:
SpiRu hat geschrieben:werden diese nicht mehr mit den eingetragenen Startwerten initialisiert
... wenn man als Startwert "0,0" oder "Mist" oder "Blödsinn" reinschreibt!
Und wie, bitte, können Zeitvariable vorbelegt werden?
  • Oder aus welchem obskuren Grund sollen ausgerechnet Zeitvariable nicht vorbelegt werden können?
    Und warum ist das dann nirgends kommentiert?
    Und warum macht der Compiler kommentarlos irgend welche eigenmächtigen Zuweisungen?
    Warum bemängelt er unzulässige Werte nicht?
Sag jetzt nicht, das sei ein Feature! :twisted:
FHZ 1000 PC, Homeputer Studio V2.0 Rel. 120301
FHT80b-Raumregler, Windows XP (SP3)

Bugs? - Das sind keine Bugs! Das sind Features!

SpiRu
Beiträge: 74
Registriert: 18.09.2012, 23:05
Wohnort: Deutschland.Freiburg

Re: Zeitvariablen werden nicht initialisiert

Beitrag von SpiRu » 04.10.2012, 12:56

fsommer1968 hat geschrieben:Ich habs lieber zentral an einer Stelle als verteilt übers ganze Projekt.
Genau das verstößt aber gegen die Grundregel des information hiding. In der objekt-orientierten Programmierung sollen Objektdaten möglichst nur durch das Objekt selbst (genauer gesagt Methoden des Objekts) manipuliert werden, Internas möglichst verborgen bleiben (was bei Homeputer Objekten nur bedingt möglich ist, da alle Variablen global sind). Bei typischen 1-Mann Bastler-Systemen kennt der Allein- und Chef-Programmierer alle seine Objekte auswendig. Bei größeren System ist das hingegen nicht der Fall und an zentraler Stelle in im Detail unbekannten Objekten rumzuschrauben, kann schwer zu überschauende Konsequenzen haben, bzw. erfordert vermeidbar viel Detailwissen über Internas. Deshalb sollen alle objektbezogenen Aktionen möglichst lokal im Objekt selbst abgehandelt werden. Insbesondere natürlich auch Initialisierungen.
FHZ 1000 PC, Homeputer Studio V2.0 Rel. 120301
FHT80b-Raumregler, Windows XP (SP3)

Bugs? - Das sind keine Bugs! Das sind Features!

fsommer1968
Beiträge: 230
Registriert: 16.02.2008, 17:05
Danksagung erhalten: 9 Mal

Re: Zeitvariablen werden nicht initialisiert

Beitrag von fsommer1968 » 04.10.2012, 13:17

Meine Schutzbedarffeststellung hat ergeben, daß das Risiko tolerabel ist - bei mir zumindest.- Bei Dir scheint das anders zu sein.
Leider greift das "Konzept" hier nur teilweise, weil Variablen eh im gesamten Projekt erreichbar sind. Und - man kann sich das Leben dann auch unnötig schwer machen - siehe die Diskussionen der letzten Tage.

Ich klinke mich jetzt besser auch aus. Beschaffe Dir das nächste mal die Komponenten selber, und lasse sie nicht kaufen, evtl. hast Du dann mehr Erfolg.

buempi
Ehrenmitglied
Beiträge: 12194
Registriert: 29.07.2006, 15:58
Wohnort: Schweiz
Danksagung erhalten: 5 Mal

Re: Zeitvariablen werden nicht initialisiert

Beitrag von buempi » 04.10.2012, 13:37

SpiRu hat geschrieben:Und wie, bitte, können Zeitvariable vorbelegt werden?
... du wirst es nicht glauben! - Mit einem ZEIT-Wert wie z.B. 04.10.12 13:35:59

Viele Grüsse
Bümpi

SpiRu
Beiträge: 74
Registriert: 18.09.2012, 23:05
Wohnort: Deutschland.Freiburg

Re: Zeitvariablen werden nicht initialisiert

Beitrag von SpiRu » 04.10.2012, 14:45

buempi hat geschrieben:Du begreifst es nicht? - Zeitvariablen sind Variablen, um Zeitpunkte im Format "dd.mm.yy hh:mm:ss" aufzunehmen und keine Real-Variablen!
Du begreifst es nicht!

Du hast wohl immer noch nicht verstanden, dass Zeitvariable die Zeit nicht in einem bestimmen externen Darstellungs- (und zudem von den Windows Regions- und Sprachoptionen abhängigen) Format wie "dd.mm.yy hh:mm:ss" speichern.
Mit Zeichenketten kann man nicht rechnen, mit Zeitvariablen schon:

Code: Alles auswählen

dt, Zeit1, Zeit2 [Zeit], 
ds      [Zeichen]
string1 [Zeichen] Startwert "Dies ist ein Text"
string2 [Zeichen] Startwert "dd.mm.yy hh:mm:ss"

dt:= Zeit2   - Zeit1
ds:= string2 - string1    ** bewirkt übrigens (ohne Compiler-Kommentar!) das selbe wie
ds:= string2
dt:= ist klar und ergibt je nach Kontext einen Zeitpunkt (Zeitpunkt-Zeitdauer) oder eine Zeitdauer/Zeitdifferenz (Zeitpunkt-Zeitpunkt).
Aber eine Differenz von Zeichenketten ist nicht definiert! (Hier kommt dann garantiert ein "ja, aber..." Einwand)

Zeitvariable sind definitiv (als [Zeit], [Uhr], [Datum] Type-gecastete) Real-Variable! Mit denen man auch ganz normal rechnen kann!
Und ob der Inhalt dann als Zeitdifferenz (Dauer) oder als Datum relativ zu "1899-12-30 00:00:00" zu interpretieren ist, hängt vom Kontext ab.

Code: Alles auswählen

dt:= "00:00:00"
dt:= 0,0
dt:= dt + 1,5
dt:= dt + 1+"12:00:00"
erhöht dt jeweils um 1 Tag und 12 Stunden, unabhängig davon, wie der Inhalt zu interpretieren ist (Datum oder Zeitdifferenz). Die beiden verwendeten Schreibweisen für 1,5 Tage und deren Zuweisung an eine Variable vom Typ [Zeit] beweisen übrigens, dass Du mit Deiner Aussage
buempi hat geschrieben:Zeitvariablen sind ... keine Real-Variablen!
definitiv falsch liegst! Ebenso die Zuweisung des Real-Werts 0,0 an die Zeitvariable, die der Compiler nicht nur klaglos akzeptiert, sondern auch richtig übersetzt!

Allerdings kann eine Zeit-Variable nur bedingt auch als Real-Variable verwendet werden. Es funktionieren nur Zuweisung, Addition und Subtraktion. Multiplikation etc. wie mit "echten" Real-Werten geht nicht! Was einem der tolle "Compiler" aber nicht sagt, sondern einfach kommentarlos an dieser Stelle keinen Code erzeugt - wie auch an zahlreichen anderen Stellen. Jedesmal kommentarlos! Lauter üble Bugs!

Es würde zwar wenig Sinn machen, ein Datum wie 2012-10-22 mit 365,0 zu multiplizieren, eine tägliche Laufzeit aber schon, um daraus z.B. die Jahreslaufzeit zu errechnen. Die überflüssigen Einschränkungen bei den Operationen sind daher nicht nur völlig unbegründet, sonder auch kontraproduktiv!
Zuletzt geändert von SpiRu am 04.10.2012, 19:49, insgesamt 3-mal geändert.
FHZ 1000 PC, Homeputer Studio V2.0 Rel. 120301
FHT80b-Raumregler, Windows XP (SP3)

Bugs? - Das sind keine Bugs! Das sind Features!

Antworten

Zurück zu „homeputer Studio / Standard: Bugs & Updatewünsche“