methoden sind nach vererbung nicht mehr bekannt [gelöst]

cbs · Beiträge: 207 Erhaltene Danke: 1

moin leuts

ich hab ein problem mit der vererbung

ich habe mir eine klasse geschrieben (TParser) die methoden enthält um eine webseite zu parsen

jetzt möchte ich neue klassen erstellen die von TParser abgeleitet sind und verschiedene Daten aus der Seite rauslesen mit hilfe der methoden von TParser

deklariert habe ich das folgendermaßen:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

TParser = class(TObject)
private
  FPage: string;
  {...}
public
  function LoadPage(URL: string): Boolean;
  {...}
end;

TDataList = class(TParser)
private
  FList: TList;
  {...}
public
  constructor Create;
  destructor Destroy; override;
  {...}
end;

das problem ist das die methoden von TParser nicht mehr in TDataList auftauchen. ich habe schon probiert die methoden als protected oder public zu deklarieren. aber die methoden sind nicht mehr in TDataList bekannt abwohl TDataList ja eindeutig von TParser abgeleitet ist.

die beiden klassen liegen in unterschiedlichen units. die unit von TParser ist aber in der unit von TDataList mit eingebunden. daran sollte es eigenltich nicht liegen

wo liegt da das problem?

danke schonmal!

TomT · Beiträge: 116 Suse 9.1 WinXP D6 Pers

Es könnte sich um einen Konflikt handeln, da es in Delphi schon eine Klasse TParser gibt.

MFG TomT

_________________
...und da wurde mir klar, dass eine Toolbar keine Kneipe für Heimwerker ist.

UC-Chewie · Beiträge: 531 WinXP D5 Ent

Wenn es mehrere Klassen mit gleichem Namen gibt, wird die genommen, die in der gleichen Unit liegt. Gibt es da keine, wird die aus der Unit genommen, die zuerst in der uses-Klausel auftaucht.
Setz also die Unit, in der du TParser deklariert hast, als erstes in die uses-Klausel, und das Problem müsste gelöst sein.

_________________
Egal wie dumm man selbst ist, es gibt immer andere, die noch dümmer sind

Gast Erhaltene Danke: 1

Nein, es wird immer die Klasse genommen, die der Compiler als letzes findet.
Daher muss die Unit möglichst hinter "Classes" stehen.

cbs · Beiträge: 207 Erhaltene Danke: 1

jo DANKE!

wenn ich die unit als letztes in die uses einfüge funktionierts.

ich hatte in der OH nach TParser gesucht und keinen eintrag dazu gefunden. deshalb habe ich dummerweise angenommen das es die klasse noch nicht gibt

aber ich werd meine vorsichtshalber umbennen. thx nochmal!

mfg cbs

UC-Chewie · Beiträge: 531 WinXP D5 Ent

obbschtkuche hat folgendes geschrieben:

Nein, es wird immer die Klasse genommen, die der Compiler als letzes findet.

Echt? Hmm, dann verstehe ich aber nicht ganz, warum bei DLLs mit Strings die Unit ShareMem als erstes in dies Liste muss

_________________
Egal wie dumm man selbst ist, es gibt immer andere, die noch dümmer sind

TomT · Beiträge: 116 Suse 9.1 WinXP D6 Pers

Um sicher zu gehen, dass die Klasse aus der gewünschten Unit verwendet wird kann man auch die Unit mit angeben, also:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:

type
  TTest = class(TObject)
  private
    { Private declarations }
  public
    { Public declarations }
  end;


type
  TTest2 = class(Unit1.TTest)
  private
    { Private declarations }
  public
    { Public declarations }
  end;

_________________
...und da wurde mir klar, dass eine Toolbar keine Kneipe für Heimwerker ist.

cbs · Beiträge: 207 Erhaltene Danke: 1

TomT hat folgendes geschrieben:

Um sicher zu gehen, dass die Klasse aus der gewünschten Unit verwendet wird kann man auch die Unit mit angeben

axo.. gut zu wissen. hab meine klasse einfach in THtmlParser umbennant. passt auch besser :wink:

thx nochmal!

Motzi · Verfasst: Sa 03.01.04 19:20

UC-Chewie hat folgendes geschrieben:

obbschtkuche hat folgendes geschrieben:

Nein, es wird immer die Klasse genommen, die der Compiler als letzes findet.

Echt? Hmm, dann verstehe ich aber nicht ganz, warum bei DLLs mit Strings die Unit ShareMem als erstes in dies Liste muss

Weil die Unit ShareMem den Standard-Memory-Manager ersetzt...

_________________
gringo pussy cats - eef i see you i will pull your tail out by eets roots!

UC-Chewie · Beiträge: 531 WinXP D5 Ent

Motzi hat folgendes geschrieben:

Weil die Unit ShareMem den Standard-Memory-Manager ersetzt...

Ja, aber wenn doch Funktionen aus einer hinteren Unit zuerst ausgeführt werden ??

_________________
Egal wie dumm man selbst ist, es gibt immer andere, die noch dümmer sind

Gast Erhaltene Danke: 1

Ich vermute, damit Befehle in "initialization"-Bereichen der Units auch mit dem richtigen Memorymanager ausgeführt werden. Ist aber wie gesagt nur eine Vermutung.

Motzi · Verfasst: So 04.01.04 17:50

Weil die Units in der Reihenfolge initialisiert werden wie sie in der uses-Liste stehen. Und die Unit-ShareMem muss schließlich den Memory-Manager entsprechend initialisieren, _bevor_ eine andere Unit initialisiert wird und dabei auf den "falschen" Memory-Manager zurückgreift...

_________________
gringo pussy cats - eef i see you i will pull your tail out by eets roots!

UC-Chewie · Beiträge: 531 WinXP D5 Ent

Ja, aber:

obbschtkuche hat folgendes geschrieben:

Nein, es wird immer die Klasse genommen, die der Compiler als letzes findet.
Daher muss die Unit möglichst hinter "Classes" stehen.

Das heißt, bei Klassen die letzte Unit, bei Funktionen die erste :shock:

_________________
Egal wie dumm man selbst ist, es gibt immer andere, die noch dümmer sind

Gast Erhaltene Danke: 1

Die initialization-Teile der Units werden in der Reihenfolge abgearbeitet, wie sie hinter uses stehen. Da der MemoryManager bei initialization aktiviert wird, muss er direkt als erstes stehen, damit bei der i. der anderen Units der richtige Manager verwendet wird.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme