Objektinspektor

[TigerLilly]

Gibt es im Objektinspektor eigentlich eine Möglichkeit, Änderungen rückgängig zu machen oder Properties bzw die Gruppen auf ihren Default zurückzusetzen?

[Rollo62]

Meines Wissens nicht, das wäre aber ein schöner Feature-Request den ich mir auch manchmal wünschen würde.
Vielleicht hat CnPack/GExperts so eine versteckte Funktion, ich glaube aber nicht.

Ich würde vor großen Änderungen vorher ein Backup sichern, aber in der Praxis macht man dass dann doch nicht.

[dummzeuch]

Zitat:

Zitat von TigerLilly (Beitrag 1519811)

Gibt es im Objektinspektor eigentlich eine Möglichkeit, Änderungen rückgängig zu machen oder Properties bzw die Gruppen auf ihren Default zurückzusetzen?

Rechtsklick auf ein Property -> Default sollte es eigentlich geben.

Was im Prinzip auch geht: Umschalten des Formulars auf Textdarstellung und die nicht gewünschten Einstellungen rauslöschen. Das setzt sie auf Default zurück.

Änderungen rückgängig machen gibt es nicht, aber dazu hat man eine Sourcecodeverwaltung, insofern ist das nicht ganz so schlimm.

[himitsu]

Und manuell geht natürlich auch.
Alt-F12, das Property löschen und wieder Alt+F12
(vorher mit F12 in den Designeditor und natürlich geht es auch über Menü oder Kontextmenü)

Jupp, rückgängig zu "alten" Werten via Codeverwaltung
oder auch über die __Historie.
(oder ohne Speichern schließen und wieder auf :stupid:)

Wenn keine Versionsverwaltung, dann schadet es nicht das History-Limit hochzusetzen.



History und auch GIT/SVN/HG innerhalb der IDE haben nur einen Nachteil ... OK, Zwei:
* Änderungen über mehrere Dateien (auch PAS und DFM getrennt) sind schwer/umständlich "gemeinsam" zu handhaben.
* Es gibt ein Limit und standardmäßig nach zu geringer Antahl flegen diese "Backups" weg.
* Dank dem neueren Recovery gibt es auch keinen Grund mehr für das schwachsinnige AutoSave ... welches sinnlos die History zumüllt und somit schneller löscht
* Und wer vorallem für das blöde AutoSave das "Rückgängig nach Speichern" nicht aktiviert hat, der hat auch nochmal Pech verdient.

[Uwe Raabe]

Das hört sich einfacher an als es ist. Für Properties, die ihren Default-Wert über ein Attribut der das Keyword

Delphi-Quellcode:

default

veröffentlichen, könnte man etwas implementieren. Wenn es aber im z.B. die Standardgrößen eines TButtons geht wird es schwieriger. Die werden zwar auch im Create gesetzt, aber nirgendwo sind diese Werte als Default zu erkennen. Das sieht man z.B. daran, dass die im Objektinspektor fett dargestellt werden, wie andere vom Defaultwert abweichende auch.

[himitsu]

Jupp, daher auch aus der DFM löschen, die ganze Zeile.

Werden sie danach nicht mehr geladen (überschrieben), dann behalten sie ihren "Default".
Aber kam der Default vom Designer (nicht vom Create), dann würde das das auch nichts helfen.


Für "Default-Zurücksetzen" müsste sich der Designer oder die Komponenten sich im AfterCreate/Loaded/oderso die "alten" Werte merken. (was er/sie nicht machen)
oder man müsste die "ursprüngliche" DFM nochmals laden, im Hintergrund, um damit zu vergleichen. (ähnlich der Form-Vererbung)

[TigerLilly]

Zitat:

Zitat von dummzeuch (Beitrag 1519816)

Rechtsklick auf ein Property -> Default sollte es eigentlich geben.

Nope. Zumindest nicht bei 11.3.

Zitat:

Was im Prinzip auch geht: Umschalten des Formulars auf Textdarstellung und die nicht gewünschten Einstellungen rauslöschen. Das setzt sie auf Default zurück.

Ja, so mach ich das jetzt. Das Problem ist nur, dass man nicht immer weiß/erkennt, welche man geändert hat.

Zitat:

Änderungen rückgängig machen gibt es nicht, aber dazu hat man eine Sourcecodeverwaltung, insofern ist das nicht ganz so schlimm.

Ich bin grad am Ausprobieren eines Grids, welche Properties in welcher Kombination was bewirken. Von Einchecken etc bin ich da noch weit enetfernt.

[dummzeuch]

Zitat:

Zitat von Uwe Raabe (Beitrag 1519820)

Das hört sich einfacher an als es ist. Für Properties, die ihren Default-Wert über ein Attribut der das Keyword

Delphi-Quellcode:

default

veröffentlichen, könnte man etwas implementieren. Wenn es aber im z.B. die Standardgrößen eines TButtons geht wird es schwieriger. Die werden zwar auch im Create gesetzt, aber nirgendwo sind diese Werte als Default zu erkennen. Das sieht man z.B. daran, dass die im Objektinspektor fett dargestellt werden, wie andere vom Defaultwert abweichende auch.

Das könnte man herausfinden, in dem man einen neuen Button erzeugt und in enen Memory-Stream schreibt. Ist aber natürlich trotzdem ein Hack.

[dummzeuch]

Zitat:

Zitat von TigerLilly (Beitrag 1519822)

Zitat:

Zitat von dummzeuch (Beitrag 1519816)

Rechtsklick auf ein Property -> Default sollte es eigentlich geben.

Nope. Zumindest nicht bei 11.3.

