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???

[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.

[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

[greenmile]

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.

[Harry Stahl]

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:

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;

Wenn man nun eine Unit Namens "CLHelperLVItem" erstellt, die dann unter uses, im Implementation Abschnitt einbindet:

Delphi-Quellcode:

mplementation

{$R *.fmx}

uses CLHelperLVItem;

Dann läuft es wieder.

Die ClassHelper Unit sieht so aus:

Delphi-Quellcode:

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.

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.

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).

[Sherlock]

Ja, Super Idee! Werde ich so nutzen, und schauen, was die nächste Berliner Überraschung sein wird.



Sherlock