Fehler beim zugreifen auf die public-Eigenschaft Strings !!

[Sepp101]

Hallo erstmal.<br>
<br>
Es geht um eine Komponente die von TGraphicControl abgeleitet wurde und die nun die Eigenschaft Strings: strings erhalten soll. Jedes mal wenn ich die Komponente testen will und zur Entwurfszeit der Anwendung diese Komponente hinzufüge und auf die Eigenschaft zugreife erscheint folgender Fehler : "nil kann nicht zu TRicheditstrings zugewiesen werden.". <br>
Kennt jemand diesen Fehler oder hat eine Ahnung woher er stammen könnte ?Was muß ich tun um diesen Fehler zu beheben ?<br>
<br>
Gruß Detlef.<br>

[Sepp101]

Ich bins nochmal:<br>
<br>
Soll natürlich nicht public heißen sondern published.<br>
<br>
Detle

[Hagen Reddmann]

<a href="/webx?50@@.ee859bf/11">Rasmus Weigel "Ereignisbehandlung von Unter-Propertys zur Entwicklungszeit" 12.07.2001 08:00</a>
http://www.entwickler-forum.de\webx?50@@.ee859bf/1

[Sepp101]

Danke erstmal für die Antwort,

aber was genau soll ich denn jetzt ändern ? Der Fehler kommt ja schon wenn ich nur in der Eigenschaften-Liste der neuen Komponente auf Strings klicke und nicht erst wenn ich was ändere(OnChange). Normalerweise müsste doch Delphi den Rest erledigen, oder ?

Ich hab da leider irgendwie keine genauen Vorstellungen was ich jetzt tun kann. Vielleicht gibts ja irgendwo eine Komponente, die eine entsprechende Eigenschaft hat, wo ich mir das mal anschauen könnte.

Gruß Detlef

[Hagen Reddmann]

Strings=type TStrings oder TStringList sind Objecte, als properties MÜSSEN diese eine read/write Methode nutzen. In der write Methode der Eigenschaft MUSS mit FStrings.Assign(NewStrings) der Context kopiert werden. Der angegebene Link zeigt all dieses.

gruß Hage

[Sepp101]

Hallo Hagen,

zum Problem mit der published-property Strings: ich kriegs einfach nicht hin. Ich hab auch eine andere Komponente gefunden bei der es funktioniert, allerdings wurde die von TCustomLabel und nicht von TGraphicControl abgeleitet. Aber egal, ich hab ein neues Problem.

Vielleicht kannst Du mir ja sagen woran es liegen könnte wenn der Fehler kommt: "Element " hat kein übergeordnetes Fenster" ?
Ich weiß, dass ich den Fehler am Anfang nicht hatte.

Gruß Detle

[Hagen Reddmann]

Ohne Source gehts nicht. Also poste mal das Grundgerüst, constructor, Paintmethode usw.

<pre>
type
TmyControl = class()
private
FStrings: TStringList;
function GetStrings: TStrings;
procedure SetStrings(Value: TStrings);
published
property Strings: TStrings read getStrings write SetStrings;
end;<br>

function TMyControl.GetStrings: TStrings;
begin
if FStrings = nil then FStrings := TStringList.Create;
Result := FStrings;
end;<br>

procedure TMyControl.SetStrings(Value: TStrings);
begin
if Value = nil then
begin
FStrings.Free;
FStrings := nil;
end else GetStrings.Assign(Value);
end;<br>

</pre>

im destructor noch FStrings.Free einfügen.<br>

Nun, mit dem "übergeordneten fenster": Dein Control besitzt kein Parent und kann damit bestimmte methoden NICHT nutzen. z.b. .Paint;

gruß hage

[Sepp101]

Hallo Hagen,

das mit der Eigenschaft Strings hat natürlich so funktioniert. Aber das mit dem Unterschied von TStringList und TStrings und warum FStrings = nil gesetzt wird nachdem die Variable freigegeben wurde versteh ich trotzdem nich. Aber wenigstens hab ich den Fehler mit dem Element, das ein übergeordnetes Fenster braucht gelöst. Ich hatte im Constructor über eine Set-Methode indirekt auf Paint zugegriffen, was zu diesem Zeitpunkt warscheinlich noch gar nicht geht. Aber jetzt funzts wieder.

Vielen Dank also nochmals für alles Hagen

bis dann, Detle

[Christian Seehase]

Hallo Detlef,<br>
<br>
FStrings = nil, da sonst auf einen Speicherbereich verwiesen wird, der schon freigegeben wurde (FStrings.Free).<br>
<br>
Ciao<br>
Chri

[Hagen Reddmann]

Hi

Du musst nicht unbedingt die FStrings zerstören. Ich persönlich bevorzuge diesen Weg da es 1.) wenig zeit frist, 2.) Speicher spart, 3.) mit einer Abfrage wie FStrings = nil sehr leicht ermittelt werden kann ob überhaupt Strings vorhanden sind. Das kann z.B. die .paint methode enorm beschleunigen falls FStrings = nil. Dann wird nämlich keinerlei langsamme GDI Funktion aufgerufen.<br>
Normalerweise überprüfe ich sogar nach FStrings.Assign(value) ob FStrings.Count = 0 ist. Sollte das der Fall sein rufe ich auch FStrings.Free auf.<br>
In neueren Delphi Versionen sollte man FreeAndNil() aufrufen. Diese procedure ruft .Free auf und danach ObjectReferenz := nil. Allerdings preferiere ich obigen Code, da er genauso sicher aber schneller ist.<br>

Auf alle Fälle wird der Speicherbereich auf den der Objectzeiger FStrings zeigt nach einem FStrings.Free ungültig. Heist der zeiger in FStrings ist ungültig geworden. Damit man nun dieses im späteren Programfluß erkennt und damit man NICHT auf einen falsches Object/Specher zugreift sollte man IMMER nach einem Object.Free; auch die Referenzvariable Object auf nil setzen.<br>
Wird NICHT so vorgegangen und angenommen das der Objectzeiger noch gültig ist hat man immer die berühmte Schutzverletzung vor Augen.<br>

Gruß hage

[Christian Wilke]

Hallo, <br>
Gibt es eigentlich eine Möglichkeit, ein dynamisches Feld von Integer-Zahlen so wie hier die Strings zu verwalten (spziell mit published-Problematik aus Beitrag #6)?<br>
Gruß Christia

[Hagen Reddmann]

<pre>

// D4 and above<br>

type
TIntArray = array of Integer;<br>

TMyObject = class
private
FIntegers: TIntArray;
function GetInteger(Index: Integer): Integer;
procedure SetInteger(Index,Value: Integer);
published
property Integer[Index: Integer]: Integer read GetInteger write SetInteger;
end;<br>

function TMyObject.GetInteger(Index: Integer): Integer;
begin
if (Index >= 0) and (Index < length(FIntegers)) then Result := FIntegers[Index]
else Result := 0;
end;<br>

procedure TMyObject.SetInteger(Index,Value: Integer);
begin
if Index > High(FIntegers) then SetLength(FIntegers, Index +1);
FIntegers[Index] := Value;
end;<br>

</pre>

Als published Eigenschaft ist ein Array oder Dynamisches Array direkt NICHT möglich.

Gruß Hage

[Christian Wilke]

Hallo Hagen, <br>
Habe Dein Beispiel ausprobiert, bei mir meldet der Compiler: "Published-Eignschaft 'Integer' kann nicht vom Typ ARRAY sein".<br>
Gruß Christia

[Hagen Reddmann]

Sorry, nenns mal in Int[] o.ä. um. Ich glaube mit dem PropertyName "Integer" hat's der Compiler nicht so. Obiger Code war auch eher als Demonstration gedacht.

Gruß Hage

[Christian Wilke]

Hallo Hagen,<br>
"Published-Eignschaft 'Int' kann nicht vom Typ ARRAY sein"..