> -- Илья Ермаков писал(а):
> По поводу определения, когда объект больше не показывается на экране... Здесь можно пойти таким путем - через модуль Windows искать открытые кадры, связанные с отображением. Если их нет, то можно останавливаться...
Вы, наверное, предлагаете пойти тем же путем, что Views.Omnicast (я не смотрел, как он реализован, но суть в том, что рассылается сообщение всем видимым View). Проблема с этой процедурой в том, что ее оповещения приходят только к тем View, которые хотя бы частично видны на экране. Я думаю, где-то существует их глобальный список для целей прорисовки, и по этому списку делается проход. Но активный объект должен быть активен даже если он не отображается. Если он скрыт из поля зрения из-за прокрутки, он все равно должен периодически сохранять текущие значения параметров. Так что наличие фрейма - не показатель, если только вы не возьметесь утверждать, что для каждого View, встроенного в потенциально отображаемую часть документа, всегда есть хотя бы один фрейм. Включая View, свернутые в Fold?

По-моему, просто фреймворк не разрабатывался для соответствия тем требованиям, которые предъявляют активные объекты. Работа с Models, Views и документами построена на тех же принципах, что работа с памятью, а память принципиально пассивна. Есть место для развития, но лучше оставить существующее простое решение. Главное - понять, что за ним стоит. При большом желании с моей стороны, наверное, можно было бы разработать специализированный контейнер или wrapper, отслеживающий удаление активных компонентов. И, кстати, создать глобальный базовый абстрактный тип для таких компонентов. Хм...

> -- Илья Ермаков писал(а):
> Я тоже сталкивался с проблемой регистрации объектов в глобальных списках. Зарегистрировав объект в списке, мы создаем на него глобальный якорь. Но таким образом список не может узнать сам, когда объект более не нужен! N-е время назад я написал процедурку, которая позволяет искать на низком уровне все ссылки на объект (как это делает Kernel.Mark) и сделал в модуле-регистраторе некий высокоуровневый сборщик мусора, который периодически проверял, остались ли на объекты внешние ссылки, и если нет, то исключал их из списка - а далее их "добивал" обычный сборщик Сейчас, переписывая рантайм, я позаимствовал одну хорошую идею, которая есть в .NET - слабые указатели (weak pointers). Слабый указатель - это ссылка на объект, которая не является якорем. Когда нам нужно работать с объектом, мы можем запросить у слабого указателя обычный указатель. Если нам вернут NIL, то мы видим, что объект уже собран сборщиком мусора.
Идея слабых указателей в самом деле решила бы эту проблему (заодно добавив новые?). Еще один вариант решения - счетчик ссылок: как только остается ровно одна ссылка, мы знаем, что это ссылка из глобального списка, и объект можно выбрасывать. К сожалению, оба эти решения требуют переделки рантайм-системы. А вот высокоуровневый сборщик мусора мне бы мог понравиться, если он эффективен. Можете поделиться кодом?

> -- Илья Ермаков писал(а):
> А вообще, с многопоточностью все равно работать гораздо лучше, нежели без нее
Конечно, лучше! : )
Осталось только договориться о том, что значит "лучше", не так ли? ; )