Properties im Published-Abschnitt für den OI "unsichtbar"

[iCode4You]

äh so langsam fehlt mir der überblick... Die Grundfrage waren doch die abhängigkeiten zwischen einzelnen published props !
und um die zu lösen beim create(durch das streaming) kann man loaded überschreiben oder onCreate wobei ich mir da nicht sicher bin
und private "Fields" können selbstverständlich im Konstruktor vorinitialisiert werden.

[tommie-lie]

Hab' ich jetzt 'nen Denkfehler? :gruebel:

Zitat:

Zitat von Wheelie

unter anderem entscheidet er sich auch, ob das pendel einen automatischen massstab besitzen soll oder nicht (property AutoMassstab: Boolean read FAutoMassstab write SetAutoMassstab;). wenn er nun F9 drückt wird die klasse neu instanziert und delphi weist diesem neuen objekt die vom benutzer festgelegten eigenschaften nacheinander zu, und zwar genau so, wie sie im published-abschnitt vorkommen -> zuerst AutoMassstab, dann Pendellaenge etc. allerdings werden NUR die properties des published-abschnitts zugewiesen (logisch, denn nur die kann der anwender verändert haben).

Der Benutzer legt für jedes published Property fest, welchen Wert es haben soll. Das kann er nur im OI machen. Jetzt sollen PixelInMeter und PixelLaenge nicht im OI erscheinen, also kann sie der Anwender auch nicht mit einem bestimmten Wert vorbelegen. Dementsprechend ist es doch vollkommen egal, wann diese beiden Properties mit (ohnehin unsinnigen) Werten gefüllt werden, da sie ja nicht vom Anwender stammen, für dich also vollkommen belanglos sind. Anhand der Namen vermute ich, daß es mit dem Maßstab zusammenhängt, wie wäre es, im OnCreate bei gesetztem AutoMassstab eine passende Größe für die beiden Properties zu berechnen? Ist für mein Verständnis irgendwie egal... Allerdings weiß ich nicht, wie Properties zur Laufzeit gehandhabt werden, ob sie in OnCreate also schon mit sinnvollen Werten belegt sind und ob die entsprechenden Access-Methods aufgerufen werden. :duck: Ansonsten sehe ich aber kein Problem darin, die beiden Properties public zu deklarieren und beim Laden der Komponente anhand des Wertes von AutoMassstab zu berechnen, oder eben nicht.

Ansonsten solltest du auf das Gummibärchen hören, und dafür sorgen, daß es deine Komponente nicht interessiert, welches Property nun zuerst gesetzt wird, zum Bleistift durch On-Demand-Abfrage der Werte (sprich beim Zeichnen auf den Bildschirm, wenn sich nichts mehr ändert). :zwinker:

[DP-Maintenance]

Dieses Thema wurde von "Christian Seehase" von "Programmieren allgemein" nach "Sonstige Fragen zu Delphi" verschoben.
Ein delphispezifisches Problem

[maximov]

Zitat:

Zitat von iCode4You

äh so langsam fehlt mir der überblick... Die Grundfrage waren doch die abhängigkeiten zwischen einzelnen published props !
und um die zu lösen beim create(durch das streaming) kann man loaded überschreiben oder onCreate wobei ich mir da nicht sicher bin
und private "Fields" können selbstverständlich im Konstruktor vorinitialisiert werden.

Ja. Um temporale abhängigkeiten zu vermeiden bietet es sich tatsächlich an, Loaded zu überschreiben und dort sämtliche vor-berechnungen aufzurufen. Man will aber trotzdem beim setzen der properties aktionen tätigen, aber nicht beim laden - also fragt man das objekt, in den settern, ob es gerade geladen wird

Delphi-Quellcode:

if csLoading in ComponentState then exit;

Und schon ist man nicht mehr abhängig von der streamin-order :mrgreen:

[Muetze1]

Moin!

Zitat:

Zitat von SirThornberry

@Muetze: Ich muss dich leider enttäuschen, du kannst dich nicht darauf verlassen das die Properties dann in alphabeticher Reihenfolge gesetzt werden, du solltest deine Komponenten so schreiben das es egal ist welches Property zuerst gesetzt wird.

Ja, und? Was habe ich denn in meinem Beitrag behauptet? Mir ging es um die Sichtbarkeit und auf die Reihenfolge bin ich nicht eingegangen - und bei meinen ist die Reihenfolge immer egal.

Zitat:

Zitat von Pseudemys Nelsoni

Zitat:

properties im private-abschnitt werden erst gar nicht zugewiesen

kannst doch im OnCreate deiner Kompo machen, oder?

Ja, aber dann braucht es auch nicht mehr in die DFM, da es eh immer gesetzt wird.

MfG
Muetze1