![]() |
Von Seattle nach Berlin
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 |
AW: Von Seattle nach Berlin
Zitat:
|
AW: Von Seattle nach Berlin
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. |
AW: Von Seattle nach Berlin
@Himitsu: Ah, das wäre ein guter Ansatz, ich verfolge den mal. :thumb:
Zitat:
Sherlock |
AW: Von Seattle nach Berlin
Das Listview-Control wurde ja bereits in Delphi Seattle intern heftig umgestrickt:
![]() 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. |
AW: Von Seattle nach Berlin
Sicherlich ein Grund, warum in keinem Beispiel (Video und Source)
die Listview NIE nativ angesprochen wird, sondern immer nur mir den Livebindings... |
AW: Von Seattle nach Berlin
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 :D
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 |
AW: Von Seattle nach Berlin
Darüber bin ich auch prompt gestolpert und habe nichts gefunden. Mir blieb nichts anderes übrig als über alle Komponenten zu gehen und den Parent zu suchen. Naja, zumindest im ersten Schritt. Vier Schritte weiter habe ich dann kapituliert und entschieden, erstmal bei Seattle zu bleiben.
|
AW: Von Seattle nach Berlin
Wenn man den von mir erwähnten Weg (temporär) nutzen will, dann könnte man das auch in Zusammenhang mit einem Classhelper machen.
Vorteil wäre, dass der bisherige Code compiliert und falls die Entfernung der parent-Eigenschaft ein Bug gewesen sein sollte, und man die wieder rein bringen sollte, dann entfernt man einfach den Verweis auf die Unit, welche den ClassHelper enthält und alles ist wieder beim alten. Konkretes Beispiel, der folgende Code compilierte und lief unter Seattle ordnungsgemäß, unter Delphi Berlin nicht mehr (überall wo man die entfernte Parent-Eigenschaft verwenden will, meckert der Compiler rum):
Delphi-Quellcode:
Wenn man nun eine Unit Namens "CLHelperLVItem" erstellt, die dann unter uses, im Implementation Abschnitt einbindet:
procedure TForm25.FormCreate(Sender: TObject);
var L: Integer; TL: TListViewItem; begin for L := 0 to 10 do begin TL := TListviewItem (listview1.Items.Add); TL.parent := Listview1; // *Mark TL.Text := 'ItemA' + L.ToString + TL.Parent.ClassName; end; end;
Delphi-Quellcode:
Dann läuft es wieder.
mplementation
{$R *.fmx} uses CLHelperLVItem; Die ClassHelper Unit sieht so aus:
Delphi-Quellcode:
Das einzige: Man muss sich um das setzen der Parent-Eigenschaft selbst kümmern (siehe oben, Stelle "*Mark"). Meistens haben die Anwender das aber sowieso schon gemacht, wenn nicht, müsste man das an diesen Stellen nachholen.
unit CLHelperLVItem;
interface Uses System.Types, System.UITypes, System.Classes, FMX.Types, FMX.Controls, FMX.ListView.Types, FMX.ListView.Appearances, FMX.ListView.Adapters.Base, FMX.ListView; Type TMListViewItemHelper = Class helper for TListviewitem private function GetParent: TControl; procedure SetParent (Control: Tcontrol); public property Parent: TControl read GetParent write SetParent; end; implementation { TMListViewItemHelper } function TMListViewItemHelper.Getparent: Tcontrol; begin Result := TControl (Tag); end; procedure TMListViewItemHelper.SetParent (Control: TControl); begin Tag := LongInt (Control); end; end. Wie gesagt Vorteil ist, dass der alte Code überwiegend oder ganz ohne Änderungen laufen sollte und man bei einem späteren Bugfix (Wiedereinführung von "Parent") nur den Verweis auf den Classhelper entfernen muss. Der WorkAround geht natürlich nur, wenn man die TAG-Eigenschaft bislang nicht anderweitig verwendet hatte (neue Felder darf man ja den Class Helpern leider nicht zufügen, daher musste ich an was existierendes anknüpfen). |
AW: Von Seattle nach Berlin
Ja, Super Idee! Werde ich so nutzen, und schauen, was die nächste Berliner Überraschung sein wird.
:thumb: Sherlock |
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:56 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz