BEDINGTE Freigabe der macOS Version Sequoia für tomedo® Alle Hinweise und Informationen finden Sie unter folgendem Link.
Hinweis: Zukünftige iOS tomedo Updates werden nur noch auf Geräten mit iOS 16 oder höher verfügbar sein.

Fieses Spezialproblem im Rahmen von Aktionsketten und Marker-Abfragen: 

Mittels $[istMarkerGesetzt Marker]$ kann man ja sehr schön den Zustand von Markern abfragen, um damit dann weitere Abläufe zu steuern. Da eröffnen sich tolle Möglichkeiten der Automatisierung. 

Überraschenderweise funktioniert dies nicht innerhalb von Aktionsketten, wenn diese in Serie abgearbeitet werden sollen.

So löst die AK-Bedingung     $[istMarkerGesetzt Asthma]$      ist     1     bei gesetztem Marker als alleinige Aktionskettenbedingung in einer einzelnen AK aus und funktioniert dort normal:

AK-Bedingung 2-Hauptdiagnose-Asthma?

Wenn man exakt dieselbe AK-Bedingung innerhalb einer AK mit mehreren, nacheinander laufenden AK einsetzt, löst sie nicht aus. 

Es scheint ein Problem beim Auflösen des Begriffs istMarkerGesetzt zu geben, wenn mehrere AK-Bedingungen/AK in Serie/Reihe abgearbeitet werden müssen. 

Vielen Dank an Christian Klaproth für die Hilfe beim Finden dieses Fehlers.

Gefragt in Bug von (7.7k Punkte)
0 Punkte
Mir fällt grad kein Grund ein, warum das Kommando istMarkerGesetzt innerhalb einer AKBedinung anders aufglöst werden sollte.
Können Sie mal bitte unter
Hilfe -> Logs -> LogLevels Feinschaltung
das LogLevel
LogLevelBriefkommandos
aktivieren und schauen, was da ersetzt wird? Evtl. hilft auch
LogLevelAktionsKettenBedingung
um zu sehen, wann welche Bedingung aufgerufen wird.

Vielen Dank für den Hinweis, nochmal in das Log zu schauen, das hat die Lösung gebracht: 

2025-01-22 14:59:20.664 ZSBriefBasicCommand.m:448[lvl=171] Ersetze Platzhalter mit Argumenten
$[istMarkerGesetzt Asthma]$ --> '1'
2025-01-22 14:59:20.664 GuiActionCondition.m:208[lvl=94] 
evaluiere:  Prüfung-ob-Marker-Asthma-gesetzt
 -> "$[istMarkerGesetzt Asthma]$ " == "1" 
 => "$[istMarkerGesetzt Asthma]$ " == "1" 
 => "1 " == "1
 ==> nope

Da erst fällt dann auf, dass in der AK-Bedingung hinter dem Ausdruck $[istMarkerGesetzt Asthma]$ noch ein Leerzeichen versteckt ist. surprise

Das erkennt man nur im log durch den Vergleich von "1 " versus "1". 

Das ist ja eine ganz miese Falle. Könnte man die Leerzeichen im AK-Bedingungs-Feld irgendwie sichtbar machen? Oder einen Hinweis / Tooltip, dass man auf Leerzeichen am Ende eines Ausdrucks an dieser Stelle achtet. Ich vermute, diesen Fehler kriegt man leicht mal hin. Extrem schwer zu debuggen, wenn man nicht darauf gestoßen wird.

1 Antwort

Beste Antwort
Kein Bug, Problem gelöst. Vielen Dank, Herr Bürger.
Beantwortet von (7.7k Punkte)
ausgewählt vor von
0 Punkte
18,685 Beiträge
26,998 Antworten
48,495 Kommentare
29,900 Nutzer