Multicolor Procedure List

[RSBasic]

Multicolor Procedure List 1.3.1 wurde veröffentlicht.

Changelog:

• Bugfix: Wenn vor "Procedure" Tabulatorzeichen vorhanden sind, wurde nicht erkannt.
• Geändert: DPI-Compiler-Option ist jetzt aktiviert.
• Hinzugefügt: Button "Einstellungen"
• Hinzugefügt: Pfeil-Button zum Wechseln der sichtbaren Einstellungen, weil es inzwischen viele Buttons existieren.
• Hinzugefügt: Wenn der Cursor in ;-Kommentare ist, dann wird der Eintrag auch hervorgehoben.
• Bugfix: Prozedurenerkennung

Was mir mit der 1.3.0 allerdings auffällt ist, dass einige Prozedurnamen das Hervorheben der aktuellen Prozedur aushebeln.
Bei folgende Testprozeduren werden nur die letzten Beiden in der Liste korrekt hervorgehoben (wenn der Cursor sich in der Prozedur befindet).

bei deinen ersten zwei Prozeduren ist ein Tabulator vor dem Namen vorhanden, darum wird die Markierung nicht funktionieren.

Tabulatorzeichen werden jetzt berücksichtigt.

Hallo RSBasic,

gerade ist mir noch eine Kleinigkeit aufgefallen.

Prozedurparameter, deren Typendefintion aus einem anderen Modul gezogen wird, werden nicht korrekt geparst. Den "::" als Separator kann dein Tool nicht handhaben.

Beispiel:

Code: Alles auswählen

ShowResult(*Result.DBI::structResult, sText.s)

Die Prozedurliste zeigt dann nur structResult, sText.s) an.

Das gleiche Problem hatte ich gerade bei meinem Tool "DeclareFilter" zu fixen.

Gruß Markus

Edit 05.10.20: Das ganze tritt nur auf, wenn der Button "Hide module names" aktiviert ist!

Kannst du hier einen kleinen vollständigen Beispielcode posten, damit ich den Code direkt testen kann? Das wäre lieb.

nach langer Zeit der Verwendung von der Multicolor Procedure List 1.2.8 ist mir ein neuer Fehler aufgefallen.
Ich habe in einer Struktur das Feld 'eProcedure' verwendet, und damit gibt es Probleme. Wenn sich der Curser im Code hinter diesen Namen befindet, wird die Proezdur in der Liste nicht mehr ausgewählt.
Das kann man leicht verhindern mit umbenennen des Felds. Aber ich konvertiere gerade Code von einer anderen Sprache und da ist es mir aufgefallen.

Behoben

[DePe]

Hallo RSBasic,

in der aktuellen Version 1.3.1 funktioniert das Hervorheben der Kommentare in der Prozedurliste bei mir nicht. Der Grund ist, dass ich immer mindestens ein Leerzeichen nach ';-' verwende, z.B. ';- Kommentar'.

Ich verwende auch zwischen Prozedurgruppen nur ';-' ohne weiteres Leerzeichen oder Text. Wenn man den Cursor in diese Zeile setzt, springt die Prozedurliste ganz nach oben, und alle Zeilen mit ';-' werden hervorgehoben.

Danke jedenfalls für die neue Version.

Peter

[RSBasic]

Multicolor Procedure List 1.3.2 wurde veröffentlicht.

Changelog:

• Bugfix: Kommentare werden auch mit Leerzeichen erkannt.
• Bugfix: Kommentare werden auch mit Tabs erkant.
• Bugfix: Wenn ein Text einer Sprache fehlt, dann wird stattdessen der originale Sprachtext angezeigt.

in der aktuellen Version 1.3.1 funktioniert das Hervorheben der Kommentare in der Prozedurliste bei mir nicht. Der Grund ist, dass ich immer mindestens ein Leerzeichen nach ';-' verwende, z.B. ';- Kommentar'.

Behoben

[DePe]

Hallo RSBasic,

danke. funktioniert jetzt wunderbar.

Peter

[RSBasic]

Multicolor Procedure List 1.3.3 wurde veröffentlicht.

Changelog:

• Bugfix: Sprachdateien sind jetzt im richtigen Kodierungsformat.

[RSBasic]

Multicolor Procedure List 1.3.4 wurde veröffentlicht.

Changelog:

• Geändert: Scintilla-Code wird jetzt nicht mehr als Ascii ausgelesen, sondern als UTF8.
• Geändert: Nach der Änderung der Settings.ini wird das Werkzeug automatisch neu gestartet.

[Kurzer]

Kannst du hier einen kleinen vollständigen Beispielcode posten, damit ich den Code direkt testen kann? Das wäre lieb.

Klar, gerne:

Code: Alles auswählen

DeclareModule pt
	Structure colour
		red.a
		green.a
		blue.a
		alpha.a	
	EndStructure
EndDeclareModule

Module pt
; placebo	
EndModule

Procedure Normal(sString.s)
	;nix
EndProcedure

Procedure MitModuleZugriff(*myPoint.pt::colour)
	;nix
EndProcedure

Das sieht dann so aus:



Allerdings habe ich mit deieer aktuellen Version 1.3.3. noch diverse massive Probleme:

1) Es wird in größeren Codes kein Scrollballken mehr angezeigt.

2) Wenn der Caret auf einer Kommentar-Markierung steht, dann werden in deinem Tool alle Kommentar-Markierung hervorgehoben (sofern sie identischen Inhalt haben... ist möglicherweise von dir so gewollt, irritiert aber eher und war meiner Meinung nach auch schon mal anders ). Edit: Ah, das zeigt noch mehr nonsense an (siehe GIF) und hat offenbar mit Punkt 3 zu tun. Eine Kommentar-Markierung wird gar nicht angezeigt (;- Private procedures (imp)).

3) Steht der Caret hinter einem "EndProcedure", aber noch vor dem nachfolgenden "Procedure" der nächsten Prozedur, dann wird noch immer die darüber stehende Prozedur hervorgehoben.

Und zwei "nice to haves" fallen mir dabei noch ein.

a) Wenn der Knopf "Automatisches Ausklappen der Prozedur nach dem Klick deaktivieren" gedrückt ist (also die Funktion aktiv ist), dann wäre es super, wenn der Aufklappzustand einer Prozedur völlig unangetastet bleibt. Momentan ist es so, dass eine angeklickte Prozedur entweder immer aufgeklappt wird oder immer zugeklappt wird (je nach Zustand des Buttons). Hat man nun Prozeduren, die man für diese Sitzung zugeklappt lassen möchte, dann darf man sie tunlichst nicht in der Prozedurliste anklicken, sonst... *fupp*.

b) Etwas für lange Sourcecodes mit vielen Prozeduren: Ich fände es super, wenn die Prozedurliste die Position ihrer Einträge (bzw. der Scrollposition) *immer* mit der Position des Cartets im Sourcecode synchron hält. Auch dann, wenn man irgendwo in den Sourcecode klickt, wo es für die Prozedurliste gar nichts hervorzuheben gibt.

Wenn dann die aktuelle Position, in der sich der Caret befindet, bzw. der betreffende Bereich in der Prozedurliste vertikal mittig ausgerichtet wird statt ganz oben in der ersten Zeile, dann wäre das noch perfekter (halt so ein bisschen an diese Birdview-Übersicht von VS-Code angelehnt).

So, und hier noch das GIF, das die Probleme 1 bis 3 im Schnellformat anzeigt.

[DePe]

Hallo Kurzer,

der Fehler mit dem Modulnamen und Doppelpunkt ist mir noch nie aufgefallen. Ich habe aber die Anzeige der Parameter deaktiviert, mich stören sie in der Prozedurliste. Vielleicht ist das eine Option für dich?

Peter

[RSBasic]

a) Wenn der Knopf "Automatisches Ausklappen der Prozedur nach dem Klick deaktivieren" gedrückt ist (also die Funktion aktiv ist), dann wäre es super, wenn der Aufklappzustand einer Prozedur völlig unangetastet bleibt. Momentan ist es so, dass eine angeklickte Prozedur entweder immer aufgeklappt wird oder immer zugeklappt wird (je nach Zustand des Buttons). Hat man nun Prozeduren, die man für diese Sitzung zugeklappt lassen möchte, dann darf man sie tunlichst nicht in der Prozedurliste anklicken, sonst... *fupp*.

Leider lässt sich das nicht beheben, weil ich die Klicks in meinem ListIconGadget nur an das originale ListViewGadget von PB IDE weiterreiche. Sonst muss mein Werkzeug selber im gesamten Quellcode nach der Stelle der angeklickten Prozedur suchen und scrollen. Das wäre too much bezzüglich Performance. Da PureBasic IDE selbst Kontrolle über den geöffneten Code hat, wäre es besser, wenn PB zur Stelle scrollt.

[Kurzer]

Leider lässt sich das nicht beheben, weil ich die Klicks in meinem ListIconGadget nur an das originale ListViewGadget von PB IDE weiterreiche. Sonst muss mein Werkzeug selber im gesamten Quellcode nach der Stelle der angeklickten Prozedur suchen und scrollen. Das wäre too much bezzüglich Performance. Da PureBasic IDE selbst Kontrolle über den geöffneten Code hat, wäre es besser, wenn PB zur Stelle scrollt.

Ah, alles klar. Ja, das kann ich verstehen. Dann erbarmt sich ja evtl. ein User, der an der IDE mit rumbastlet (guthub) und spendiert eine Einstellung für das Verhalten "Prozedur aufklappen oder nicht".

der Fehler mit dem Modulnamen und Doppelpunkt ist mir noch nie aufgefallen. Ich habe aber die Anzeige der Parameter deaktiviert, mich stören sie in der Prozedurliste. Vielleicht ist das eine Option für dich?

Ah, gut zu wissen, dass es einen Workaround gibt. Naja, der Bug ist für mich kein ShowStopper, aber ich hatte ihn einfach mal mit gemeldet. Ob er einfach zu fixen ist, muss RSBasic entscheiden. Ich kann auch damit leben, weil es ja nicht so oft vorkommt, dass man sich einen Variablentyp aus einem Modul holt.