TComboBox 'Control has no parent window' in destructor

Question

I'm using Delphi XE2. I build a custom TComboBox so that I can easily add key/string pairs and handle the cleanup in the component's destructor.

All if not (csDesigning in ComponentState) code is omitted for brevity.

interface

type
  TKeyRec = class(TObject)
    Key: string;
    Value: string;
  end;

  TMyComboBox = class(TComboBox)
  public
    destructor Destroy; override;
    procedure AddItemPair(const Key, Value: string);
  end;

implementation

destructor TMyComboBox.Destroy;
var i: Integer;
begin
  for i := 0 to Self.Items.Count - 1 do
    Self.Items.Objects[i].Free;
  Self.Clear;
  inherited;
end;

procedure TMyComboBox.AddItemPair(const Key, Value: string);
var rec: TKeyRec;
begin
  rec := TKeyRec.Create;
  rec.Key := Key;
  rec.Value := Value;
  Self.Items.AddObject(Value, rec);
end;

When the application closes, the destructor is called, but the Items.Count property is inaccessible because the TComboBox must have a parent control to access this property. By the time the destructor is called, it no longer has a parent control.

I saw this problem once before and had to store the objects in a separate TList and free them separately. But that only worked because the order that I added them to the TList was always the same as the strings added to the combo box. When the user selected a string, I could use the combo box index to find the correlating object in the TList. If the combo box is sorted, then the indexes won't match, so I can't always use that solution.

Has anyone else seen this? How did you workaround the issue? It would be really nice to be able to free the objects in the component's destructor!

Answer 1

You can override function GetItemsClass:

function GetItemsClass: TCustomComboBoxStringsClass; override;

It is called by Combo to create Items (by default it is TComboBoxStrings probably). Then you can create your own TComboBoxStrings descendant, for example TComboBoxStringObjects, where you can free object linked with item (when item deleted).

Answer 2

After reading the link from Sertac (David Heffernan's comment and NGLN's answer), I believe a solution that stores the objects in a managed list and not in a GUI control is the best. To that end, I have create a combo box that descends from TCustomComboBox. This lets me promote all the properties except for Sorted to published. This keeps the internal FList in sync with the strings in the combo boxes Items property. I just make sure they are sorted the way I want before adding them...

The following shows what I did. I only included the essential code (less range checking) for brevity, but included some conditional logic that allows the combo box to be used without objects as well.

FList is properly destroyed in the destructor, freeing all objects without any run-time exceptions and the object list is managed within the component itself instead of having to manage it elsewhere -- making it very portable. It works when the control is added to a form at design-time, or when it is created at run-time. I hope this is useful to someone else!

interface

type
  TMyComboBox = class(TCustomComboBox)
  private
    FList: TList;
    FUsesObjects: Boolean;
    function GetKey: string;
  public
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
    procedure AddItemPair(const Key, Value: string);
    procedure ClearAllItems;
    procedure DeleteItem(const Index: Integer);
    property Key: string read GetKey;
  published
    // all published properties (except Sorted) from TComboBox
  end;

implementation

type
  TKeyRec = class(TObject)
    Key: string;
    Value: string;
  end;

function TMyComboBox.GetKey: string;
begin
  if not FUsesObjects then
    raise Exception.Create('Objects are not used.');

  Result := TKeyRec(FList.Items[ItemIndex]).Key;
end;

constructor TMyComboBox.Create(AOwner: TComponent);
begin
  inherited;

  if not (csDesigning in ComponentState) then
  begin
    FUsesObjects := False;
    FList := TList.Create;
  end;
end;

destructor TMyComboBox.Destroy;
begin
  if not (csDesigning in ComponentState) then
  begin
    ClearAllItems;
    FreeAndNil(FList);
  end;

  inherited;
end;

procedure TMyComboBox.AddItemPair(const Key, Value: string);
var rec: TKeyRec;
begin
  FUsesObjects := True;
  rec := TKeyRec.Create;
  rec.Key := Key;
  rec.Value := Value;
  FList.Add(rec);
  Items.Add(Value);
end;

procedure TMyComboBox.ClearAllItems;
var i: Integer;
begin
  if not (csDesigning in ComponentState) then
  begin
    if FUsesObjects then
    begin
      for i := 0 to FList.Count - 1 do
        TKeyRec(FList.Items[i]).Free;
      FList.Clear;
    end;
    if not (csDestroying in ComponentState) then
      Clear; // can't clear if the component is being destroyed or there is an exception, 'no parent window'
  end;
end;

procedure TMyComboBox.DeleteItem(const Index: Integer);
begin
  if FUsesObjects then
  begin
    TKeyRec(FList.Items[Index]).Free;
    FList.Delete(Index);
  end;
  Items.Delete(Index);
end;

end.

Answer 3

There's a way that avoid the need of rewrite the component to use another list to save the objects. The solution is to use the WM_DESTROY message along with the ComponentState property. When the component is about to be destroyed, its state change to csDestroying, so the next time it receives a WM_DESTROY message it will be not part of the window recreation process. We use this method in our component library sucessfully.

TMyCombo = class(TCombobox)
...
  procedure   WMDestroy(var message: TMessage); message WM_DESTROY;
...

procedure TMyCombo.WMDestroy(var message: TMessage);
var
  i: integer;
begin
  if (csDestroying in ComponentState) then
    for i:=0 to Items.Count - 1 do
      Items.Objects[i].Free;
  inherited;
end;