очистка StringList

← →
Crusader (2013-01-09 10:32) [0]

в StringList1 добавляются объекты (AddObject) из StringList2. Как очистить StringList1 не освобождая (Objects[I].Free) содержащиеся в нем объекты.

← →
Crusader (2013-01-09 10:39) [1]

у меня есть список TStringList который содержит строки и объекты. В определенный момент из него выбираются item"ы и добавляются в компонент TListBox (AddObject). Как перед добавлением item"ов правильно очистить компонент TListBox, чтобы не освободить объекты из списка TStringList.

← →
RWolf © (2013-01-09 10:41) [2]

очистка TListBox не освобождает связанные с ним объекты.

← →
RWolf © (2013-01-09 10:42) [3]

равно как и очистка TStringList.

← →
sniknik © (2013-01-09 10:51) [4]

параллельно сохраняй объекты в ObjectList, при необходимости очистить (clear) уничтожить (free) StringList тут же делай аналогичное, общее для ObjectList.

ну, или для удобства (убирания дублирующихся действий) можно перекрыть методы и и добавь нехитрое в общем то действие в сам StringList (или отказаться от него, и строку названия включить внутрь обьекта, и перейти полностью на объектный список)

← →
DVM © (2013-01-09 11:08) [5]

> Crusader

Лучше использовать так называемый виртуальный режим, когда контрол не хранит данные непосредственно, а запрашивает их для рисования из внешнего списка. А уж внешний список может быть организован как угодно. Может подойдет?

← →
sniknik © (2013-01-09 11:12) [6]

> добавь нехитрое в общем то действие в сам StringList
если не мудрить особо то -
type TMyStringList = class(TStringList) procedure Delete(Index: Integer); override; procedure Clear; override; destructor Destroy; override; end; procedure TMyStringList.Delete(Index: Integer); begin Objects[Index].Free; inherited; end; procedure TMyStringList.Clear; var i: integer; begin for i:= 0 to Count - 1 do Objects[i].Free; inherited; end; destructor TMyStringList.Destroy; var i: integer; begin for i:= 0 to Count - 1 do Objects[i].Free; inherited; end;

← →
Crusader (2013-01-09 11:33) [7]

> Лучше использовать так называемый виртуальный режим, когда
> контрол не хранит данные непосредственно, а запрашивает
> их для рисования из внешнего списка. А уж внешний список
> может быть организован как угодно. Может подойдет?

то что надо, спасибо за совет

← →
sniknik © (2013-01-09 11:42) [8]

вообще то, в объектах тоже не данные хранятся, а ссылки. вот строки, в стринглисте, их можно считать данными.
тут разделение даст лишний "геморрой", ИМХО, и вообще, опять ИМХО, DVM давая совет спутал со StringList с StringGrid-ом.

← →
DVM © (2013-01-09 11:50) [9]

> sniknik © (09.01.13 11:42) [8]

> DVM давая совет спутал со StringList с StringGrid-ом.

Я TListBox упомянутый выше имел в виду.

> тут разделение даст лишний "геморрой", ИМХО

Ну как сказать, писать кода придется больше, да. Но как только возникнет необходимость данные списка использовать еще где либо или изменить интерфейс или вообще убрать интерфейс - переделок/доработок будет меньше. Разделение данных и представления опять же. Не всегда оправдано конечно, смотря что за список и что с данными потом надо делать.

> sniknik © (09.01.13 11:12) [6]

Опа. Слушайте, а в TStrings Delete и Clear всегда виртуальными были? Или я с TList путаю?
Просто помню, что там Notify надо было перекрывать, а публичные, вроде, статичными были...

> или вообще убрать интерфейс
"авторский" TStringList и так не визуальный, а TListBox это от RWolf путаница...

> а в TStrings Delete и Clear всегда виртуальными были?
ну, в D7 уже точно.

и в TStringList, в TStrings они вообще абстрактные.

> и в TStringList, в TStrings они вообще абстрактные.

Ну это понятно. Я просто с TList и его Notify спутал.

очистка StringList Найти похожие ветки