Multicolor Procedure List

[Kurzer]

Ja tolles Programmchen. Und wie schnell du immer die Updates raushaust !

Das gleiche denke ich mir auch die ganze Zeit.

Es gab hier im Forum vor Jahren auch mal jemanden aus Österreich, der in brutal kurzen Abständen richtig komplexes Zeug veröffentlicht hat. Mir kommt dann immer der Begriff "hochbegabt" in den Sinn. Ich glaube es gibt für solche Menschen auch eine Art Fachbegriff. In meinem früheren Berufsumfeld hatten wir einen Azubi der Sysadmin war. Man hatte in der Interaktion mit ihm immer das Gefühl, dass er extrem genervt ist, weil seine interne "Hirn-Taktrate" ca. 5 mal höher war als die seiner Mitmenschen. Das betraf sowohl das Denken, Schreiben als auch Sprechen. Die Generation 50+ kam mit ihm schon allein beim Kommunizieren nicht mehr mit.

Aber zurück zum Thema.

Danke RSBasic für das Einbauen der aktuellen Prozedur-Funktion.
Sie funktioniert bei mir hervorragend und frisst in meinem Fall max. 2% CPU Leistung.

Was mir auffällt ist aber, dass die zugehörige Info-Zeile "Aktuell: <Prozedurname>" (unter den Buttons) ca. alle 500ms neu refreshed wird und dadurch flackert. Ist das bei allen Gadgets deines Panels so, dass du die immer wieder redrawst? Eigentlich muss das ja nur neu gezeichnet werden, wenn sich der aktuelle Prozedurname geändert hat.

Als i-Tüpfelchen (für meinen persönlichen Geschmack) würde ich es noch gut finden, wenn die aktuelle Markierung im ListView völlig unterdrückt wird. Also die (in meinem Fall graue,) farbliche Hinterlegung des Eintrags, den man zuletzt angeklickt hat. Wenn man nämlich im Source nach dem Klicken in eine andere Prozedur scrollt, dann hat diese farbliche Hinterlegung keine Aussagekraft mehr. Außer man möchte wissen welchen Eintrag man zuletzt angeklickt hat.

Und bzgl. der fett gedruckten, aktuellen Prozedur in der Liste ist das für meine alten, -4.5 Dioptrin-gestraften Augen nicht immer sofort ersichtlich. Ich weiß nicht, ob es für dich große Umstände macht für die aktuelle Prozedur auch eine farbliche Hinterlegung einzubauen. Ich persönlich würde das ganze dann definitiv schneller überblicken in der Prozedurliste.

Aber es ist natürlich nicht so einfach so viele unterschiedliche Bedürfnisse der User unter einen Hut zu bringen. Insofern bin ich auch schon echt froh über das, was dein Tool bisher leistet.

Gruß Kurzer

PS: Mich interessiert auch der technische Hintergrund bzgl. der Erkennung der aktuellen Prozedur. Bekommst Du von der IDE die aktuelle Zeilennummer übermittelt oder wie läuft das ab? Und scannst du permanent nach dem Prozedurenamen oder nur bei Änderung der Zeile? Ich frage deshalb, weil es bei einigen Usern so hohe CPU-Auslastungen gab. Musst du das %TEMPFILE immer wieder neu einlesen?

[RSBasic]

Ich bin froh, dass ich derzeit so hochmotiviert bin. Und das muss ich natürlich ausnutzen, bevor meine nächste Pause kommt.

Was mir auffällt ist aber, dass die zugehörige Info-Zeile "Aktuell: <Prozedurname>" (unter den Buttons) ca. alle 500ms neu refreshed wird und dadurch flackert. Ist das bei allen Gadgets deines Panels so, dass du die immer wieder redrawst? Eigentlich muss das ja nur neu gezeichnet werden, wenn sich der aktuelle Prozedurname geändert hat.

Das fällt bei mir nicht auf, aber du hast Recht. Ich werde das ändern.

Als i-Tüpfelchen (für meinen persönlichen Geschmack) würde ich es noch gut finden, wenn die aktuelle Markierung im ListView völlig unterdrückt wird. Also die (in meinem Fall graue,) farbliche Hinterlegung des Eintrags, den man zuletzt angeklickt hat. Wenn man nämlich im Source nach dem Klicken in eine andere Prozedur scrollt, dann hat diese farbliche Hinterlegung keine Aussagekraft mehr. Außer man möchte wissen welchen Eintrag man zuletzt angeklickt hat.

Das spielte nur am Anfang eine Rolle, als der Fokus noch nicht automatisch nach dem Klick auf das PB-ScintillaGadget gesetzt wurde.
Jetzt ergibt das (#PB_ListIcon_AlwaysShowSelection) natürlich keinen Sinn mehr. Ich werde das entfernen. Danke für den Hinweis.

Und bzgl. der fett gedruckten, aktuellen Prozedur in der Liste ist das für meine alten, -4.5 Dioptrin-gestraften Augen nicht immer sofort ersichtlich. Ich weiß nicht, ob es für dich große Umstände macht für die aktuelle Prozedur auch eine farbliche Hinterlegung einzubauen. Ich persönlich würde das ganze dann definitiv schneller überblicken in der Prozedurliste.

Farbliche Markierung wäre nicht so gut, sonst wird die vom User festgelegte Schriftfarbe/Hintergrundfarbe überschrieben.
Derzeit ist es so, dass der Eintrag fett markiert und um 1px vergrößert dargestellt wird. Vielleicht um 2px stattdessen erhöhen? Oder zusätzlich unterstreichen? Ich habe ein paar Screenshots erstellt und du kannst jeweils deine Meinung dazu sagen:
So sieht es derzeit aus:


Mit zusätzlicher Unterstreichung:


Fett und 2px vergrößert:


Fett und 2x vergrößert und unterstrichen:

PS: Mich interessiert auch der technische Hintergrund bzgl. der Erkennung der aktuellen Prozedur. Bekommst Du von der IDE die aktuelle Zeilennummer übermittelt oder wie läuft das ab? Und scannst du permanent nach dem Prozedurenamen oder nur bei Änderung der Zeile? Ich frage deshalb, weil es bei einigen Usern so hohe CPU-Auslastungen gab. Musst du das %TEMPFILE immer wieder neu einlesen?

PB teilt mir leider nichts automatisch mit und ich kann mich auch nicht in die Events reinhängen. Vielleicht mit Process Injection, aber das möchte ich nicht.
Ich muss leider per WinAPI selber die Werte manuell ermitteln.
Z.B. die aktuelle Cursorposition:

Code: Alles auswählen

PBScintillaCursorPosition = SendMessage_(PBScintillaHandle, #SCI_GETCURRENTPOS, 0, 0)

Erst wenn sich die Cursorposition ändert, dann kann ich weitere Werte ermitteln, z.B. mit Hilfe der Cursorposition die aktuelle Prozedur ermitteln.
Zum Ermitteln der aktuellen Prozedur verwende ich den Code von Kiffi.
Man fängt ab der aktuellen Cursorposition an und fragt Zeichen für Zeichen rückwärts ab, bis man den Anfang der Prozedur gefunden hat und dann hat man den Namen der aktuellen Prozedur.
Das Problem ist, wenn der Quellcode riesig ist, dann ist auch der String riesig und macht das ganze Werkzeug extrem lahm. Ich kann zwar sagen, maximal 1000 Zeichen, aber ich weiß vorher nicht, wie groß die Prozedur ist.
Und je größer die aktuelle Prozedur ist, desso länger dauert die Rückwärtssuche/Schleife.

Bei der Prozedurliste frage ich immer die Anzahl und die Gesamtlänge, bevor ich alle Prozedurnamen in mein ListIconGadget importiere.
Den Quellcode lese ich mit ReadProcessMemory_() aus. Es gibt zwar #SCI_GETTEXT, aber das funktioniert nur bei eigenen Anwendungen, aber damit kann ich nicht den Inhalt aus fremden Prozessen auslesen.

[Kurzer]

Naja, ich bin ja nicht das Maß aller Dinge und dein Tool nutzen auch andere User.
Ein unterstrichener Eintrag würde für mich sicherlich eindeutiger aus der Liste herausstechen. Also gleiche Fontgröße, fett und unterstrichen.

Ich bin froh, dass ich derzeit so hochmotiviert bin. Und das muss ich natürlich ausnutzen, bevor meine nächste Pause kommt

Das kenne ich . Dann ist ja es gut, wenn dein Tool so intensiv von den Usern getestet wird und du feedback bekommst.

Man fängt ab der aktuellen Cursorposition an und fragt Zeichen für Zeichen rückwärts ab, bis man den Anfang der Prozedur gefunden hat und dann hat man den Namen der aktuellen Prozedur.
Das Problem ist, wenn der Quellcode riesig ist, dann ist auch der String riesig und macht das ganze Werkzeug extrem lahm. Ich kann zwar sagen, maximal 1000 Zeichen, aber ich weiß vorher nicht, wie groß die Prozedur ist.
Und je größer die aktuelle Prozedur ist, desso länger dauert die Rückwärtssuche/Schleife.

Hmm, laß mal überlegen. Du könntest einmalig ReverseString(String$) benutzen, um den gesamten Source gespiegelt vorliegen zu haben und dann direkt vorwärts mit FindString(String$...) nach "erudecorP" suchen.

Gruß Kurzer

[RSBasic]

Multicolor Procedure List 1.2.2 wurde veröffentlicht.

Changelog:

• Geändert: Der Text "Aktuell: <aktuelle Prozedur>" wird jetzt nur bei Änderung aktualisiert.
• Geändert: Aktuelle Prozedur wird jetzt zusätzlich unterstrichen.
• Entfernt: Inaktive Markierung (#PB_ListIcon_AlwaysShowSelection) wurde entfernt.

[Kurzer]

Einwandfrei! Kein Flackern, der unterstrichene Eintrag ist gut zu sehen und alles fühlt sich wie ein Teil der IDE an.
Das ist ein hervorragendes Helferlein geworden.

Und ich nehme meinen Vorschlag zurück, die Hervorhebung der aktuelle Prozedur gern als Standalone Tool zu nutzen. Ich bleibe jetzt bei deinem Multicolor Procedure Tool.

Vielen Dank für die ganzen Sonderlocken, die du da eingebaut hast.

PS: Ach halt... ich habe gerade noch eine eher seltene condition getestet.
Dein Tool habe ich so eingebunden, dass es mit dem Start der IDE startet. Ruft man es dann aber nochmals manuell über das Werkzeug-Menü der PB IDE auf, dann hat man lt. Taskmanager zwei Instanzen davon laufen. Das ist sicherlich nicht so gedacht, oder?

PS2: Verdammt, wenn man gerade beim Testen ist: Folgendes ist mir aufgefallen.
Ich habe Browser und PB Editor offen. Der Editor erstreckt sich über den gesamten Screen, der Browser nimmt ca. 2/3 der linken Seite des Screens ein. Wenn der Browser vorn ist, dann sieht man rechts also noch 1/3 der PB IDE.
Nun folgende Schritte durchführen:
1) Suchfeld in Multicolor Procedure List benutzen und auf eine Prozedur einschränken.
2) Browser nach vorne holen
3) Mit der Maus rechts in das IDE-Fenster klicken
=> Die PB IDE kann damit nicht mehr in den Vordergrund geholt werden. Ich muss erst den zugehörigen Eintrag unten in der Taskleiste von Windows anklicken, um PB wieder nach vorn holen zu können.

Dabei ist mir dann auch aufgefallen, dass man das Suchfeld manuell wieder löschen muss, wenn man die gesamte Prozedurliste wieder sehen möchte. Hier wäre ein [x] Button zum löschen des Suchfelds sehr nützlich.

RSBasic, sag mir bitte rechtzeitig bescheid, wenn du mich zu hassen beginnst. Ich kann nicht anders, ich hatte früher unter anderem mit Testen von Software zu tun.

PS3: Hmm, ich habe ein sehr seltsames Verhalten der PB IDE gerade. Da ich das Tool nun dauerhaft nutzen möchte, habe ich es in mein PB Verzeichnis kopiert und nicht mehr unter D:\Test\ liegen.
Den Eintrag im PB Werkzeugmenü habe ich entsprechend angepasst (bzw. auch schon mal komplett gelöscht und neu angelegt), aber die IDE versucht immer noch auf das alte Verzeichnis zuzugreifen. Sichtbar wird das dadurch, dass ich die Exe nun in "Multicolor Procedure List x64.exe" umbenannt habe, die IDE aber auf die Datei ohne das "x64" am Ende des Namens zugreifen möchte.



Der Inhalt der Datei "Tools.prefs" innerhalb von PureBasic zeigt mir allerdings den korrekten, neuen Eintrag an.

Code: Alles auswählen

[Tool_9]
Command = C:\PortableApps\PureBasic 570 x64 Portable\PureTools\Multicolor-Procedure-List\Multicolor Procedure List x86.exe
Arguments = 
WorkingDir = 
MenuItemName = Multicolor Procedure List2
Shortcut = 0
ConfigLine = 
Trigger = 1
Flags = 0
ReloadSource = 0
HideEditor = 0
HideFromMenu = 0
SourceSpecific = 0
Deactivate = 0

Hat jemand eine Ahnung wo PB diese Werkzeuginfos evtl. noch abspeichert? Ich bin ziemlich ratlos.
(Ja, dort ist testweise die x86er Version des Tools in meiner x64 PB Installation eingebunden, aber es funktioniert auch mit dem x64 Tool nicht)

Nachtrag: Okay hab's gefunden, es liegt tatsächlich am Umbenennen der Datei. Die Meldung kommt offenbar nicht von der PB IDE, sondern von deinem Tool.

[RSBasic]

Dein Tool habe ich so eingebunden, dass es mit dem Start der IDE startet. Ruft man es dann aber nochmals manuell über das Werkzeug-Menü der PB IDE auf, dann hat man lt. Taskmanager zwei Instanzen davon laufen. Das ist sicherlich nicht so gedacht, oder?

Normalerweise kommt das nicht vor, da man laut Anleitung die Checkbox "Werkzeug vom Hauptmenü verstecken" aktivieren muss, dann hat man keine Möglichkeit, das Werkzeug manuell aus dem Menü zu starten.
Aber ich sollte trotzdem eine Abfrage einbauen, dass immer pro PB-Instanz maximal nur eine Werkzeug-Instanz laufen darf.

1) Suchfeld in Multicolor Procedure List benutzen und auf eine Prozedur einschränken.
2) Browser nach vorne holen
3) Mit der Maus rechts in das IDE-Fenster klicken
=> Die PB IDE kann damit nicht mehr in den Vordergrund geholt werden. Ich muss erst den zugehörigen Eintrag unten in der Taskleiste von Windows anklicken, um PB wieder nach vorn holen zu können.

Das ist wahrscheinlich das gleiche Verhalten wie hier: viewtopic.php?p=352900#p352900
Das Problem habe ich auch behoben, indem ich mein Werkzeugfenster als Kindfenster von PB-Fenster definiere, und es hat gut funktioniert.
Aber später gab es ein anderes Problem und zwar: viewtopic.php?p=353054#p353054
Aus dem Grund musste ich es wieder entfernen, da ich ein IMA-Fehler nicht dulden darf.
Ich habe leider keine andere Möglichkeit gefunden, um das Fokus-Problem zu beheben.

Dabei ist mir dann auch aufgefallen, dass man das Suchfeld manuell wieder löschen muss, wenn man die gesamte Prozedurliste wieder sehen möchte. Hier wäre ein [x] Button zum löschen des Suchfelds sehr nützlich.

Werde ich hinzufügen.

RSBasic, sag mir bitte rechtzeitig bescheid, wenn du mich zu hassen beginnst. Ich kann nicht anders, ich hatte früher unter anderem mit Testen von Software zu tun.

Kein Problem

[Kurzer]

Oh, das mit dem Verstecken des Tools von der Werkzeugliste habe ich übersehen.
Stimmt, in deinem Screenshot ist das aktiviert. Sorry, mein Fehler.

Ich habe leider keine andere Möglichkeit gefunden, um das Fokus-Problem zu beheben.

Alles klar, kein Problem. Dafür, dass du eh schon viele Klimmzüge machen musst, um das Tool in die IDE zu integrieren, ist es dir wirklich gut gelungen. Ich kann mit dem Fokusproblem leben. Man sollte beim coden eh nicht so viel im Forum rumlungern.

Bei meinem "PS3" habe ich festgestellt, dass das Tool nicht umbenannt werden darf, weil es offenbar seine eigene Exe sucht.
Ich konnte es daher nicht installieren. Aber ich habe das Problem dann doch selbst lösen können.

[DePe]

Erst wenn sich die Cursorposition ändert, dann kann ich weitere Werte ermitteln, z.B. mit Hilfe der Cursorposition die aktuelle Prozedur ermitteln.
Zum Ermitteln der aktuellen Prozedur verwende ich den Code von Kiffi.
Man fängt ab der aktuellen Cursorposition an und fragt Zeichen für Zeichen rückwärts ab, bis man den Anfang der Prozedur gefunden hat und dann hat man den Namen der aktuellen Prozedur.
Das Problem ist, wenn der Quellcode riesig ist, dann ist auch der String riesig und macht das ganze Werkzeug extrem lahm. Ich kann zwar sagen, maximal 1000 Zeichen, aber ich weiß vorher nicht, wie groß die Prozedur ist.
Und je größer die aktuelle Prozedur ist, desso länger dauert die Rückwärtssuche/Schleife.

Ich habe jetzt mit dem Tool von Kiffi und dem Multicolor-Tool getestet. Also innerhalb eines Projekts nur mit Moduldateien.
In der längsten Datei mit 5.000 Zeilen, ist am Ende eine Prozedur mit 19 Zeilen. Mit dem Multicolor-Tool dauert es 34* Sekunden bis das Tool wieder reagiert und die Prozedur in der Liste markiert. Mit dem Tool von Kiffi wird die Messagebox sofort angezeigt, naja vielleicht eine halbe Sekunde später.
Kann es sein das du irgendeinen logischen Fehler in dein Tool eingebaut hast?

Peter

* PIII 450 MHz

[RSBasic]

Wie groß ist ist dein Modul, in dem sich deine Prozedur befindet? Ich muss leider weiter rückwärts suchen und zwar nach dem Namen des Moduls, damit ich auch den richtigen Eintrag in der Prozedurliste fett markieren kann. Mal angenommen, es existieren zwei unterschiedliche Module mit jeweils eine Prozedur mit demselben Namen. Beispiel:

Code: Alles auswählen

MyModule1::Init()
MyModule2::Init()

Wenn man beispielsweise in der Prozedur Init() von MyModule2 ist, dann soll auch dieser Eintrag markiert werden. Das ist der Unterschied zwischen Kiffis Code und den von mir erweiterten Code von Kiffi. Der originale Code von Kiffi schaut nur nach aktueller Prozedur, mehr nicht, das reicht aber nicht aus, da PB Module kann, damit man gleichnamigen, unabhängigen Prozeduren erstellen kann.
Ich kann später mal schauen, ob ich den Code zum Ermitteln umbaue und optimiere.

[DePe]

Da hast du natürlich recht, das habe ich nicht bedacht. Ich verwende pro Datei nur ein Modul, es ist also in diesen Fall auch 5.000 Zeilen bzw. 21.700 Zeichen groß.

Peter