Feature request - Object Inspector - properties whitelist/blacklist - user definable

[ChristianZ]

Hallo liebe Delphi Gemeinde,

ich habe bei Embarcadero einen Feature Request eingestellt.
Wer sich in diesem Thema wiederfindet, darf gerne den Vorschlag unter dem folgenden Link kommentieren und auch hoch voten.

https://quality.embarcadero.com/browse/RSP-12466

Es geht darum, im Objectinspector die Masse an Properties und Events sinnvoll zu filtern.
Die neue Such-Funktion finde ich bereits sehr gut - jedoch noch nicht weitgehend genug.

Ich benötige selten mehr als 5- 10 Properties, die ich editieren möchte.
Deshalb schlage ich vor, die Liste frei definierbar zu filtern.

Sei es durch White / Blacklisten, die sich jeder Nutzer selber zusammenstellen kann oder durch eine bessere Nutzung der bereits bestehenden Kategorien.

Am Besten wäre es aus meiner Sicht, frei definierbare Kategorien anlegen zu können, und beliebige Properties/Events in beliebige Kategorien zu sortieren.

Also nochmals, wenn jemand dieses Feature ebenfalls brauchen könnte, würde ich mich freuen, wenn Ihr fleißig kommentiert und voted.

Marco Cantú hat auf den Delphi Tagen auf die Anfrage geantwortet, dass natürlich Feature implementiert werden, die vielen Entwicklern zu gute kommen. Und dass bisher kaum jemand "Kategorien" nutzt, obwohl es dieses Feature schon lange gibt .....

Gruß und Dank
Christian

P.S.:
Wenn jemand noch in anderen Foren unterwegs ist, oder häufiger in Communities im Ausland, dann darf mein Text auch gerne dorthin geteilt werden.

[Der schöne Günther]

Ich würde noch ein Bild dazu machen wie du dir das optisch vorstellst und im Text deutlicher machen dass du findest dass die in "10 Seattle" neu hinzugekommene Filterfunktion noch nicht weit genug geht.

PS: Gab es bei "Issue Type" nicht mal "Feature request/enhancement" oder so etwas? Wurde das entfernt? Ansonsten vielleicht http://delphi.uservoice.com/forums/4432-general wobei ich nicht weiß, ob das überhaupt "offiziell" von Embarcadero ist.

[mkinzler]

Die Frage ist nur, wie man das implementiert, da es ja nicht reicht neue Kategorien anlegen zu lassen, man muss die Properties ja auch entsprechend zuordnen und diese auch Verwalten. Dies müsste ja für jede Komponente indivuell verwaltet werden; nur anhand der Bezeichnung der Property wäre ja sehr ungenau.

[haentschman]

Hallöle...

Sowas gab es mal bis XE. Der Daniel (Nachtrag: gelogen, war Uwe Schuster) hatte das zur Verfügung gestellt. Da hatte man dann im OI einen dritten Reiter namens Favoriten. Man konnte dann einzelne Properties zu Favoriten erklären und diese waren dann Klassenbezogen identisch.
Vieleicht bitten wir Daniel (Uwe) den QT zur Verfügung zu stellen um dieses immer aktuell zu halten. Da die ToolsAPI bestimmt abwärtskompatibel ist, ist die alte Version bestimmt einfach anzupassen.

[ChristianZ]

Zitat von haentschman:

Hallöle...

Sowas gab es mal bis XE. Der Daniel (Nachtrag: gelogen, war Uwe Schuster) hatte das zur Verfügung gestellt. Da hatte man dann im OI einen dritten Reiter namens Favoriten. Man konnte dann einzelne Properties zu Favoriten erklären und diese waren dann Klassenbezogen identisch.
Vieleicht bitten wir Daniel (Uwe) den QT zur Verfügung zu stellen um dieses immer aktuell zu halten. Da die ToolsAPI bestimmt abwärtskompatibel ist, ist die alte Version bestimmt einfach anzupassen.

Das ist ja noch besser als gedacht

[haentschman]

Ja funktioniert es denn? Wenn ja mit welchem Delphi? Ich kann nur bis XE mitreden. Ich meine es mal mit XE5 erfolglos probiert zu haben. Das würde mir in neueren Versionen durchaus fehlen.

[ChristianZ]

Zitat von mkinzler:

Die Frage ist nur, wie man das implementiert, da es ja nicht reicht neue Kategorien anlegen zu lassen, man muss die Properties ja auch entsprechend zuordnen und diese auch Verwalten. Dies müsste ja für jede Komponente indivuell verwaltet werden; nur anhand der Bezeichnung der Property wäre ja sehr ungenau.

Aber zumindest wäre es ähnlich der jetzigen Suchfunktion schon eine ganze Ecke besser, als bisher.
Generell gebe ich Dir aber Recht - pro Komponente(n) wäre sinnvoll.