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

← →
ЮРИЙ_К © (2002-01-04 10:37) [0]

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

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

← →
Алексей Петров © (2002-01-04 10:42) [1]

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

← →
panov © (2002-01-04 10:52) [2]

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

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

← →
Юрий_К © (2002-01-04 10:59) [3]

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

← →
Алексей Петров © (2002-01-04 11:09) [4]

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

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

← →
TonnyS © (2002-01-04 11:53) [5]

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

← →
gek (2002-01-04 11:55) [6]

Я также как panov делаю.

← →
SergVlad © (2002-01-04 12:14) [7]

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

← →
ShaggyDoc © (2002-01-04 12:39) [8]

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

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

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

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

← →
SergVlad © (2002-01-04 15:36) [9]

Ну если уж заговорили об текст. файлах для работы с которыми используется 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-то и они могут обработать.

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