Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Правила хорошего тона при работе с INI-файлами ??? [D5, Win95/98]

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

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

ShaggyDoc (2002-01-08 07:31:00) [1]
Еще по поводу кэширования ИНИ-файлов:

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

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

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

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

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

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

panov (2002-01-04 21:30:00) [2]
>Юрий_К © (04.01.02 18:11)
Каждому пользоватедю создается свой ini-файл. Вот и все.

Юрий_К (2002-01-04 18:11:00) [3]
А как будут обстоять дела с этим INI-файлом, если прога работает в сети и разные юзера могут вностьи коррективы в INI-файл ???

ReNoiZer (2002-01-04 16:53:00) [4]
Народ уже давно пора переходить на XML
TClientDataSet- все что для этого нужно

SergVlad (2002-01-04 15:36:00) [5]
Ну если уж заговорили об текст. файлах для работы с которыми используется 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 файла разными приложениями
не считаю правильным. Ну не БД это, в самом деле.

ShaggyDoc (2002-01-04 12:39:00) [6]
Очень много работаю с ИНИ, в том числе использую даже в виде МИНИ-ИНИ-СУБД (такова специфика)

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

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

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

SergVlad (2002-01-04 12:14:00) [7]
Не должно смущать интенсивное переоткрытие и чтение из Ini при открытии приложения - он попадает в кэш операционной системы.

gek (2002-01-04 11:55:00) [8]
Я также как panov делаю.

TonnyS (2002-01-04 11:53:00) [9]
я все настройки держу в INI, не люблю лазить по реестру, тем более найти/отредактировать INI значительно быстрее, а так же проще скопировать их куда-нибудь при переустановке винды.

Алексей Петров (2002-01-04 11:09:00) [10]
Я согласен, что в реестре не все стоит хранить. Сам обычно делаю cfg файл.

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

Юрий_К (2002-01-04 10:59:00) [11]
Алексей Петров
Дело в том, что не всегда можно воспользоваться реестром, и предпочитаю реестр для лично индивидуальных настроек, а INI -для общих

panov (2002-01-04 10:52:00) [12]
А я не люблю программы, использующие реестр.
С INI работаю так:
В начале программы считываю необходимые в большинстве случаев параметры в глобальные переменные, а в некоторых обособленных местах программы загружаю только необходимые параметры.

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

Алексей Петров (2002-01-04 10:42:00) [13]
Правила хорошего тона от Ms:
Не пользоваться INI, а писать в Registry - это одно из условий сертификации программы Ms-ом.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »