Hallo Heinileini, ich denke du hast den Kern des Problems verstanden nur wir haben aneinander vorbei geredet.
Ja, ich denke auch, dass ich den Kern des Problems (nach AnlaufSchwierigkeiten) verstanden habe und bin mir sicher, dass wir immer noch aneinander vorbeireden.
Genau darum geht es diejenigen Instanzpräfixe, die nicht mehr in Verwendung sind zu prüfen und zu eliminieren.
Dieses Anliegen war sehr einfach zu verstehen.
Wenn neue Aufrufe hinzukommen ist das kein Problem, denn dann trägt dieser Aufruf sich selbstständig in den globalen DB ein und gut ist.
Aaah! Also doch. Immerhin dieses Detail hätten wir jetzt endlich (mit Beitrag 39) geklärt.
Meine Fragen ...
Warum soll nur überwacht werden, ob ein Präfix nicht mehr benutzt wird?
Warum nicht auch prüfen, ob ein neuer Präfix hinzugekommen ist? Weil mehr PräfixEinträge angelegt werden könnten, als das Array aufnehmen kann, sich also die Reserve als zu knapp bemessen erweisen könnte?
... zielten genau in diese Richtung, da das Erstellen der Liste ja nur eine minimale Erweiterung der Aufgabe des Vergleichens mit der Liste und eines evtl. Löschens eines Eintrags aus der Liste darstellt.
Hintergedanke meiner Fragen war auch: wenn man "voreilig" einen Präfix aus der Liste gelöscht hat, dann repariert sich die Liste ganz automatisch wieder, sobald sich die vermeintliche PräfixLeiche als nur scheintot erwiesen hat.
Problematisch ist nur wenn mittendrin welche gelöscht oder umbenannt werden
Das Löschen ist problematisch - darin sind wir uns einig.
Ein Umbenennen ist für mich nichts anderes als die Einführung eines neuen Namens bei gleichzeitiger Löschung des alten Namens.
Da das Umbenennen für mich auch das Löschen beinhaltet, beinhaltet es auch dieselbe Problematik, wie das Löschen.
Meine Unkenntnis der Möglichkeiten sagt mir:
Ich weiss nicht, ob ich das Verschwinden des alten Namens mit dem "gleichzeitigen" Auftauchen eines neuen Namens so in Verbindung bringen kann, dass ich beide Ereignisse eindeutig auf das einzige Ereignis des Umbenennens zurückführen kann.
Wenn es nämlich eine solche Präfix"leiche" in dem globalen DB gibt, funktioniert meine Visu nicht mehr ordentlich.
Das nicht mehr ordentliche Funktionieren der Visu ist also ein eindeutiges Kriterium dafür, dass HandlungsBedarf besteht?
Aber während ich mir deinen Kommentar durchgelesen habe ist mir eine andere Lösung eingefallen.
Spontan wollte ich eigentlich nur mit einem Vergleich Deines Problems mit dem Problem einer "StillstandsÜberwachung" reagiert haben.
Aber das erspare ich mir jetzt.
Nachtrag:
Index und Array im OB1 jedes mal initialisieren - Jede Instanz trägt sich ein und erhöht den Zähler - am Ende OB1 in Visu-Array kopieren - Fertig???
Dass in einem "Zyklus" gearbeitet werden müsste, ohne näher festmachen zu können, wie dieser Zklus aussieht und ob es der OB1-Zyklus sein könnte und ...
... Und wenn nicht, dann muss den Eintrag ein übergeordneter Baustein löschen.
dass etwas "Übergeordnetes" vorhandenen sein muss, das diesen "Zyklus" realisiert, hatte ich doch schon geschrieben.
Um den Overhead des "Übergeordneten" klein zu halten, hatte ich vorgeschlagen, das zyklisch auszuführende in den vorhandenen FB zu integrieren und dort nur bei einer einzigen Instanz pro Zyklus aktiv werden zu lassen.
Dass ich dafür den "zufällig" ersten Aufruf einer Instanz ausgeguckt hatte, obwohl von der Logik her sich der letzte Aufruf in einem Zyklus aufgedrängt hätte, ergibt sich daraus, dass mit Hilfe des "Übergeordneten" der erste Aufruf im FB eindeutig zu identifizieren ist, der letzte jedoch nicht (bzw. erst viel zu spät).
Index und Array im OB1 jedes mal initialisieren - Jede Instanz trägt sich ein und erhöht den Zähler - am Ende OB1 in Visu-Array kopieren - Fertig???
Was ist mit Aufrufen der Instanzen, die "ausserhalb" des OB1-Zyklus erfolgen oder die nicht lückenlos in jedem OB1-Zyklus stattfinden?
Gut, es mag sein, dass es solche Fälle gar nicht gibt. Aber darüber kann nur der TE Auskunft geben.