[EibStudio] Featurewunsch

[Uwe!]

Hallo,

ich hab mein Programm in mehrere Abschnitte thematisch gegliedert, also z. B. Heizung, Fenster, Wetter etc.
Jeder Block hat zu Beginn eine Sprungmarke a la "//# Heizung".
Allerdings hab ich in den Blöcken jeweils mit #addto [EibPC / Webserver / Makros] alles zugehörige untereinander gepackt. Das funktioniert sehr gut und gefällt mir besser als je ein großer Block für [EibPC / Webserver / Makros].
Zusammen mit meinen Sprungmarken wird es dann aber bei der Auswahl der Sprungziele unübersichtlich, da ich dann sowas angezeigt bekomme:

image.png


Für mich wäre es daher praktisch, wenn man einstellen könnte, ob [EibPC / Webserver / Makros] als Sprungziele angezeigt werden.
Evtl. bin ich da aber ein Einzelschicksal.

Danke
Uwe

[foobar0815]

Hi,

mein Vorschlag wäre, einzelne Programme zu nutzen statt das große monolithische Programm mit Sprungmarken zu unterteilen. Dann passen auch die automatischen Sprungmarken.

Was spricht da dagegen, außer Gewohnheit ?

[klaus_kraemer]

Da werde ich hellhörig. Ich ging bisher davon aus, es gibt ein einziges Hauptprogramm und der Rest ergibt sich aus eingebundenen Makros. Lieg' ich falsch?

Mir geht immer noch das alte

#include Dateipfad

ab, mit dem Codedateien in die Hauptstruktur "inkludiert" werden konnten. Das hatte auch den großen Vorteil, mehrere zusammenspielende Codeabschnitte gleichzeitig in Notepad++ öffnen zu können und (bei geeigneten Monitoren) einen super Überblick zu haben, anstatt immer einen Codeblock wieder überblenden zu müssen, wie es im EibStudio ist.

[foobar0815]

Im Experten kannst du einzelne Programme (eigentlich Programmabschnitte) anlegen und mittlerweile (glaube >5.500) auch Unterverzeichnisse erstellen.

image.png

[Uwe!]

Im Experten kannst du einzelne Programme (eigentlich Programmabschnitte) anlegen und mittlerweile (glaube >5.500) auch Unterverzeichnisse erstellen.

hm. Das muss ich mir mal anschauen. Könnte eine Lösung sein.

Was spricht da dagegen, außer Gewohnheit

ggf. gar nichts, außer dass man sich neue Funktionen manchmal selbst erarbeiten muss und daher aus Unwissenheit nicht nutzt.

Die Reihenfolge des kompilierten Codes ist dann in der Reihenfolge wie die Programme im EibStudio aufgelsietet sind?

[foobar0815]

Genau

[Tokamak]

Die Reihenfolge des kompilierten Codes ist dann in der Reihenfolge wie die Programme im EibStudio aufgelsietet sind?

Spielt keine Rolle, das System ist Ereignis-gesteuert

[Uwe!]

Spielt keine Rolle, das System ist Ereignis-gesteuert

ja, aber Reihenfolge vom Code hat trotzdem Auswirkungen

[Tokamak]

Die Reihenfolge der Programme sollte keine Auswirkungen haben.
Und selbst wenn, sollte man darauf nicht bauen.

[klaus_kraemer]

Die Reihenfolge der Programme sollte keine Auswirkungen haben.
Und selbst wenn, sollte man darauf nicht bauen.

Ich vermute mal, dass die Reihenfolge, wie z.B. die Abfolge der Abarbeitung der #addto[Webserver】durchaus ihre Auswirkung auf die Visu haben werden.

[Uwe!]

ich kann ein aktuelles Beispiel geben, da ich meinen Code aktuell gerade überarbeite und dabei teilweise auch neu sortiere. Dabei ist mir ein Fehler passiert. Folgender Code liefert nicht, was ich wollte:

if “Status-9/2/1” != StatusAlt and “Status-9/2/1” >= 10u08 then \
MailText = MailText + $Status: $ + StatusText + $<br>$ ; \
StatusAlt = “Status-9/2/1” \
endif
.
.
.
if “Status-9/2/1” == 0u08 then StatusText = $WP Aus$ endif
if “Status-9/2/1” == 16u08 then StatusText = $WP wartet - Mindeststandzeit$ endif

Wechselt 9/2/1 von 0 auf 16, wird in demselben Durchlauf zuerst die Mail-Zeile ausgeführt. StatusText steht da aber noch auf dem alten Wert „WP Aus“. Die Zeile darunter setzt den neuen Text erst danach, und für die Mail ist es dann zu spät. Statt "WP wartet - Mindeststandzeit" bekomme ich "WP Aus" gemailt.

Mit diesem Code kommt das richtige Mail an:

// zuerst den Text setzen ...
if “Status-9/2/1” == 0u08 then StatusText = $WP Aus$ endif
if “Status-9/2/1” == 16u08 then StatusText = $WP wartet - Mindeststandzeit$ endif

// ... dann verwenden
if “Status-9/2/1” != StatusAlt and “Status-9/2/1” >= 10u08 then \
MailText = MailText + $Status: $ + StatusText + $<br>$ ; \
StatusAlt = “Status-9/2/1” \
endif
​

Identischer Code, nur andere Reihenfolge.

[Tokamak]

Identischer Code, nur andere Reihenfolge.

Was aber lediglich bedeutet, dass man beide Versionen nicht machen sollte.

Formal werden, wenn ich die Doku richtig verstehe, alle if-Bedinungen zeitglich invalidiert. In welcher Reihenfolge sie dann abgearbeitet werden, ist nicht offziell dokumentiert, zumindest nicht nach meinem Kenntnisstand. Dass sie von oben nach unten abgearbeitet werden, liegt nahe, denn irgendeine Reihenfolge wird es geben. Auch die Makro-Beispiel zur Berechnung des cosh() funktoniert nur, wenn von oben nach unten gegangen wird.

Die then-Blöcke hinter den invalidierten ifs sind aber alle unabhängig voneinander. Anzunehmen, dass diese von oben nach unten abgearbeitet werden, halte ich für gewagt.
Selbst wenn es tatsächlich so ist, sollte man nicht darauf bauen. Schließlich könnte sich von Firmware zu Firmware der Scheduler ändern.

Abgesehen davon würde das ja auch gelten, wenn die then-Blöcke in verschiedenen Programmen lägen. Dann hinge die Reihenfolge, in der sie abgearbeitet werden, vom Programmnamen ab. Eine Umbenennung führt so zu einer Funktionsänderung, was man vermeiden will, wenn man ein stabiles System haben möchte.

Will man also eine Reihenfolge haben, sollte man die explizit formulieren und forcieren und nicht implizit davon ausgehen.

[EPIX]

ich verwende das System der einzelnen Programme problemlos seit Jahren...
die Definitionen sind an erster Stelle der Programme...

[foobar0815]

Die sequentialität ist schon eine Eigenschaft, auf die man sich bei bedingungslosen Funktionen verlassen kann:

x=4
x=5

ergibt für x immer 5.

Auch innerhalb eines if...then sind Zuweisungen in den allermeisten Fällen sequentiell (Ausnahme: Ausgabefunktionen die den Zustand der Variablen am Ende des If-s übernehmen).

Sich bei voneinander unabhängigen Programmteilen mit unterschiedlichen Bedingungen auf eine Reihenvolge zu verlassen, würde ich allein für ein leichteres Verständnis der Zusammenhänge nicht empfehlen. Statt dessen kannst du bei obigem Teilabschnitt auch die StatusText-Generierung direkt in das if mit reinziehen.

Wenn dein StatusAlt nur dafür da ist, eine Änderung der GA zu erkennen, kannst du auch direkt
if change("Status-9/2/1") .... machen.

[Uwe!]

Wenn dein StatusAlt nur dafür da ist, eine Änderung der GA zu erkennen, kannst du auch direkt
if change("Status-9/2/1") .... machen.

das hatte ich, gab aber Probleme. Ich muss mal suchen, ob ich noch finde, was das Problem war.