Форум: "Начинающим";
Текущий архив: 2006.12.17;
Скачать: [xml.tar.bz2];
ВнизХотел бы посоветоваться... Найти похожие ветки
← →
ProgRAMmer Dimonych © (2006-12-01 21:41) [0]Есть программа. Использует INI-файл, в котором хранятся её настройки. Открывается этот файл через TMemINIFile. Периодически программа обращается к INI-файлу: загружает, обрабатывает, выгружает.
После того, как программа прерывается из диспетчера задач, при повторном запуске, время от времени выводится сообщение об ошибке. Приблизительное содержание: не удаётся получить доступ к файлу <Имя INI-файла+Полный путь к нему>, т.к. файл занят другим процессом.
Что вы делаете в своих программах, чтобы не возникало этой проблемы?
← →
Джо © (2006-12-01 21:51) [1]> Что вы делаете в своих программах, чтобы не возникало этой
> проблемы?
Если программу приходится снимать при помощи Ctrl-Alt-Del и принудительного убиения процесса — то это внештатная ситуация. Что тут предусмотришь? Постараться писать программу так, чтобы не пришлось ее насильно убивать из менеджера задач.
← →
ProgRAMmer Dimonych © (2006-12-01 21:59) [2]> Джо © (01.12.06 21:51) [1]
> Постараться писать программу так, чтобы не пришлось ее насильно
> убивать из менеджера задач.
Это обучающая программа. Во время урока выводится определённый блок информации. Логичнее всего убрать как можно больше способов прерывания работы программы на этом этапе.
finally не помогут случайно?
Или придётся убивать диспетчера?
← →
Sam Stone © (2006-12-01 22:40) [3]> [2] ProgRAMmer Dimonych © (01.12.06 21:59)
TIniFile.Create
try
бла-бла-бла
finally
TIniFile.Free;
end;
Стандартная конструкция для предотвращения всяких гадостей.
← →
ProgRAMmer Dimonych © (2006-12-01 22:54) [4]> Sam Stone © (01.12.06 22:40) [3]
Т.е. finally должно сработать?
← →
Kolan © (2006-12-01 22:59) [5]Сомневаюсь что код в finally отработает. А если питание вырубить? :)
А зачем TMemINIFile, почему не TIniFile?
← →
Джо © (2006-12-01 23:02) [6]Никакой finally в данном случае не спасет.
← →
ProgRAMmer Dimonych © (2006-12-01 23:08) [7]> Kolan © (01.12.06 22:59) [5]
Удобнее в некотором роде... Когда вносятся изменения. Вместо того, чтобы каждый чих сохранять отдельно, вносим все изменения в копию файла в памяти и вызываем UpdateFile.
← →
Джо © (2006-12-01 23:10) [8]> [7] ProgRAMmer Dimonych © (01.12.06 23:08)
> > Kolan © (01.12.06 22:59) [5]
> Удобнее в некотором роде... Когда вносятся изменения. Вместо
> того, чтобы каждый чих сохранять отдельно, вносим все изменения
> в копию файла в памяти и вызываем UpdateFile.
Странный выбор, если требуется как раз максимальная "отказоустойчивость".
← →
Kolan © (2006-12-01 23:11) [9]> Удобнее в некотором роде... Когда вносятся изменения. Вместо
> того, чтобы каждый чих сохранять отдельно, вносим все изменения
> в копию файла в памяти и вызываем UpdateFile
Видимо поэтому и остается он открытым при убиении процесса... С TIniFile я такого ненаблюдал. А зачем настройки вечно сохранять загружать? Обычно загружешь в начале сохраняешь в конце или при изменении(по комманде пользователя)...
← →
ProgRAMmer Dimonych © (2006-12-01 23:14) [10]> Kolan © (01.12.06 23:11) [9]
> А зачем настройки вечно сохранять загружать? Обычно загружешь
> в начале сохраняешь в конце или при изменении(по комманде
> пользователя)...
В разных процедурах и даже разных юнитах, поэтому удобнее использовать локальные переменные-объекты. Ну, и перечитывать приходится. Можно, конечно, сделать что-то типа MainForm.SomeINIFile..., но как-то не было желания...
← →
ProgRAMmer Dimonych © (2006-12-01 23:15) [11]> Джо © (01.12.06 23:10) [8]
> Странный выбор, если требуется как раз максимальная "отказоустойчивость".
По идее, если запись происходит один раз, а не несколько, то вероятность попадания Crtl+Alt+Del на момент записи меньше. Или, может быть, мне стоит почитать исходник TMemINIFile? Я как-то не удосужился...
← →
Kolan © (2006-12-01 23:17) [12]> [10] ProgRAMmer Dimonych © (01.12.06 23:14)
> > Kolan © (01.12.06 23:11) [9]
> > А зачем настройки вечно сохранять загружать? Обычно загружешь
>
> > в начале сохраняешь в конце или при изменении(по комманде
>
> > пользователя)...
> В разных процедурах и даже разных юнитах, поэтому удобнее
> использовать локальные переменные-объекты. Ну, и перечитывать
> приходится. Можно, конечно, сделать что-то типа MainForm.SomeINIFile...,
> но как-то не было желания...
Имхо, настройки же одни для всей программы. Лучьше сделать синглетон "менеджер настроек" при старте загружать их, при завершении/изменении сохранять. А если понадобились то дергать сам менеджер.
ЗЫ
И использовать просто TIniFile.
Страницы: 1 вся ветка
Форум: "Начинающим";
Текущий архив: 2006.12.17;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.058 c