MQL5 v1.50: Knopf-Flackern - der Chart trug den Indikator DREIMAL

User: "beim Wechseln der Zeit blinken die Knoepfe kurz gross auf und sind dann
wieder klein". Nicht die Groesse war das Problem.

BELEG aus dem Terminal-Journal: je Zeitebenen-Wechsel DREI identische Zeilen
"custom indicator SR_Levels loaded succesfully" im selben Zehntelsekunden-
Fenster. Auf dem Chart lagen drei Instanzen. Jede hat ihren EIGENEN
gespeicherten Eingabesatz - die vor v1.49 angehaengten trugen noch 66/17/8,
die neue 132/34/16. Alle drei schrieben im Sekundentakt auf dieselben
Objektnamen, also wechselte die Groesse permanent hin und her.

Doppelte Instanzen sind von aussen unsichtbar, solange nichts schreibend
kollidiert - sie kosteten hier zusaetzlich das Dreifache an CSV-Lesevorgaengen
und Objekt-Auf-/Abbau je Sekunde. Merksatz: bei unerklaerlichem
Chart-Verhalten ZUERST die Ladezeilen im Journal zaehlen.

FIX 1: nur eine Instanz zeichnet die Knoepfe. Anspruch je Chart ueber eine
temporaere GlobalVariable, gesetzt mit GlobalVariableSetOnCondition - also
ATOMAR (ein Check-dann-Set haetten bei gleichzeitigem Start alle drei
gewonnen). Nicht-Inhaber steigen in BtnDraw() sofort aus und melden einmalig
im Experten-Log, dass eine zweite Instanz laeuft.
OnDeinit raeumt die Knoepfe nur noch als Inhaber weg und gibt den Anspruch
frei - sonst haette eine beendete Zweit-Instanz die Knoepfe der noch
laufenden ersten geloescht.

FIX 2: die Groesse heilt sich selbst. BtnDraw() legt einen Knopf neu an, wenn
seine gespeicherte XSIZE/YSIZE/FONTSIZE nicht mehr zum Soll passt; reines
Nachsetzen der Eigenschaften (v1.49) reichte in der Praxis nicht.

Der eigentliche Fix liegt beim Nutzer: doppelte Instanzen entfernen
(Rechtsklick > Indikatorenliste). Der Guard verhindert nur den sichtbaren
Schaden, nicht die dreifache Last.

0 errors 0 warnings, .ex5 frisch, Spiegel bitgleich.

CLAUDE.md

@@ -9661,3 +9661,46 @@ erreichbar schlägt schön, und der Normalfall ist eine Spalte.
 ✅ `0 errors, 0 warnings`, `.ex5` frisch, Spiegel bitgleich.
 ⚠ Wer noch größer will, dreht `InpBtnBreite`/`InpBtnHoehe`/`InpBtnFont` weiter —
 der Spalten-Rückfall fängt zu hohe Stapel ab.
+
+### ⚠⚠ „Knöpfe blinken kurz groß auf und sind dann wieder klein" — der Chart trug den Indikator DREIMAL (2026-08-22, v1.50)
+
+User-Meldung beim Zeitebenen-Wechsel. **Nicht die Größe war das Problem.**
+Beleg aus dem Terminal-Journal (`<terminal>/logs/20260822.log`) — je Wechsel
+**drei** identische Zeilen im selben Zehntelsekunden-Fenster:
+```
+13:19:16.071  custom indicator SR_Levels (SpotCrude,M5) loaded succesfully
+13:19:16.072  custom indicator SR_Levels (SpotCrude,M5) loaded succesfully
+13:19:16.072  custom indicator SR_Levels (SpotCrude,M5) loaded succesfully
+```
+**Auf dem Chart lagen DREI Instanzen.** Jede hat ihren **eigenen gespeicherten
+Eingabesatz**: die vor v1.49 angehängten trugen noch `66/17/8`, die neue
+`132/34/16`. Alle drei schrieben im Sekundentakt auf **dieselben** Objektnamen —
+also wechselte die Größe permanent hin und her.
+
+⚠⚠ **Das ist die Falle hinter dem Symptom: doppelte Instanzen sind von außen
+unsichtbar**, solange nichts schreibend kollidiert. Sie kosteten hier ausserdem
+das Dreifache an CSV-Lesevorgängen und Objekt-Auf-/Abbau je Sekunde.
+**➜ Beim nächsten unerklärlichen Chart-Verhalten ZUERST die Ladezeilen im
+Journal zählen.** Das kostet eine Minute und hätte hier drei Hypothesen erspart.
+
+✅ **Fix im Code: nur EINE Instanz zeichnet die Knöpfe.** Anspruch je Chart über
+eine temporäre `GlobalVariable` (`SRB_BTNOWN_<ChartID>`), gesetzt mit
+**`GlobalVariableSetOnCondition`** — also **atomar**. Ein Check-dann-Set hätten
+bei praktisch gleichzeitigem Start alle drei gewonnen. Nicht-Inhaber steigen in
+`BtnDraw()` sofort aus und melden **einmalig** im Experten-Log, dass eine zweite
+Instanz läuft (sichtbar machen statt still schlucken).
+⚠ **`OnDeinit` räumt die Knöpfe nur noch als Inhaber weg** und gibt den Anspruch
+frei — sonst hätte eine beendete Zweit-Instanz die Knöpfe der noch laufenden
+ersten gelöscht. Fällt der Inhaber weg, holt sich der nächste Timer-Durchlauf
+einer anderen Instanz den Anspruch.
+
+✅ **Zweite Absicherung: die Größe heilt sich selbst.** `BtnDraw()` legt einen
+Knopf **neu an**, wenn seine gespeicherte `XSIZE`/`YSIZE`/`FONTSIZE` nicht mehr
+zum Soll passt. Reines Nachsetzen der Eigenschaften (v1.49) reichte in der
+Praxis nicht.
+
+⚠ **Der eigentliche Fix liegt beim Nutzer:** die doppelten Instanzen entfernen
+(Rechtsklick auf den Chart → *Indikatorenliste* → alle `SR_Levels` bis auf eines
+löschen). Der Code-Guard verhindert nur den sichtbaren Schaden, nicht die
+dreifache Last.
+✅ `0 errors, 0 warnings`, `.ex5` frisch, Spiegel bitgleich.