AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language StringList weiter reichen zur Eigentliche Klasse
Thema durchsuchen
Ansicht
Themen-Optionen

StringList weiter reichen zur Eigentliche Klasse

Ein Thema von mimi · begonnen am 30. Okt 2007 · letzter Beitrag vom 2. Nov 2007
Antwort Antwort
Seite 2 von 4     12 34      
mimi

Registriert seit: 1. Dez 2002
Ort: Oldenburg(Oldenburg)
2.008 Beiträge
 
FreePascal / Lazarus
 
#11

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 10:01
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.
Michael Springwald
MFG
Michael Springwald,
Bitte nur Deutsche Links angeben Danke (benutzte überwiegend Lazarus)
  Mit Zitat antworten Zitat
mimi

Registriert seit: 1. Dez 2002
Ort: Oldenburg(Oldenburg)
2.008 Beiträge
 
FreePascal / Lazarus
 
#12

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 10:40
wenn ich das so habe:
Delphi-Quellcode:
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;
sehe ich was in der Listbox und die Writeln Meldung wird ausgeben.
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.
Michael Springwald
MFG
Michael Springwald,
Bitte nur Deutsche Links angeben Danke (benutzte überwiegend Lazarus)
  Mit Zitat antworten Zitat
Muetze1
(Gast)

n/a Beiträge
 
#13

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 13:45
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?
  Mit Zitat antworten Zitat
mimi

Registriert seit: 1. Dez 2002
Ort: Oldenburg(Oldenburg)
2.008 Beiträge
 
FreePascal / Lazarus
 
#14

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 13:59
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.
Michael Springwald
MFG
Michael Springwald,
Bitte nur Deutsche Links angeben Danke (benutzte überwiegend Lazarus)
  Mit Zitat antworten Zitat
Muetze1
(Gast)

n/a Beiträge
 
#15

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 14:05
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...
  Mit Zitat antworten Zitat
mimi

Registriert seit: 1. Dez 2002
Ort: Oldenburg(Oldenburg)
2.008 Beiträge
 
FreePascal / Lazarus
 
#16

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 14:15
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)
Angehängte Dateien
Dateityp: zip playlisten_192.zip (3,4 KB, 3x aufgerufen)
Michael Springwald
MFG
Michael Springwald,
Bitte nur Deutsche Links angeben Danke (benutzte überwiegend Lazarus)
  Mit Zitat antworten Zitat
Muetze1
(Gast)

n/a Beiträge
 
#17

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 14:58
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.
Angehängte Dateien
Dateityp: zip playlisten_neu_945.zip (3,3 KB, 6x aufgerufen)
  Mit Zitat antworten Zitat
mimi

Registriert seit: 1. Dez 2002
Ort: Oldenburg(Oldenburg)
2.008 Beiträge
 
FreePascal / Lazarus
 
#18

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 15:30
Zu 1: Danke ! Irgendwie dachte ich das würde TStrings auto. tuen bei der Freigabe.
Zu 2: Danke !
Zitat:
Warum ist der Parameter Filename bei LoadFromFile() optional? Ich brauch die Methode Loadfromfile nicht aufrufen
Wenn im Playlisten Manger der Parameter FileName schon mit einem namen belegt ist, kann dieser Auto. genommen werden bei LoadFromFile, wenn der nicht genommen werden soll, muss man im LoadFromFile einen Parameter eingeben

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 http://www.delphipraxis.net/internal...t.php?t=119063,
ich werde dich auf jeden Fall erwähnen.

Zitat:
// FileName:=''; // alle member sind automatisch 0, 0.0, false bzw. ''
dazu gibt es hier einen schönen Thread:
http://www.lazarusforum.de/viewtopic.php?t=1022

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.
Michael Springwald
MFG
Michael Springwald,
Bitte nur Deutsche Links angeben Danke (benutzte überwiegend Lazarus)
  Mit Zitat antworten Zitat
mimi

Registriert seit: 1. Dez 2002
Ort: Oldenburg(Oldenburg)
2.008 Beiträge
 
FreePascal / Lazarus
 
#19

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 15:33
PlayListeManger ist im TFrom1 Definiert
Michael Springwald
MFG
Michael Springwald,
Bitte nur Deutsche Links angeben Danke (benutzte überwiegend Lazarus)
  Mit Zitat antworten Zitat
Muetze1
(Gast)

n/a Beiträge
 
#20

Re: StringList weiter reichen zur Eigentliche Klasse

  Alt 31. Okt 2007, 16:16
Zitat von mimi:
Zu 1: Danke ! Irgendwie dachte ich das würde TStrings auto. tuen bei der Freigabe.
Ja, hatte ich vermutet. Dies ist aber nicht der Fall, da die TStrings nichtmal wissen, ob da wirklich eine Instanz hinterlegt ist oder der Programmierer nicht vllt. einfach nur einen Integer reinpackt.

Zitat von mimi:
Wenn im Playlisten Manger der Parameter FileName schon mit einem namen belegt ist, kann dieser Auto. genommen werden bei LoadFromFile, wenn der nicht genommen werden soll, muss man im LoadFromFile einen Parameter eingeben
Ok, das widerspricht ja nicht meiner Anpassung, schliesslich kann der Manager schauen ob sein Aufruf mit '' war und entsprechend den internen Filename weiterreichen zu der Playlist Instanz.

Zitat von mimi:
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.
Kannst du doch. Wenn du sowas schreibst:
Delphi-Quellcode:
type
type
  TMyClass = class
  end;
ist dies das gleiche wie
Delphi-Quellcode:
type
  TMyClass = class(TObject)
  end;
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.

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 von mimi:
zu 7: Ich weiß, aber das ist auch published sein kann, ist mir neu.
Sie bei den Formularen: Füge eine Komponente ein. Sie wird direkt unter dem class eingefügt und ist aber von einer anderen Unit aus zugreifbar. Diese Elemente sind mindestens public, mMn aber sogar published (wegen dem Streaming zum wiederfinden der Komponenten beim Streaming).

Zitat von mimi:
also nach einen ersten test geht es immer noch nicht so wie ich es wollte.
Ich habe ehrlich gesagt nur so über den Quellcode geschaut und geändert. Da das Assign() so offensichtlich war, habe ich nicht weiter geschaut.

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.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 4     12 34      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:54 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz