Parent Problem

[IngoD7]

Zitat von Der_Unwissende:

Zitat von IngoD7:

Wichtig für sein Problem ist nur, dass die Eigenschaft Parent direkt beim Erzeugen belegt wird. Mehr wollte ich nicht ausdrücken.

Das ist aber so falsch!
Das Problem (das Du nach eigener Aussage nicht verstehst) für das Du hier eine Lösung anbietest ist nicht das, das der Thread-Steller hat.

Na komm, zum guten Teil aber schon. Wenn die Box wirklich vorausgefüllt sein soll mit irgendwelchen Strings, so muss das im Konstruktor irgendwo passieren, und dazu muss vorher im Konstruktor der Parent mit einem WinControl belegt sein. Meine im Vorposting zuletzt getroffene Aussage ist also nicht falsch.

Er erzeugt sein Panel-Combo-Objekt zur Laufzeit. Richtig?

Zwei mögliche Fälle:
1.) Er weiß zur Laufzeit, wo das Teil zu liegen kommt.
Damit kann er z.B. meinen ersten (Owner=Parent, aber weniger gut) oder meinen letzen Vorschlag (Parent dem Konstruktor mit übergeben) benutzen. Der letzte Vorschlag kam später als Nachtrag und hat sich möglicherweise mit deinem Posting überschnitten.

2.) Der spätere Parent ist selbst vielleicht noch gar nicht erzeugt, wenn das Panel-Combo-Objekt erzeugt wird.
Dann übergebe ich "irgendeinen" Parent und setze Visible vom Panel-Combo-Objekt zunächst auf false.
Das könnte auch sogar der Konstruktor erledigen, indem er alle Komponenten der Applikation durchsucht und das erstbeste TForm, dass er findet, vorübergehend als Parent nimmt (bei Visible:=false).

//EDIT: Posting anders strukturiert, inhaltlich gleichgeblieben.

[Der_Unwissende]

Zitat von IngoD7:

Na komm, zum guten Teil aber schon. Wenn die Box wirklich vorausgefüllt sein soll mit irgendwelchen Strings, so muss das im Konstruktor irgendwo passieren, und dazu muss vorher im Konstruktor der Parent mit einem WinControl belegt sein. Meine im Vorposting zuletzt getroffene Aussage ist also nicht falsch.

Ok, nochmal, es geht nicht um ein beliebiges TWinControl. Du erzeugst dyn. ein Panel (ohne weiteren Parent/Owner). Dieses Panel ist ein TWinControl! Du erzeugst jetzt eine Combobox und übergibst im Konstruktor dieses Panel als Owner und setzt es danach auch noch mal per Eigenschaft als Parent und Owner und zur Sicherheit fügst Du auch nochmal mit Panel.insertControl die Combobox ein.
Dann greifst Du auf die Eigenschaft Items zu und eine Exception wird ausgelöst, weil es kein Fenster gibt, dass der Combobox direkt oder über die gesamte Hierachie aller Parents übergeordnet ist.

Damit dieses Problem nicht auftritt musst Du also schauen, ob einer der Parents ein Fenster ist, nochmal als Code:

Delphi-Quellcode:

var b: Boolean;
    control: TWinControl;
begin
  b := false;
  control := Combobox.Parent;
  while (control <> nil) and (not b) do
  begin
    b := control is TForm;
    control := control.Parent;
  end; 
  
  // wenn b an dieser Stelle noch false ist, 
  // dann hast Du ein Problem
end;

Wichtig ist eben nicht, das ein Parent existiert, sondern das ein Fenster übergeordnet ist.

Hoffe es ist jetzt etwas klarer (ist eine Besonderheit der Combobox).

[EDIT]
Ok, das mit dem visible := false kann natürlich klappen!
[/EDIT]

[IngoD7]

Bevor ich möglicherweise noch länger antworten muss ...

Ich habe vollkommen verstanden, was du meinst. Was stimmt an meinen Lösungsvorschlägen (nimm mein letztes Posting dazu her) denn nicht?

[Der_Unwissende]

Zitat von IngoD7:

Was stimmt an meinen Lösungsvorschlägen (nimm mein letztes Posting dazu her) denn nicht?

Zitat von IngoD7:

Zwei mögliche Fälle:
1.) Er weiß zur Laufzeit, wo das Teil zu liegen kommt.
Damit kann er z.B. meinen ersten (Owner=Parent, aber weniger gut) oder meinen letzen Vorschlag (Parent dem Konstruktor mit übergeben) benutzen. Der letzte Vorschlag kam später als Nachtrag und hat sich möglicherweise mit deinem Posting überschnitten.

Ok, was heißt denn wissen wo man zur Laufzeit zum liegen kommt? Ich meine nehmen wir deinen zweiten Vorschlag:

Zitat von IngoD7:

Als letztes könnte man auch einen Parent getrennt mit übergeben (so würde ich es wahrscheinlich machen):

Delphi-Quellcode:

X:=TMyClass.Create(Form1, Panel2);
 ...............

constructor TMyClass.Create(Compo:TComponent; WinC: TWinControl); 
  begin 
  inherited create(Compo); 
  parent:=WinC; 
  combo:=TCombobox.Create(self); 
  combo.Parent:=self; 
  end;

Wichtig für sein Problem ist nur, dass die Eigenschaft Parent direkt beim Erzeugen belegt wird. Mehr wollte ich nicht ausdrücken.

Hier übergibst Du als Parent Panel2, ist ein Panel. Ok, wo ist die Garantie dafür, dass ein Panel eine Form als Parent hat? Wie sieht es denn bei folgendem Code aus:

Delphi-Quellcode:

var panel2: TPanel;
    x: TMyClass;
begin
  panel2 := TPanel.Create(Form1);
  x := TMyClass.Create(Form1, Panel2);
  ...
end;

Hier ist doch alles so übergeben, wie Du es vorschlägst oder sehe ich das falsch? Na ja, genau hier dürfte es trotz allem krachen, weil es ebend für die Combobox immer noch kein übergeordnetes Fenster gibt. Wie Du siehst ist hier der spätere Parent schon erzeut, mit der Existenz eines Parents lässt sich das Problem also nicht lösen.

Zitat von IngoD7:

2.) Der spätere Parent ist selbst vielleicht noch gar nicht erzeugt, wenn das Panel-Combo-Objekt erzeugt wird.
Dann übergebe ich "irgendeinen" Parent und setze Visible vom Panel-Combo-Objekt zunächst auf false.
Das könnte auch sogar der Konstruktor erledigen, indem er alle Komponenten der Applikation durchsucht und das erstbeste TForm, dass er findet, vorübergehend als Parent nimmt (bei Visible:=false).

Gut, wann setzt man visible wieder auf true? Nebenbei bemerkt auch die Sichtbarkeit ändert nichts am Problem, es wird der selbe Fehler ausgelöst.

[IngoD7]

Zitat von Der_Unwissende:

Hier übergibst Du als Parent Panel2, ist ein Panel. Ok, wo ist die Garantie dafür, dass ein Panel eine Form als Parent hat?

Oh man, jetzt verstehe ich endlich, was du meinst.

Darf ich denn aber nicht voraussetzen, dass das Programm bzw. der Programmierer so etwas abfängt? Ich meine: Viele Komponenten haben Besonderheiten, auf die man während der Programmentwicklung eingehen und achten muss. In einer imaginären Online-Hilfe für diese Komponente stünde eben, dass der Programmierer dafür Sorge zu tragen hat, dass der Parentstammbaum der Komponente "ganz oben" ein Fenster haben muss.

Letztendlich soll die Komponente ja irgendwann zur Laufzeit mal sichtbar sein und ein Parent wird zugewiesen werden müssen. Das darf dann eben nicht "irgendetwas" sein, sondern muss einen sauberen WinControl-Stammbaum haben. Dafür muss der Programmierer schon irgendwie sorgen. Warum sollte er auch das Teil auf einer Komponente anzeigen wollen, die selber nicht angezeigt werden kann?

Klar könnte man jetzt die Set-Parent-Procedure überschreiben und dort eine Prüfung einbauen. Aber was ist dann? Dann fällt das Programm bei einem "falschen" Parent etwas kontrollierter auf die Schnauze, anstatt nur mit einer Exception. Das hilft auch nicht weiter.

Für mich ist Fakt: Zum Zeitpunkt, da Parent irgendwo zur Laufzeit belegt wird, muss dieser Parent sauber sein, oder das Programm fällt auf die Nase. Das kann man auch wohl nicht ändern. Da ist diese Komponente sicherlich keine große Ausnahme, denn mögliche "Fehlbedienungen" gibt es auch bei anderen Komponenten/Klassen.

Diese Überlegungen gelten alle auch dann, wenn im Aufruf des Konstruktors diesem der Parent gleich mit übergeben würde. Hier würde ich aber durchaus einsehen, dass der besagte korrekte Parentstammbaum vielleicht noch gar nicht immer existiert.

Um also das Createn nicht gleich zu gefährden, könnte dieses hier doch gut funktionieren:

Zitat von IngoD7:

2.) [...]Das könnte auch sogar der Konstruktor erledigen, indem er alle Komponenten der Applikation durchsucht und das erstbeste TForm, dass er findet, vorübergehend als Parent nimmt (bei Visible:=false).

Lassen wir es also den Konstruktor machen. Was hälst von folgendem? (Achtung nur so vom Prinzip - da gehören vielleicht durchaus noch ein paar Sicherungen rein.) Das Beispiel ist jetzt eine alleinige ComboBox ohne festes Panel darunter. Ist ja das gleiche in grün.

Diese sucht sich beim Erzeugen irgendeine Form als funktionierenden "Leihvater" und setzt sich zunächst auf unsichtbar.
Im Hauptprogramm muss dann mit Festlegung eines anderen Parent die Box gesondert sichtbar gemacht werden.

Delphi-Quellcode:

constructor TMyCombo.Create(AOwner:TComponent);
  begin
  inherited;
  Visible:=false;
  Parent:=SucheParent;
  Items.Clear;
  Items.Add('Delphi-Praxis');
  Items.Add('Delphi-Forum');
  Items.Add('DSDT');
  end;

function TMyCombo.SucheParent : TWinControl;
  var i:integer;
  begin
   for i:= 0 to Application.ComponentCount-1 do
     begin
       if Application.Components[i] is TForm then
         begin
           result:=TWinControl(Application.Components[i]);
           break;
         end;
     end;
   end;

[Der_Unwissende]

Also dein letzter Vorschlag ist bis jetzt die beste Lösung die ich gesehen hab (die scheint auch gut zu funktionieren).
Deshalb nicht falsch verstehen wenn ich sage, dass die ein wenig unsauber wirkt, dachte halt einfach, dass das auch schöner gehen müsste. Aber wie gesagt, die Beste bisher und die sollte auch funktionieren.

[IngoD7]

Zitat von Der_Unwissende:

Deshalb nicht falsch verstehen wenn ich sage, dass die ein wenig unsauber wirkt,

Kein Problem. Sie funktioniert, aber ich schaue da ja selber etwas skeptisch drauf. Aber solange die Anwendung nur irgendeine Form besitzt geht nichts schief.

Zitat von Der_Unwissende:

dachte halt einfach, dass das auch schöner gehen müsste.

Das schließe ich auch nicht aus.

Aber im Moment könnten wir schon froh sein, wenn der Fragesteller unserer Diskussion überhaupt irgendwie folgen konnte.

[Sidorion]

Das Problem bei einer ComboBox ist, das WINDOWS die Items handhabt. In Konsequenz davon ist die Items-Property erst dann benutzbar, wenn die ComboBox ein Handle hat, und das bekommt sie erst beim ersten 'sichtbarwerden', egal, auf welchem Parent sie liegt(ja man kann theoretisch eine CB auch auf den Desktop setzen). Es hat also nix mit dem Parent-setzen an sich zu tun.

Wenn man also auf die Items zugreifen will, bevor die Box sichtbar ist, muss man also in einem Nachfolger die Items erstmal 'zwischenspeichern', solange die CB noch kein Handle hat (Thema überschreiben der Getter-Setter-Methoden der Items-Property).
Sobald die CB dann sichtbar wird (WinHandleAssigned) kann man dann der CB die gemerkten Items unterjubeln. Wenn sie erstml ein Handle hat, dann behält sie es auch, wenn sie unsichtbar wird.

nochmal zur Verdeutlichung: es nutzt nix, wenn die CB eine Form als parent hat, solange diese unsichtbar ist. die Items sind erst benutzbar, wenn die CB selber sichtbar wird.

[DGL-luke]

Reicht vielleicht auch ein Message-only Window?

Delphi-Quellcode:

constructor TMyCombo.Create(Owner: TComponent);
begin
  self.Parent := hWnd(-3); //HWND_MESSAGE
  {...}
end;

[IngoD7]

Zitat von Sidorion:

nochmal zur Verdeutlichung: es nutzt nix, wenn die CB eine Form als parent hat, solange diese unsichtbar ist. die Items sind erst benutzbar, wenn die CB selber sichtbar wird.

Was verstehst du unter unsichtbar? Einfach Visible = false ? Dann stimmt das nicht, was du schreibst.