Hallo und Willkommen in den heiligen Hallen des Wissens und des Wahnsinns
Delphi-Quellcode kannst du in (Delphi)(/Delphi)-Tags (mit eckigen Klammern) packen. Das tue ich hier einmal, mit leichten Formatierungsänderungen:
Teil "Steuerung"
Delphi-Quellcode:
pTFstKa = ^VFstKa;
VFstKa = record
FstKaX: ^Fahrstuhlkabine; //Fahrstuhlkabine ist als Klasse deklariert
next: PTFstKa;
end;
Steuerung = class
id: cardinal;
pFstKa: pTFstKa;
procedure Fahrstuhl_Hinzu(
id_in:cardinal;
zulGewicht_in, EtageV_in, EtageB_in: integer;
sNiAnEt: string);
function Suche_Fahrstuhl(Suchkriterium, id_in, Stelle: cardinal):pTFstKa;
constructor init(id_in: cardinal);
destructor destruct();
end;
"Liste anlegen"
Delphi-Quellcode:
procedure Steuerung.Fahrstuhl_Hinzu(
id_in:cardinal;
zulGewicht_in, EtageV_in, EtageB_in: integer;
sNiAnEt: string
);
var
FstKa: Fahrstuhlkabine;
p,h: pTFstKa;
begin
//Listenelement hinzufügen
p:=pFstKa;
new(h);
h^.next:=nil;
//Objektinitialisierung:
FstKa:= Fahrstuhlkabine.Init(id_in, zulGewicht_in, EtageV_in, EtageB_in, sNiAnEt);
h^.FstKaX:= @FstKa;
//an Liste anfügen
if pFstKa=nil then
pFstKa:=h
else begin
while p^.next<>nil do begin
p:=p^.next;
end;
p^.next:=h;
end;
end;
"Laden der Aufzug-Eigenschaften des darzustellenden Aufzugs"
Delphi-Quellcode:
index := Combob_FstKa.ItemIndex;
p1 := Steuerung1.Suche_Fahrstuhl(2,0,
index);
Form.Caption := '
Aufzug - Nr:' + inttostr(p1^.FstKaX^.id);
// <------ hier kommt dann die Exception
Wieviel Theoriewissen über Objektorientierung und Anforderungserhebung habt ihr mit auf den Weg bekommen? Die Anforderung von dir sagt "Fahrstuhlsteuerung, die eine beliebige Anzahl von Fahrstühlen, Etagen etc. verwalten & steuern kann". Kannst du mehr dazu erzählen? Gerade zur Methode
Steuerung.Suche_Fahrstuhl(..)
und insbesondere den Parametern kann ich mir spontan gar nichts vorstellen
Zur Lösung des eigentlichen Problems: Entweder bin ich dumm (zum Ausgleich bin ich aber relativ schön), oder aus dem hier ersichtlichen Code lässt sich nichts finden. Meine Vermutung wäre, dass
Steuerung.Suche_Fahrstuhl(..)
keinen vernünftigen Zeiger zurückgibt, beispielsweise den Record nicht mittels
new()
auf dem Heap anlegt, sondern nur lokal "bei sich" auf dem Stack und dann einen Pointer auf Schrott zurückgibt.
Alternativ streicht bei mir der Debugger immer wieder gerne eine Zeile zu tief an, meint in Wirklichkeit die Zeile darüber. Setz doch mal einen Haltepunkt auf
p1 := Steuerung1.Suche_Fahrstuhl(2,0,index);
und geh dann schrittweise mit F7 durch und schau wo er rausfliegt.
Das bringt mich dann zu einem an sich erst einmal subjektiven Thema, hoffe aber, dass der Großteil der Belegschaft hier das ähnlich sieht: Ich finde den Code extrem schwer zu lesen, warum überhaupt die Records (und Zeiger)? Und warum keine gängigen Listentypen wie
TList
oder
TObjectList
? Ist das eine zwingende Vorgabe? Man muss doch nicht in jedem Projekt die verkettete Liste neu erfinden...
Zu Stilvorgaben und Namenskonventionen: Wie lange bist du schon bei Delphi dabei und von welcher Sprache kommst du? Mir kam es anfangs auch etwas dämlich vor, die Klassennamen immer mit
T beginnen zu lassen, das ist sicher auch persönliches Gusto. Aber ich kann mir spontan keinen (hier passenden) Grund ausdenken, Konstruktoren und Destruktoren
nicht Create
und
Destroy
zu nennen, das bietet auf Dauer nur Verwirrungspotentiel.
Wenn ich jetzt noch damit anfange, dass zumindest mein Kopf es spontan nicht schafft, den Zweck hinter Variablennamen wie
sNiAnEt
oder
pFstKa
zu erkennen, wendest du dich wahrscheinlich wie jeder vernünftige Mensch angewidert vom Forum (insbesondere von mir) ab, da du eigentlich aus einem anderen Grund hergekommen bist. Aber ich denke dass es viel schwerer ist, überhaupt durcheinander zu kommen, wenn man nicht an Buchstaben spart und außen am Funktionskopf dokumentiert, wozu die Werte die rein- und rausgehen überhaupt gut sind.
Wie gesagt, spontan finde ich mit dem gegebenen Code keine Unstimmigkeit, ich tippe auf den oben genannten zwei Gründen auf einen Fehler in der nicht gegebenen Implementierung von
Steuerung1.Suche_Fahrstuhl