Отсюда рассуждение: если появятся "указатели" на программные модули, то где планируется хранить "счетчики ссылок"

сразу хотел бы пояснить: если в ini файле вводить такой раздел и в дальнейшем использовать его как список удаляемых модулей при деинсталяции компонента, то есть шанс удалить юниты, используемые не только этим компонентом, но и другими.

Galkov и Dilma, пояснение весьма к месту, но оно только уточняет положение дел, не снимая остроты. Не хочу с ходу предлагать сырые решения, но хочу подчеркнуть, что проблема этого "узкого места" имеется, причем, уже давно, и без каких-то изменений уйти от этой проблемы не удастся.
Посему и честно предложил потолковать на эти темы в отдельном топике (но: этого же раздела )

Dilma, можно скажем сделать так

[files]
own=file1,file2,file3 - удаляем вместе с элементом
other=file4,file5,file6 - предупреждаем и спрашиваем ?
necessary=file7,file8,file9 -файлы которых нет в инсталляции, но без которых не будет работать.(на будущее для инсталлятора)

Особенно понравилось "предупреждаем и спрашиваем " - а кто знает?
Наверное проще (для пользователя) перед удалением элемента
1) открываем его hixxxxxx.pas файл
2) читаем строки от uses до ";"
3) отбрасываем имена типа Windows, Kol, Debug. (т.е. те, что заведомо используются не только им)
4) на оставшиеся имена шерстим во всех остальных элементах строку uses , если есть - отбрасываем.
5) предупреждаем - "При удалении компонента будут удалены файлы: с п и с о к" и спрашиваем "удалить".
Да это намного дольше, но надежнее.
При удалении компонента, я так и поступаю. Правда все делаю ручками
Если бы каждый компонент с его файлами хранился бы в отдельной папке, то было бы вообще просто. Вот сколько "бы"

[size=-2]------ Добавлено в 09:34
завтра попробую, написанное выше, реализовать на HiAsm

Своё обещание выполнит не могу, ибо накрылся ноут с наброском системы. Сроки ремонта неизвестны.

на мой взгляд более красивым решением было бы избавиться от необходимости лазить в папку code вообще.

По большому счету vau_HI, уже все изложил, что необходимо сделать. Все остальные дополнения нужно вносить в рамках данных предложений.

А на мой взгляд - недопустимо обратное (т.е. - некрасивое)

Некрасивые решения часто используются как временные затычки

Мне кажется нет тут никакой проблемы ,Удаляем компонент то есть файлы pas.ini.ico и всё если даже к компоненту прилагалась какая то библиотека то пусть она останется(кому она мешает )
ну полежит она 3 месяца до переустановки новой версии .

Что касается именно менеджера компонентов, я, по моему мнению, не могу предлагать взвешенные решения, так как все вопросы, связанные с компонентами я не решаю. Не в силах решать. Не знаю как. Единственное что хочется по компонентам это:

в случае если компонент стандартный, т.е. принадлежит к дистрибутиву, должна контролироваться для компонента идентичность, ну может я не правильно выразился, общем целостность принадлежности именно к нему, дистрибутиву. Если компонент в последствии модифицируется, ну например как здесь, при компиляции, ну и в менеджере компонентов тоже, должно быть об этом указано. Отсюда вывод: сделать в менеджере компонентов опцию: сообщать об изменении стандартных компонентов при компиляции.

я очень хочу получить статистику по проекту. Что я имею ввиду: сейчас статистика= msgbox c перечислением сколько всего. Очень помогло бы при разработке и продвижении схем расширенная статистика - а именно: - html страничка с таблицей используемых компонентов (например вот так:

[burl=www.hiasm.hexshock.com/wiki.php?view=31]Иконка компонента[/burl]	[burl=www.hiasm.hexshock.com/wiki.php?view=34]Название: Количество в проекте[/burl]	[burl=www.hiasm.hexshock.com/xf/topic.php?t=77]Идентичность стандартному[/burl]
	МеморуStatus: 2	+

я подчеркиваю, например, т.к. хотелось бы видеть таблицы с разбивкой по группам элементов.

Не однократно говорилось об этом и писалось в форуме, предоставить возможность пользователю HiAsm редактировать некоторые настройки компонента: а именно - менять иконку, перемещать компоненты из группы в группу, модифицировать (добавлять или изменять) настройки компонента в INI файле (который можно было в дань моде заменить XML), модифицировать код компонента (pas) - не возмущайтесь - это и сейчас уже есть и давно было - предоставить возможность делать это более удобно, или скажем так, более насыщенно современными интерфейсными решениями а-ля Microsoft, из среды разработки.

сделать Drag&Drop в панели элементов.

Добавить хорошую справку
Т.к. я не владею способностями по написанию компонентов в моем предложении может быть и есть рациональное зерно, но найти его можете только Вы, Dilma. Так что особо сильно за предложения не пинайте.

Хороший повод наконец таки изучить что-то типа SQL Lite и на основе его сделать новый набор компонент, а так же весь менеджер.

Вячеслав, удаляем или переносим в папку HiArh)имя_компонента, а при желании установить его назад - автоматом создается hic файл и запускается.
Насчет размещения компонентов в вопрос спорный, хотя, если делать резервную копию базы перед внесением нового элемента (для отката) или каждому пользователю установить ИБП (UPS), то идея очень даже приемлема. Но это только мое мнение

Tad, Да это хорошая идея не удалять компонент, а перемещять в другую папку (потом всегда можно сделать откат).

vau_HI, здесь я с вами не согласен. Размер кластера на моем винте 32KB, а максимальный размер ini файла, например, не превышает 5KB. То есть 80% дискового пространства расходуется впустую. А если мы будем каждый элемент помещать в отдельный каталог, то будет еще хуже.