Правила хорошего тона при работе с INI-файлами ???

Коллеги, подскажите, PLS, как правильно нужно работать с INI-файлами? В программе параметры решил сохранять в INI-файле. При первоначальной загрузке считываю эти данные. Затем, есть места, где приходится в одной форме не единожды обращаться к этому файлу. Т.е. процесс -> (Инициализация INI-файла, считывание данных,освобождение памяти) происходит очень интенсивно. Правильно-ли это? Может нужно объявить глобальные переменные и один раз считать данные и присвоить переменным? Подскажите, что
является правилом хорошего тона программирования при работе с INI-файлами?

Заранее благодарен.

Правила хорошего тона от Ms:
Не пользоваться INI, а писать в Registry - это одно из условий сертификации программы Ms-ом.

А я не люблю программы, использующие реестр.
С INI работаю так:
В начале программы считываю необходимые в большинстве случаев параметры в глобальные переменные, а в некоторых обособленных местах программы загружаю только необходимые параметры.

Причем использую таким образом:
//считывает конкретный параметр
function GetParm(aParmName: String): String;
var
ini: TIniFile;
begin
ini := TIniFile.Create(...);
...
ini.Free;
end;
т.е. для чтения каждого параметра открываю и закрываю ini-файл.
Даже если файл занимает сотню-другую Кб, мне все равно удобнее воспользоваться функцией.

Алексей Петров
Дело в том, что не всегда можно воспользоваться реестром, и предпочитаю реестр для лично индивидуальных настроек, а INI -для общих

Я согласен, что в реестре не все стоит хранить. Сам обычно делаю cfg файл.

А на счет INI - это не мое мнение, а вычитанное где-то в MSDN. Где точно - не помню.

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

Не должно смущать интенсивное переоткрытие и чтение из Ini при открытии приложения - он попадает в кэш операционной системы.

Очень много работаю с ИНИ, в том числе использую даже в виде МИНИ-ИНИ-СУБД (такова специфика)

Выработал для себя правила хорошего тона:

1. Наплевать на предписания MS. Следуя этой хренотени все программы, а в них почти все окошки, норовят все сведения о себе писать в реестр. А он не резиновый. Причем, чем вшивее программа, тем больше она мусора пишет.
2. Не забывать, что в ИНИ можно хранить все, что угодно. Вплоть до того что...
3. Использовать всегда TagIniFile. Работает в десятки раз быстрее, нет ограничений на размер файла.
4. Кэширование ИНИ иногда оказывается очень вредным. Приходилось сталкиваться с тем, что данные изменены одной программой, а другой, или этой же - берутся из кэша.

Согласен с panov ©. Скорость работы с ИНИ (обычных размеров) не критична. Просто незаметна, поэтому вполне можно сделать работу через функции, хотя иногда, для чтения большого количества значений, лучше делать за один прием.

Ну если уж заговорили об текст. файлах для работы с которыми используется TIniFile..
Моя практика такова:
1. Использую, в основном, для сохранения настроек формы(размеры, позиция, значения св-ва компонентов).
2. Файл ini один, поименован и связан с конкретным приложением.
3. Каждая создаваемая в run-time форма "заводит" свою секцию, где и пишутся присущие ей значения.
4. Самый первый наследник от TForm (а все остальные формы наследуются от него), обладает методами и св-ми для работы с ini файлом приложения.
Например
procedure SaveFormPos(Sender: TObject);
function LoadFormPos(Sender: TObject): string;
function GetIniFileName: string;
function ReadIntegerIni(const Key: string; Default: Longint): Longint;
procedure WriteIntegerIni(const Key: string; Value: Longint);
function ReadStringIni(const Key: string; Default: string): string;
procedure WriteStringIni(const Key: string; Value: string);
procedure ReadSectionValuesIni(const Section: string; Strings: TStrings);
property pIniFileName: string read GetIniFileName write FIniFilename;
property pSectionName: string read FSectionName write FSectionName;

5. Использование одного и того же Ini файла разными приложениями
не считаю правильным. Ну не БД это, в самом деле.

Народ уже давно пора переходить на XML
TClientDataSet - все что для этого нужно

А как будут обстоять дела с этим INI-файлом, если прога работает в сети и разные юзера могут вностьи коррективы в INI-файл ???

Еще по поводу кэширования ИНИ-файлов:

Вредные эффекты проявляются по разному в разных версиях Windows.
Иногда наблюдается ошибочное чтение в случае, если секции или переменные имеют схожие имена.

Пару дней назад делал безобидную программку для показа "Советов дня". Строки советов в секции [Tips], переменные Tip1...Tipx.
В секции [TipsSetup] записывается номер последнего совета.

Win98 читает с ошибками! Стоило изменить имя секции на [Setup] - все стало нормально. Под NT и 2000 все нормально.

С подобными ситуациями сталкивался не раз.

Свои программы, разбирающие файл самостоятельно, делают все правильно.

А использовать один INI-файл для разных программ приходится. Типичная ситуация в ГИС - разные программы, на разных базовых платформах и ОС должны обмениваться данными. Не все пишут, но читают все. В том числе такие, которые в принципе не могут работать с БД, так как умеют только читать-писать текстовые строки. Но INI-то и они могут обработать.

EMAIL={{}};LOGIN={{ЮРИЙ_К}};TITLE={{Правила хорошего тона при работе с INI-файлами ???}};ATTRIBUTES={{}};ID_MSG={{9358}};ID_GROUP={{1}};ID_NNTP={{3400}};ID_DM={{75606}};REPLYNR={{0}};ID_DM_AUTHOR={{0}};ARCHIVE={{2002.01.24}};REPLYDATE={{2002-01-04 10:37}};CNT={{13}};