![]() |
Re: StringList weiter reichen zur Eigentliche Klasse
das mit Override habe ich schon.
Du meinst es könnte damit was zu tun habe, da nirgend geklärt ist das es sich um eine TStringList handelt ? sondern "nur" um eine TStrings ? Aber auch als das klar war, hat es nicht geklappt. Ich habe im Create ja schonmal gesagt, das es sich um eine TStringList handelt und alle Items manuel per addObject hinzugefügt, klappte aber auch nicht. |
Re: StringList weiter reichen zur Eigentliche Klasse
wenn ich das so habe:
Delphi-Quellcode:
sehe ich was in der Listbox und die Writeln Meldung wird ausgeben.
procedure TPlaylistenManger.SetPlaylistItems(const AValue: TStrings);
begin //fPlaylistItems.Assign(AValue); fPlaylistItems:=TStringList(AValue); end; procedure TPlaylistenManger.LoadFromFile(const aFileName: String = ''); var i:integer; begin InitPlaylist(ExtractFileName(aFileName),Playliste); Playliste.OhneExt:=OhneExt; Playliste.PlayListItems:=TStringlist(PlayListItems); Playliste.LoadFromFile(aFileName); writeln(PlayListItems.text); // PlayListItems.Assign(Playliste.PlayListItems); _ext:=Playliste.ext; end; Das Problem jedoch sobald ich versuche von einer anderen Procedure aus auf PlayListItems.Text zuzugreifen, ist diese Leer. Aber genau das ist gerade für mein vorhaben wichtig. Das das nicht so ist. |
Re: StringList weiter reichen zur Eigentliche Klasse
Nein, TStrings reicht. Der Typecast ist unsinnig und braucht nicht getan werden im Constructor sowie im LoadFromFile().
Meine Frage zu dem Code: Was ist "Playliste" für ein Typ und was macht er mit PlayListItems? |
Re: StringList weiter reichen zur Eigentliche Klasse
Ich habe mir das so gedacht:
Ich verbinde die TStrings von der Playlistmanger klasse z.b. mit der Listbox.Items. Jetzt lade ich eine Playliste - meiner wahl z.b. eine m3u(später sollen noch mehr folgen), anhand der Datei Endung wird der Playlisten Typ in der Procedure InitPlaylist Ermittelt und gesetzt. In der TPlayListM3U.LoadFromFile soll PlayListenItems(von typ TStrings) gefült werden. dazu wird er von TPlaylistenManger.LoadFromFile gesetzt. Playliste ist von typ TPlaylistBase das kann im Moment nur eine TPlayListM3U sein. Alle Playlisten müssen von TPlaylistBase abgeleitet werden. TPlaylistBase stellt im wesentlichen zwei Methoden zuverfügung: Laden und Speichern. Ich kann mir den Fehler immer noch nicht Erklären. Gut den Typ Cast mache ich wieder weg. |
Re: StringList weiter reichen zur Eigentliche Klasse
So sehe ich auch erstmal keinen Fehler. Grundlegend: Kannst du den Code zippen (der reine Playlistenteil, also Manager + BasePlaylist + M3U Ableitung reicht ja) und hier mal anhängen? Ich würde dann mal reinschauen. Wir haben ja heute Feiertag...
|
Re: StringList weiter reichen zur Eigentliche Klasse
Liste der Anhänge anzeigen (Anzahl: 1)
ja ! ist kein Problem, ist aber ein Lazarus Projekt.
Aber ich nutzte allgemeine Sachen. du müsstest nur eine eigene Oberfläche Bauen Vielen Dank für deine Hilfe. Ich hoffe du findest den Fehler. Also dir ist klar, was ich möchte ? Aber im Prinzip müsste es doch so gehen oder nicht ? (habe die Typcast noch nicht entfernt) |
Re: StringList weiter reichen zur Eigentliche Klasse
Liste der Anhänge anzeigen (Anzahl: 1)
Ok, es lag nur daran, dass du im Manager noch ein Assign() anstatt der Zuweisung drinne hattest.
Folgende Punkte: 1. Denk dran, dass du alle Instanzen von TInfo die du angelegt hast auch selber wieder freigeben musst. Die Listbox kümmert sich nicht darum! 2. Ich habe "Kommentar" mal verbessert - nur mal so nebenbei 3. Warum ist der Parameter Filename bei LoadFromFile() optional? Ich brauch die Methode Loadfromfile nicht aufrufen, wenn ich keinen Dateinamen habe. Beim speichern sehe ich dass ein: keine Angabe heisst: Speicher unter original geladenem Namen. Aber beim Laden? Ich habe das mal abgeändert. 4. Der Destruktor ist schon virtuell (muss er auch sein), somit zerschiesst du die gesamte Kette der Aufrufe mit der Deklaration eines virtuellen Destruktors in deiner Basisplaylistklasse. Ich habe es abgeändert. 5. Warum definierst und implementierst du Constructoren und Destructoren, wenn sie keinen Code beinhalten? Dies ist nicht nötig und macht den Code nur grösser und damit unleserlicher. 6. Ich habe ein paar Resourcen-Schutzblöcke eingefügt (try/finally), damit die temporären Instanzen auch im Falle eines Fehlers (Exception) wieder ordentlich freigegeben werden. 7. Alles was du direkt nach "class" deklarierst, ist public (oder sogar published). Damit ist es öffentlich einseh- und zugreifbar. (TPlaylistenManager) 8. Beim setzen einer neuen Instanz für die PlaylistenItems (also einer anderen Listbox o.ä.), muss diese Änderung mit durchgereicht werden, so dass die eigentliche Playlist auch die richtige Instanz hat. (siehe SetPlaylistItems()) 9. Was macht InitPlaylist() wenn er die Endung nicht kennt? Die Variable wird nicht initialisiert und somit weisst du nicht, ob du eine gültige Instanz in fPlayliste hast nach dem Aufruf oder nicht. 10. TPlaylistenManager.SaveToFile() ruft InitPlaylist() auf, damit erstellst du eine neue Instanz und überschreibst die vorhandene Instanz in fPlayliste Korrigierte Version im Anhang. |
Re: StringList weiter reichen zur Eigentliche Klasse
Zu 1: Danke ! Irgendwie dachte ich das würde TStrings auto. tuen bei der Freigabe.
Zu 2: Danke ! Zitat:
zu 4: Wenn du das bei der PlaylistBase meinst, ja, weil er soll ja was machen, und es soll überschrieben werden können, wenn es nötig ist. zu 5: Als Vorbereitung, es kann ja sein, das ich später dort Variablen Definieren möchte. zu 6: Danke. zu 7: Ich weiß, aber das ist auch published sein kann, ist mir neu. Vielen Dank, für deine Mühe, ich glaube das ist das erste mal seit dem ich hier im Forum bin das jemand meinen Soruce-Code zu genau unter die Lupe nimmt. Das ist ein Teil von ![]() ich werde dich auf jeden Fall erwähnen. Zitat:
![]() also nach einen ersten test geht es immer noch nicht so wie ich es wollte. Wenn ich von ausen auf writeln(PlayListeManger.PlayListItems.Text); zugreife ist diese Eigenschaft leer. In der Listbox sehe ich aber Einträge. |
Re: StringList weiter reichen zur Eigentliche Klasse
PlayListeManger ist im TFrom1 Definiert
|
Re: StringList weiter reichen zur Eigentliche Klasse
Zitat:
Zitat:
Zitat:
Delphi-Quellcode:
ist dies das gleiche wie
type
type TMyClass = class end;
Delphi-Quellcode:
Das erste ist nur eine Kurzform. Du leitest immer (sofern du nichts anderes angibst) von TObject ab. Somit erbst du automatisch den als virtuell deklarierten Destructor von TObject. Du hast somit schon einen als virtuell deklarierten Destruktor.
type
TMyClass = class(TObject) end; Wenn du nun in TPlaylistBase deinen Destruktor definierst und virtual; dahinter vermerkst, dann führst du einen neuen Destruktor ein mit dem gleichen Namen und verdeckst den von TObject. Dadurch wird aber jeder Destructor-Aufruf der bei dem TObject.Destroy ankommt nicht mehr an dich weiter geleitet. Free, FreeAndNil() etc. rufen immer den Destruktor vom Typ TObject auf und somit wird deiner niemals aufgerufen. Und damit in abgeleiteten Klassen trotzdem immernoch der Destruktor aufgerufen wird, muss dieser virtuell sein und in nachfolgenden Klassen überschrieben werden. Somit: Nimm das virtual weg! Zitat:
Zitat:
Aber zu deinem Problem: Du rufst InitPlaylist() o.ä. im Manager auch vor dem Speichern auf. Dadurch legst du eine neue Instanz an. Rufst du vllt. das Speichern auf? Ich schaue nochmal in mein Project und teste explizit. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:54 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-2025 by Thomas Breitkreuz