![]() |
Problem mit dyn. Arrays bei Übergabe an Funktion
Hallo,
warum bekomme ich bei diesem Konstrukt die Fehlermeldung: Inkompatible Typen ? In Unit 1 steht folgendes:
Delphi-Quellcode:
implementation
{$R *.dfm} uses unit2; procedure TForm1.Button1Click(Sender: TObject); var UpdateListFile : array of string; begin if Check4UpdateList(UpdateListFile) then Edit1.Text := 'OK'; end; end. In Unit 2 steht folgendes:
Delphi-Quellcode:
Würde mich mal interessieren, wo mein Denkfehler liegt.
unit Unit2;
interface function Check4UpdateList(UpdateListFile : array of string) : boolean; implementation function Check4UpdateList(UpdateListFile : array of string) : boolean; begin SetLength(UpdateListFile, 1); // hier gibts den Fehler Result := true; end; end. Gruß Michael |
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
Zitat:
Erstelle Dir einen Typen, den Du dann überall für array of string einsetzt.
Delphi-Quellcode:
...:cat:...
unit Unit2;
interface type TStringArray = array of string; function Check4UpdateList(UpdateListFile : TStringArray) : boolean; implementation function Check4UpdateList(UpdateListFile : TStringArray) : boolean; begin SetLength(UpdateListFile, 1); // hier gibts den Fehler Result := true; end; end. |
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
Hallo kalmi01,
das selbe Problem hatte ich auch schon des öfteren. Beim übergeben eines dynamischen arrays an eine Methode wird der Array innerhalb der Methode statisch. Ein Lösungsansatz wäre nur einen Zeiger auf den Array zu übergeben und diesen dann innerhalb der Methode zu dereferenzieren und dann setlength anzuwenden. Kann aber nicht garantieren, dass das klappt, habs nämlich selber noch nie versucht. Gruß Jan |
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
Zitat:
Delphi-Quellcode:
und dann immer den neuen Typen nutzt, so ist garantiert, dass es sich immer um den gleichen Typen handelt.
type
TStringArray = array of String; ...:cat:... |
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
und warum kann denn dann alles machen was man mit einer statischen stringlist auch machen kann? also ich verstehe nicht, warum da jetzt unterscheide gemacht werden. Wieso wird wegen dieser doppelten deklaration der array jetzt wie ein statischer array behandelt? wo liegt da der sinn? Und wieso limitiert dieses doppelte deklarieren nur den dynamischen aspekt des arrays? weil normalerweise müsste Delphi ja dann bei beliebigen übergebenen Variabeln an eine Methode Zweifel haben ob der Typ jetzt wirklich richtig ist und generell den typ als inkompatibel bezeichnen.
Das soll jetzt nicht heißen, dass du nicht Recht hast aber mich interessiert das, weil ich mich schon oft darüber gewundert hab was das soll. Würde denn mein Lösungsvorschlag mit dem zeiger funktionieren? Gruß Jan |
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
...:cat:... |
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
Hi,
also nur so zur Info, mit Pointern hat ich es auch schon probiert. War nicht vom gewünschten Ergebnis gekürt.
Delphi-Quellcode:
Geht aber auch nicht so, wie gewollt.
type
TStringArray = array of string; Deklarier ich TStringArray in Unit1, so muß ich diese auch in Unit2 im uses referenzieren, damit es eindeutig bleibt. Also hab ich eine eigene Unit für Typdefinitionen angelegt. So weit so gut, die Syntaxprüfung meckert nicht mehr. Leider gibts beim Compilieren: [Fataler Fehler] Interner Fehler: L1333 gefrusteter Michael |
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
Zitat:
|
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
Hi,
anstatt einen neuen Typ für das Array zu deklarieren, nimm doch einfach den vorhandenen:
Delphi-Quellcode:
aus der Unit:
TStringDynArray
Delphi-Quellcode:
Types
Da gibt's das nämlich schon... :zwinker: mfg |
Re: Problem mit dyn. Arrays bei Übergabe an Funktion
Zitat:
...:cat:... Edit: namen verdreht :mrgreen: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:47 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