Von Seattle nach Berlin

[Sherlock]

Ich hatte es angedroht, jetzt ist es getan. Seattle ist installiert. Ich habe jedoch nicht wenig Lust es grad wieder zu löschen. Meine FMX-Anwendung (ohne Fremdkomponenten) die in Seattle mit 0 Warnungen und 0 Fehlern ohne Tricks wie RTTI, Compilerswitche und sonstigen Schabernack erzeugt wird, rennt in Berlin prompt gegen eine Mauer...hmmm, Nomen est Omen?

Erster sichtbarer Grund ist, daß TListViewItems keinen Parent mehr haben. Das ist...Wow! Weil eigentlich hat doch jedes TControl ein Parent. Ich nutze die Eigenschaft um zu erfahren woher denn das ListViewItem kommt, das gerade in einem recht allgemeinen Event behandelt wird. Ich muss jetzt mal in mich gehen. Gute Nacht

Sherlock

[Jumpy]

Zitat von Sherlock:

Ich hatte es angedroht, jetzt ist es getan. Seattle ist installiert.

Ich vermute in dem Satz müsste es Berlin heißen???

[Sherlock]

@Himitsu: Ah, das wäre ein guter Ansatz, ich verfolge den mal.

Zitat von Jumpy:

Zitat von Sherlock:

Ich hatte es angedroht, jetzt ist es getan. Seattle ist installiert.

Ich vermute in dem Satz müsste es Berlin heißen???

Absolut... Waren wohl meine Hirnwindungen nach der Enttäuschung verknotet.

Sherlock

[Harry Stahl]

Das Listview-Control wurde ja bereits in Delphi Seattle intern heftig umgestrickt:

http://docwiki.embarcadero.com/RADSt...nts_in_Seattle

Während diese Änderungen erklärt wurden, fehlt diesmal ein Hinweis.

Bislang hatte das TListviewItem die Parent-Eigenschaft vom "TListItem" geerbt.

Nunmehr hat TListItem aber keine Parent-Eigenschaft mehr, stattdessen besitzt aber das TListviewItem ein privates Feld "FPresentationParent" vom Typ "IListViewPresentationParent"
Wenn ich das richtig verstanden habe, ist das quasi ein Ersatz für die bisherige Parent-Eigenschaft.

Vielleicht haben hier die Interface-Profis einen Tipp, wie man auf diese private Variable zugreifen kann und damit den "Parent" (Listview) bestimmten kann.

Ansonsten kannst Du als schnellen WorkAround zur Not, wenn Du das TListviewItem erzeugst, dessen Eigenschaft "Tag" verwenden, um dort das Listview zu speichern, welches der "Parent" des ListviewItems ist.

Was da warum und genau abläuft, habe ich so auf die Schnelle leider auch nicht verstanden, habe aber den Eindruck, es handelt sich bei den vorgenommenen Änderungen (begonnen in Seattle) insgesamt um ein Bemühen, die Datenschicht stärker von der Präsentation zu trennen.

Ärgerlich ist die "einfach so" Änderung ohne Hinweise auf jeden Fall mal wieder, insofern kann ich Deinen Unmut gut verstehen.

Insgesamt bliebe aber m.E. zu klären, ob man die aktuelle Situation als "Bug" qualifizieren muss und somit eine QC-Meldung angebracht wäre.

[Mavarik]

Sicherlich ein Grund, warum in keinem Beispiel (Video und Source)
die Listview NIE nativ angesprochen wird, sondern immer nur mir den Livebindings...

[Sherlock]

Dabei benutzt man doch das ListView auch für eine Art Menü durchaus öfter. Soll man sich etwa dafür ein DataSet basteln? Die Beispiele sind eh alle ziemlich hanebüchen und weltfremd, aber darüber beschwere ich mich schon lange nicht mehr

Ich bin schon dabei alles umzubauen und kann vermutlich bald auf die Parent-Property bzw. einem Äquivalent ganz verzichten. Dann bekommt Berlin noch eine Chance.

Sherlock

[himitsu]

Das VCL-Item hat neben Owner/Parent noch ein Property TListItem.ListView, sowas werden die hier doch bestimmt auch irgendwo haben.

Überlegung: Vielleicht ist das Item jetzt keine "eigene" visuelle Komponente in der ListView mehr, sondern hält nur noch die Daten und wird von/in/auf den ListView gemalt.