Hm, in Delphi 2007 Englisch: "Revert to inherited" (andere habe ich gerade nicht zur Hand).
Ich habe das aber bisher eigentlich noch nie benutzt.

[Uwe Raabe]

"Revert to inherited" setzt bei Visual Form Inheritance die Einstellungen auf den geerbten Wert zurück - funktioniert aber selbst da nicht immer.

[himitsu]

Zitat:

Zitat von TigerLilly (Beitrag 1519822)

Das Problem ist nur, dass man nicht immer weiß/erkennt, welche man geändert hat.

Dafür gibt es doch das __History bzw. die Code-Versionierung(en) :roll:

[Benmik]

Wenn es um das Zurücksetzen auf Standardwerte geht, verstehe ich nicht ganz. Kann man das nicht automatisieren, indem man z.B. einen TButton erzeugt, per RTTI alle Properties ausliest und diese Werte dann als Standard setzt?

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1519834)

Kann man das nicht automatisieren, indem man z.B. einen TButton erzeugt, per RTTI alle Properties ausliest und diese Werte dann als Standard setzt?

Das hatte Thomas ja schon vorgeschlagen. Es bleibt aber eben ein böser Hack. Bei manchen Controls kann das auch zu Problemen führen, wenn sie irgendwelche Nebeneffekte haben oder womöglich nicht mehrfach existieren dürfen.

Ein generelles Feature um einzelne oder alle Properties auf den Defaultwert zurückzusetzen wäre sicher auch für andere Bereiche interessant. Das erfordert aber vermutlich eine konsistente Umsetzung seitens der Entwickler diverser Component Libraries. Erfahrungsgemäß ist die Akzeptanz in dem Bereich aber eher etwas zurückhaltend.

[Benmik]

Ja, aber ich hatte nicht verstanden, warum Thomas den Button streamen wollte und warum das ein Hack sein soll, ein böser noch zumal. Man erzeugt den Button im Speicher, liest seine Werte ein und gibt ihn wieder frei, nichts Permanentes also. Was ist daran programmier-moralisch verwerflich?

[dummzeuch]

Zitat:

Zitat von Benmik (Beitrag 1519842)

Ja, aber ich hatte nicht verstanden, warum Thomas den Button streamen wollte und warum das ein Hack sein soll, ein böser noch zumal. Man erzeugt den Button im Speicher, liest seine Werte ein und gibt ihn wieder frei, nichts Permanentes also. Was ist daran programmier-moralisch verwerflich?

Mit einem TButton funktioniert das vermutlich. Aber das ist ja auch eines der einfacheren Controls. Stell Dir das mal mit einem TChart Control vor. Es ist ein Hack, weil es eine Funktionalität zu einem Zweck benutzt, für den sie nicht gedacht ist.
Über das "böse" könnte man streiten.

[himitsu]

Es gibt auch viele Controls, die nur "sichtbar" richtig arbeiten.
z.B. der ActiveX-Schrott von Adobe lässt sich nicht wirklich ohne ein sichtbares Parent-HWND erzeugen.

Und wie bereits erwähnt, gibt es einige Komponenten, welche nur einmal, zur selben Zeit, innerhalb einer Anwendung existieren können/dürfen.


Aber ja, im Allgemeinen kann man sich eine unsichtbare Form und darauf die Komponente erzeugen, dann die Werte auslesen und alles wieder freigeben,
und wenn es knallt, dann geht es eben nicht.

[Benmik]

Mit so einem pragmatischen Ansatz wird man vermutlich sehr weit kommen. Wobei ich grübele, wozu TigerLilly das braucht. Aber irgendetwas wird es sein.

[TigerLilly]

Zitat:

Zitat von Benmik (Beitrag 1519850)

Wobei ich grübele, wozu TigerLilly das braucht. Aber irgendetwas wird es sein.

Da kann ich dir helfen: Ich bin grad am Ausprobieren eines Grids, welche Properties in welcher Kombination was bewirken. Aber ich muss zugeben - der Prozess dabei ist durchaus optimierbar.

Am besten bisher funktioniert: Alt-F12 + kopieren des Teils aus der DFM. Properties ändern - ausprobieren. Und wieder Alt-F12 und Paste.

[BerndS]

Womöglich würde es zum probieren reichen, das Formular abzuleiten und hier zu testen.
Da könnte mam mit

Zitat:

["Revert to inherited" setzt bei Visual Form Inheritance die Einstellungen auf den geerbten Wert zurück - funktioniert aber selbst da nicht immer.
Uwe Raabe]

die Änderungen zurücksetzen falls es funktioniert.

[dummzeuch]

Zitat:

Zitat von TigerLilly (Beitrag 1519861)

Am besten bisher funktioniert: Alt-F12 + kopieren des Teils aus der DFM. Properties ändern - ausprobieren. Und wieder Alt-F12 und Paste.

Hm, ich überlege gerade, ob sich das mit einem IDE-Plugin automatisieren ließe...
Sowas wie "Restorepoint speichern" -> "auf Restorepoint zurücksetzen" müsste eigentlich machbar sein. Auf der anderen Seite ist das ja eigentlich nichts anderes als die Historie, die es schon gibt, nur vielleicht mit einem sprechenden Namen.

Aber ich habe sowieso wieder keine Zeit dafür. :-(

[ConnorMcLeod]

Eine Ableitung machen und die Properties im constructor setzen?
Oder im FormShow setzen?
Dann wären die Änderungen in der History.

[himitsu]

.PAS und .DFM findet man in der __History
ebenso .DPR und .DPK
und auch sonst alles Anderes, was man im Editor bearbeitet, wie z.B. .H und .MD

nur leider nicht die .DPROJ


aber dafür seh ich eine .DPROJ.LOCAL :freak: