Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 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
15-1164392601
furyz
2006-11-24 21:23
2006.12.17
Так сяк


4-1155094525
Старик
2006-08-09 07:35
2006.12.17
Иконка и курсор главной формы.


4-1154629515
ancara
2006-08-03 22:25
2006.12.17
определить момент подключения USB-накопителя


15-1164462735
Оззя
2006-11-25 16:52
2006.12.17
1-е число Мерсенна


15-1164569116
Piter
2006-11-26 22:25
2006.12.17
Забавный глюк миранды





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский