"Element '' hat kein übergeordnetes Fenster"

[DGL-luke]

Wir hatten die Diskussion vor kurzem doch erst

Aber für dich noch mal, so weit ichs in Erinnerung habe: Änderung an den TStrings wird sofort an die WinAPI weitergegeben, die das umzusetzen versucht. Geht aber nicht ohne bereits angezeigtes Parentwindow.

[xZise]

Zitat von DGL-luke:

Wir hatten die Diskussion vor kurzem doch erst

Link?

Und übrigens habe ich kA, was das verbockt. Aber ich nehme eben an das es die TStrings Property ist, da der Fehler meist dann kommt, wenn ich diesen Wert ändere.

[Nils_13]

Das verbockt nichts. Probier rum und denk ab und zu logisch, du hast den Debugger und ich bin um ehrlich zu sein () einfach zu faul es einzubauen. Diesen Fehler hatte ich schon oft und irgendwie hab ich es immer hinbekommen. Einfach mal nachdenken....

[IngoD7]

Täusche ich mich oder wird hier tatsächlich immer hübsch abwechselnd mal von der Listbox und mal von der Stringliste geredet?

Delphi-Quellcode:

  private
    FCompletionList : TStrings;
    completionBox : TListBox;

Ich weiß überhaupt nicht, welches Problem genau mit welchem Feld von TCompletionMemo genau wann genau auftritt.

[xZise]

So... Jetzt kompiliert er immerhin... Wahrscheinlich, weil ich bei TCustomMemo gesehen habe, dass das Setzen der Variable nicht einfach "FCompletionList" ist, sondern in eine Funktion ausgelagert werden muss...

@ Ingo: Ich hatte vorher keine Anhnung, warum und was etc. Ich kannte nur diese Fehlermeldung.
Allerdings habe ich jetzt das Problem, dass keine ListBox angezeigt wird... Und (siehe oben) die Daten (Breite, Höhe, Owner und Parent) setze ich ja...

Nagut... Es funktioniert doch nicht ganz so:

Zitat:

---------------------------
Fehler
---------------------------
nil kann nicht zu TRichEditStrings zugewiesen werden.
---------------------------
OK Details >>
---------------------------

Kommt, wenn ich diesen Dialog anzeigen will um die strings zu setzen...

[IngoD7]

Nimm's mir nicht übel, aber das meiste muss man sich immer erst mühsam zusammenreimen, ehe man ungefähr weiß, wo es bei dir brennt ...

Dass es irgendwie so (siehen nachfolgend) heißen muss, hattest du schon herausbekommen, oder?

Delphi-Quellcode:

protected
  procedure SetCompletionList(Value: TStrings);
published
  property CompletionList : TStrings read FCompletionList write SetCompletionList;

Wie sieht denn jetzt deine Methode SetCompletionList genau aus?

[xZise]

Ja... War mir bekannt (stand ja so in CustomMemo)... Habe es auch schon geändert.
Die Funktion:
FCompletionList.Assign(Value); Was mich irretiert, das die Items der Meo keine TStrings, sondern TMemoStrings sind... Und aauch scheint es irgendwie bei fast jeder Komponente so zu sein, dass sie statt TStrings TXXXXStrings nehmen (o.ä.)...

Mal geraten: Hängt es damit zusammen?

Zitat von IngoD7:

Nimm's mir nicht übel, aber das meiste muss man sich immer erst mühsam zusammenreimen, ehe man ungefähr weiß, wo es bei dir brennt ...

Das Hauptproblem ist ja, dass es in der IDE passiert Und da hilft debugen nichts...
Was mich auch irretiert ist, dass die Listbox nicht erscheint, obwohl die Funktion aufgerufen wird

[SirThornberry]

das ist das was die ganze zeit versucht wird dir zusagen TStrings ist eine abstrakte Basisklasse. Die ganzen Elemente wie Listboxen, Memos etc. haben eine davon abgeleitete Klasse welche das lesen und schreiben von Einträgen direkt auf die WinApi abbilden. Wenn aber zu dem Zeitpunkt das Control noch nicht angelegt ist (kein Handle angefordert etc.) kann nichts auf die WinApi abgebildet werden.

Noch was aus meiner persönlichen Sicht:
Sowas gehört sich nicht:

Delphi-Quellcode:

constructor TComponentNachfahre(AOwner: TComponent);
begin
  [...]
  MemberVar := AOwner as TWinControl;
  [...]

der Owner von TComponent hat nichts mit dem Parent oder anderen Visuellen Dingen zu tun geschweige dem mit Handles. Du kannst/solltest/darfst nie davon ausgehen das überhaupt ein Owner übergeben wird. Wenn Komponenten dynamisch erzeugt werden ist der Owner oftmals nil weil er nicht benötigt wird -> denn Dinge die man selbst anlegt/instanziert räumt man auch selbst wieder auf und ist somit nicht auf den Owner angewiesen der teilweise in der Objecthierarchy auch nicht vorhanden ist die man sich im Konzept überlegt hat.

[xZise]

Zitat von SirThornberry:

Wenn aber zu dem Zeitpunkt das Control noch nicht angelegt ist (kein Handle angefordert etc.) kann nichts auf die WinApi abgebildet werden.

Und das heißt?
Soll ich also Beispielsweise die Items von der Listbox nehmen (ich komme net auch den namen)?
Problem: "TListBoxStrings" ist sozusagen "privat", also für mich nicht zugänglich....

Zitat von SirThornberry:

Noch was aus meiner persönlichen Sicht:
Sowas gehört sich nicht:

Delphi-Quellcode:

constructor TComponentNachfahre(AOwner: TComponent);
begin
  [...]
  MemberVar := AOwner as TWinControl;
  [...]

Ich weiß, nur muss ich doch (höchstwahrscheinlich?) meiner Listbox ein Parent zuweisen. Jedenfalls müsste ich das wenn ich sie dynamisch in meiner Anwendung erstelle. Aufgrund dessen wollte ich der Listbox ein Parent zuweisen.
Das Problem ist aber, dass ich jetzt nicht genau weis was als Parent genommen wird.
Gibt es vielleicht bessere Vorschläge?

[IngoD7]

Zitat von SirThornberry:

Wenn Komponenten dynamisch erzeugt werden ist der Owner oftmals nil weil er nicht benötigt wird -> denn Dinge die man selbst anlegt/instanziert räumt man auch selbst wieder auf und ist somit nicht auf den Owner angewiesen der teilweise in der Objecthierarchy auch nicht vorhanden ist die man sich im Konzept überlegt hat.

Ergänzung:
Wenn es sich aber - so wie hier - um eine visuelle Komponente handelt, spricht doch nichts dagegen, den Owner vorzusehen. Dazu passend spricht auch nichts dagegen, der zur Laufzeit erzeugten visuellen Komponente als Owner das Form zu übergeben, auf dem die Komponente angezeigt wird. Hat auch den Vorteil, dass sie in der Eigenschaft Components des Form eingetragen wird, was oftmals nützlich ist.

Zudem sagt die Hilfe folgendes:

Zitat:

"Der Eigentümer ist für das Laden und Speichern der published-Eigenschaften seiner untergeordneten Komponenten verantwortlich."

Ich weiß zwar gerade nicht so wirklich, was das bedeutet, aber es klingt nicht unwichtig.

Ich sehe daher nicht viele Gründe, einen Owner nicht vorzusehen. Möchte man keinen übergeben bei Txxx.Create(aOwner), so übergibt man eben NIL.

Und da z.B. fangen die Probleme dann an, wenn man - so wie speziell hier geschehen - den Owner pauschal auch zum Parent erklären möchte. Denn das kann (trotz oder gerade wegen Typecast auf TWinControl) schön schiefgehen, wenn eben der Owner kein TWinControl ist.

Ich denke, SirThornberry meint das auch so; ich wollte es nur noch mal etwas verdeutlichen.