PureBoard

Ich konnte den Fehler jetzt noch zweimal provozieren, indem ich wieder neue 'Issues' hinzugefügt habe. Aber es passiert nicht jedesmal, und wenn dann nur bei meinen Projekt mit den mehreren Dateien.

Edit: Es ist jetzt auch beim Schließen von PB mit dem geöffneten Projekt passiert. Ich habe gleichzeitig zum Browser gewechselt, und PB war noch beschäftigt mit dem Schließen. Liegt vielleicht an der brustschwachen CPU.

Peter

Ich habe viele große Tabs geöffnet und auch alle Tools (Dateiexplorer, Form, Zeichen-Tabelle, ...) in die rechte Spalte gesetzt und immer wieder im PB-Einstellungsfenster Issues hinzugefügt und entfernt.
In meinen gefühlt 50 Versuchen konnte ich bis jetzt 2x den Fehler nachstellen.
Ich habe auch versucht, meinen PC auszubremsen/auszulasten, aber kein Erfolg.

Es passiert möglicherweise, wenn PB etwas länger braucht, als sonst während mein Tool erkennt, dass das Tool-Fenster nicht mehr existiert und sich neu erstellt. Wenn PB etwas länger braucht, dann sind die Controls von PB noch nicht fertig erstellt worden.
Mein Tool wartet jetzt etwas, bevor er mit der Neuerstellung und Neuimplementierung beginnt.
Kannst du mit dieser Version nochmal testen? Ich hoffe, dass diese Änderung ausreicht.
Temp-Version: http://www.rsbasic.de/temp/Multicolor_P ... e_List.zip

Ich habe es jetzt einigemale probiert, aber keine Fehlermeldung
Dafür waren beim Laden des Projekts kurz die vielfachen Einträge sichtbar. Die sind aber diesmal von selbst verschwunden, weil noch weitere Tabs geladen wurden. Ansonst tauchen die nicht mehr auf, das ist ja schon erledigt.

Edit: Bild gelöscht, ist nicht mehr hilfreich.

Peter

Multicolor Procedure List 1.0.9 wurde veröffentlicht.

Changelog:

• Geändert: Wenn die Portable-Version verwendet wird, wird die eigene Einstellungsdatei im gleichen Verzeichnis erstellt und gelesen.
• Bugfix: Wenn eine PB-Einstellung geändert wurde, dann aktualisiert PB die Benutzeroberfläche. Falls PB mit dem Neuerstellen der Controls länger braucht, konnte passieren, dass das Tool die Controls nicht fand.

Ich habe die RSBasic-Einstellungen in den Anwendungsdaten-Verzeichnis gelöscht. Die Version 1.0.9 verwendet und PB mit dem PORTABLE-Parameter gestartet wie immer. Es wird bei ein Änderung keine Ini-Datei angelegt. Es gibt volle Schreibrechte in dem PB-Verzeichnis. Nach beenden von PB gibt es einen Absturzdialog von Windows 7 64-Bit:
Edit: Wo wird die Ini-Datei genau gespeichert. Ich finde sie nicht, aber das Tool verwendet die gemachten Einstellungen nach einem Neustart.
Auch kein weiterer Absturz soweit.

Edit2: Habe die Ini schon gefunden. Mein Fehler, das Tool wird von einem anderen Verzeichnis gestart, nicht vom PB-Verzeichnis.
Aber Absturz gab es erneut:
Ich hatte auch DebugView offen, und die zwei Einträge erhalten:

[1516] Error -
[1516] Invalid args

Edit3: Im Moment gibt es keinen Absturz mehr. Ich habe das Ini-Verzeichnis gelöscht, wieder anlegen lassen, Einstellungen geändert, PB neugestartet, usw.

Edit4: Jetzt ist bei geschlossenen PB das Multicolor-Tool noch in der Taskliste mit Volldampf auf einem Core unterwegs, sprich 25 %.

Edit5: Das hängenbleiben kann ich jetzt nachstellen. Es passiert wenn beim Beenden von PB noch geänderte Dateien gespeichert werden. Wenn der Speichern-Dialog angezeigt wird. Danach bleibt das Tool hängen.

Peter

@DePe
Danke fürs Testen. Ich wundere mich, warum bei dir die Windows-Absturzmeldung kommt. Da OnError verwendet wird, sollte er doch den Fehler abfangen und direkt anzeigen.
Eigentlich solltest du so eine Meldung (nur als Beispiel mit Division durch 0, um einen Fehler zu demonstrieren) bekommen:

---------------------------
Fehler
---------------------------
Es ist ein schwerwiegender Fehler aufgetreten und das Programm muss beendet werden.
Senden Sie bitte die folgenden Informationen an support@rsbasic.de:

Datum/Uhrzeit: 27.05.2019 20:07:35
Betriebssystem: Windows 10
Anwendung: Multicolor Procedure List 1.0.9 (Build 626)
Fehlermeldung: Division by zero
Speicheradresse: 4200477

---------------------------
OK
---------------------------

Ich habe es mit Windows 10 und Windows 7 getestet, aber ich kriege es nicht nachgestellt. Solche Fehler liebe ich, die entweder nur manchmal oder auf einem anderen PC gar nicht auftreten.

Ist es derselbe PC, mit dem du die vorherigen Versionen auch immer getestet hast?

Ja, es ist derselbe PC.

Edit: Hatte wieder einen Absturz. Wieder wenn beim Beenden Dateien gespeichert werden mit dem angezeigten Speicher-Dialog.
Es waren wieder die zwei Ausgaben in DebugView:

[2488] Error -
[2488] Invalid args

Ich habe nur PB beendet und die PID 2488 war nicht mehr in der Taskliste. Zuvor habe ich diese Ausgaben noch nie gesehen, kann also nur vom Multicolor-Tool stammen.

Peter

DePe hat geschrieben:Edit4: Jetzt ist bei geschlossenen PB das Multicolor-Tool noch in der Taskliste mit Volldampf auf einem Core unterwegs, sprich 25 %.

Also dieser Fehler tritt bei mir zwar auf, aber extrem selten. Knapp eine Stunde war ich damit beschäftigt, PB zu starten und zu beenden, immer und immer wieder mit Sichten auf den Task-Manager. Dabei habe ich zusätzlich in der BindEvent-Prozedur (#PB_Event_Timer) einen Log-Eintrag erstellen lassen, um irgendwie die Ursache zu finden bzw. um herauszufinden, wo er stecken bleibt.
Mir ist folgendes aufgefallen: Wenn dieser Fehler auftritt, dann bleibt mein BindEvent+#PB_Event_Timer stecken (keine Endlosschleife, sondern er hört einfach auf). Wenn ich stattdessen als Thread laufen lasse, genau das gleiche Spiel. Bleibt einfach stecken, wenn dieser Fehler auftritt.
Aber wenn ich ohne BindEvent-Timer in der Hauptschleife logge, dann macht er problemlos weiter. Das wäre die einzige Lösung, genau dort abzufragen, ob PB noch läuft oder nicht, ohne dass er stecken bleibt. Das habe ich jetzt geändert.
Kannst du folgende Version nochmal testen, ob der Fehler "hängen bleiben" noch besteht?
http://www.rsbasic.de/temp/Multicolor_P ... t_Beta.zip
Falls in dieser neuen Version der andere Fehler mit dem Absturz erneut auftritt, einfach erneut bestätigen. Vielleicht ist der Fehler nach dem Umbau ebenfalls beseitigt.

Ich kann mit der Beta-Version keinen Absturz oder ein hängenbleiben provozieren. Es kommt mir so vor, als das die CPU-Last des Tools beim Schließen von PB jetzt geringer ist. Sie ist ansonst kurzzeitig auf 10 % hoch und dann wieder runter auf 2 %. Jetzt bleibt die Last so bei 1 % bis 2 %, oder gar 0 %.

Falls du mehr wegen dem BindEvent-Fehler ermitteln kannst, wäre ich an einer genaueren Erklrärung interessiert. Ich verwende nur BindEvent-Prozeduren, und habe damit eigentlich keine Probleme. Nur wenn ich mit noch langsameren PCs teste, z.B. PIII 450 MHz, habe ich mit den Timer-Ereignissen ebenfalls solche Probleme, das sich einfach nichts mehr tut. Habe das Problem aber noch nicht genau angeschaut. Ich verwende auch Threads und denke das es mit Single-Core-, oder langsamen Multi-Core-CPUs damit vielleicht eher Fehler gibt. Im Moment gehe ich aber davon aus, dass es meine eigenen Fehler sind.

Peter

Leider konnte ich noch nicht herausfinden, warum das so ist.

Ich habe nur eine Vermutung, dass eventuell bei der alten Multicolor Procedure List-Version folgendes passiert:
Wenn man PB beendet, dann werden zuerst alle PB-Gadgets und andere Objekte freigegeben und zum Schluss wird der PB-Prozess freigegeben.
Wenn die PB-Gadgets und der PB-Prozess nicht mehr existieren und mein Tool ermittelt danach, ob PB noch läuft, dann bekommt er False zurück und beendet sich erfolgreich.

Falls aber stattdessen mein Tool zufälligerweise genau dazwischen in diesem Millisekundenbereich abfragt, nachdem die Gadgets freigegeben wurden, bevor der PB-Prozess freigegeben wurde, dann denkt mein Tool, dass die Gadgets nur neu erstellt wurden, weil man im PB-Einstellungsfenster auf Speichern geklickt hat. So würde mein Tool versuchen, seine Custom-Prozedurliste in PB neu zu implementieren, aber genau in dem Moment wird der PB-Prozess freigegeben und es entsteht dabei eine "Geisterverbindung" und gerät in eine Endlosschleife.
Komisch ist nur, dass sowohl Threads als auch BindEvents wie z.B. Timer in diesem Fall einfach hängen bleiben bzw, stehen bleiben. Nur die Haupt-Eventschleife bleibt bestehen und man kann da noch auf Events reagieren.
Warum läuft mein Tool mit dem Thread und BindEvents nicht ganz normal weiter? Und warum entsteht (auch bei mir) die durchgehende 25 %-Prozessorauslastung?

Zuerst habe ich an folgenden Wikipedia-Artikel gedacht: https://de.wikipedia.org/wiki/Zombie-Prozess
Was aber bei meinem Tool glaube ich nicht der Fall sein kann.

Ich verwende auch nur BindEvent-Prozeduren, weil man damit den Quellcode besser trennen und übersichtlicher gestalten kann.
Ich werde später mal versuchen, ob ich mit einem einfachen, kurzen BindEvent-Beispiel (ohne sich an PB zu hängen) nachstellen kann. Falls man das bei einem einfachen BindEvent-Beispiel ebenfalls nachstellen kann, dann ist das ein PB-Bug.

Ich gebe dir ein paar Tage Zeit zum weiteren Testen der Beta-Version, falls du mein Tool benutzen möchtest. Falls nach ein paar Tagen der Fehler nicht mehr auftreten sollte, dann kann ich eine neue offizielle Version veröffentlichen.