Handling von Meldungen

Merk dir doch wer die Meldung ausgelöst hat, statt wieviele Auslöser es 
gab.
Ordne einfach einzelne Bits in deiner Variable einzelnen Auslösern zu.
Dann hast du kein Problem mit Doppelmeldungen und kannst jederzeit 
Feststellen woher die Meldung kommt.
Du musst dann nur bei der Anzeige selber zählen (wenn die Anzeigegrenze 
größer als 1 ist).

Ich weiß nicht, ob es in dieser Sprache auch die Select-Käse-Möglichkeit 
gibt. Falls ja, könntest Du sagen:

Falls das und das oder das passiert ist, bringe die Meldung:
"Wenn Du noch einmal diese Taste drückst, sage ich es Deiner Mutter!"
Falls das und das und das und das passiert ist, bringe die 
Meldung:
"So ein Haufen Mist auf einaml darf nicht passieren!"

End Falls

Print "MfG Paul"

Lars Heitkamp schrieb:
> Dirk D. schrieb:
>> Merk dir doch wer die Meldung ausgelöst hat, [...]
>
> Das Problem bei dieser Idee ist, dass ich mir für jede Meldung merken
> muss, welches Bit für welchen Auslöser steht. Verschiedene Meldungen
> hängen ja von unterschiedlichen Auslösern ab, welche sich nicht
> notwendigerweise überschneiden. Je größer das Projekt wird (was es mal
> werden soll), desto mehr Arbeit hätte ich dann diese Zuordnung zu
> pflegen.

Ist das den wirklich nen Problem? Ich stell mir das so vor:
du nimmst für jede meldung eine Variable, wenn du Speicher Sparen musst 
ist die eben grade so groß wie du Auslöser für die Meldungen hast.
Sagen wir die Meldung ist "Du solltest Lüften"
Dafür gibt es die Gründe:
 - CO2 Gehalt in der Luft zu hoch
 - Luft zu Feucht
 - Es stinkt
 - seid mehr als 24h nicht gelüftet

Dafür brauchst du 4 bit, nimmst als 8.

dann definierst du dir 4 Platzhalter, z.b.
#define MSG_VENTILATION_REASON_CO2 1
#define MSG_VENTILATION_REASON_HUMID 2
#define MSG_VENTILATION_REASON_STINK 4
#define MSG_VENTILATION_REASON_TIME 8

wenn du deiner variable (needsVentilation) einen grund hinzufögen willst 
machst du das mit

needsVentilation=needsVentilation | MSG_VENTILATION_REASON_HUMID

den grund zurückziehen kannst du mit
needsVentilation=needsVentilation & ~MSG_VENTILATION_REASON_HUMID

einzelne Gründe abfragen mit doesItStink=meedsVentilation & 
MSG_VENTILATION_REASON_STINK
abfragen ob überhaupt gelüftet werden muss einfach indem du 
needsVentilation auf > 0 prüfst.

Die Zuordnumg musst du ja nur einmal Pflegen, und wenn du den Grund für 
eine Meldung nicht wissen musst brauch ja auch nur das Modul das den 
Grund steuert darüber bescheid wissen.
du musst also nur händisch, oder mit nen bisschen Magie zur build-time 
2er Potenzen eindeutig an die gründe übergeben.

... Oder stehe ich grade auf dem schlauch?

Dirk D. schrieb:
> ... Oder stehe ich grade auf dem schlauch?

Nö, klingt soweit sinnvoll. Auf einem Mikrocontroller mit knappem RAM 
würde ich auch Diagnose-Bits nehmen und die so verodern.

Auf einem PC, der sowieso genug Speicher hat, kann man sich das 
Bitgepfriemel im Prinzip auch sparen. (wir sind hier bei 
PC-Programmierung oder?) Man legt einfach so viele Variablen an wie man 
braucht. So ungefähr kann man das auch machen (Pseudo-Code):

1

Ursache_1_aktiv = Sensor_hat_ausgeloest();

2

Ursache_2_aktiv = Letztes_Lueften_zu_lange_her();

3

usw.

4

5

Diagnosemeldung_1_aktiv_wenn = Ursache_1_aktiv ||

6

                               Ursache_2_aktiv ||

7

                               Ursache_3_aktiv ||

8

                               Ursache_4_aktiv;

9

10

Diagnosemeldung_2_aktiv_wenn = Ursache_5_aktiv ||

11

                               Ursache_6_aktiv ||

12

                               Ursache_7_aktiv;

usw.

Wenn irgendeine Ursache vorliegt, wird die Diagnosemeldung somit auf 
logisch TRUE gesetzt. Wenn keine Ursache vorliegt, wird sie auf logisch 
FALSE gesetzt. Et voilà.

Man kann gerne alle Diagnosemeldungen in einer Funktion bzw. in einem 
Modul kapseln, welches man entsprechend benennt. Zum Beispiel 
diagnostic_messages.c/.h oder void set_diagnostic_messages(). Dann geht 
einem auch gewiss nicht die Übersicht verloren. Denn was sonst sollte 
hier wohl drinstecken? ;-)

Wenn es wirklich arg viele Diagnosemeldunge sein sollten, kann man diese 
ja noch weiter unterteilen. Zum Beispiel je nach Subsystem welches 
betroffen ist.