Бобков ИльяDima T, У меня на этот случай есть вторая проверка (программа завершена не корректно). И всё работает. Просто сбрасываю переменную с копией экземпляра приложения и всё.
Можно уточнить каким образом выполняется эта проверка? Переменная физически где находится? В том же mem-файле? Как Вы по значению переменных отличаете завершенную не корректно программу от программы, которая сейчас продолжает работать?

sg12Dima T

Из хелпа:

SAVE TO Команда - Сохраняет текущие переменные памяти и массивы в файле переменных памяти или в memo-поле.
RESTORE FROM Команда - Извлекает переменные памяти и массивы переменных памяти, сохраненные в файле переменных памяти или в memo-поле, и помещает их в память.
И каким образом это помогает решить поставленную задачу? Как Вы планируете отличить содержимое mem-файла, созданного работающей в данный момент программой, от содержимого mem-файла, оставшегося без изменений вследствие аварийного завершения работы (сбой)? Во втором случае нет работающего приложения, но mem-файл выглядит так, как-будто приложение продолжает работать.

sg12Можно так: По окончании первая переменная записывается в mem-файл и проверяется через RESTORE.
При удачном завершении значение второй переменной меняется и также сохраняется. При отказе ее значение в mem-файле не меняется.
В принципе, можно обойтись и одной переменной на три значения, но это на любителя.
Давным давно, во времена Win 3.11 один из вариантов решения задачи запрета одновременного запуска нескольких копий одного и того же приложения было создание файла при запуске и удаление при выходе. Т.е. последовательность действий была такая

1. При старте приложения ищем файл с определенным именем, находящийся в определенной директории
1.1. Если такого файла нет, то это означает, что других копий приложения запущено не было. Значит, можно запускать приложение.
1.2. Если такой файл найден, то это означает, что данное приложение уже было запущено. Пользователь пытается запустить его второй раз. Значит, запускать нельзя
2. Если приложение было запущено, то при старте указанный файл создается в указанной директории
3. При завершении работы приложения файл удалялся

Т.е. даже не важно, что там внутри файла находится. Достаточно самого факта существования файла.

На первый взгляд, кажется, что схема идеальная. Но это только на первый взгляд. Представим себе ситуацию, когда приложение было завершено, но файл не удалился. Что получим? При попытке запустить приложение, мы видим, что файл есть. Значит, приложение запускать нельзя.

Как следствие, после такого события приложение невозможно будет запустить, пока программист вручную не удалит файл с диска. Чем, собственно, программисты, реализовавшие такую схему контроля, периодически и занимались... Нештатное завершение приложения (удалили процесс) - зови программиста. Без вариантов...

Так вот, добавление некоего содержимого в это файл проблему не решит. Никак. Ведь любые изменения содержимого предполагается вносить в этот файл при штатном (корректном) завершении приложения. Если же приложение было завершено не корректно, то содержимое файла останется неизменным. Таким, какое оно есть в процессе работы приложения. Но ведь приложение уже не работает! Как следствие, снова требуется ручное вмешательство программиста, чтобы запустить приложение.

Вы снова вернулись к началу истории программирования. Снова наступаете на те же грабли...

sg12Примеры кода есть в ссылке, которую я чуть выше вам дал.
Где? Что-то я тоже не вижу никаких Ваших ссылок в этой теме...

sg12ВладимирМ

История дело интересное.
Но в теме речь идет о переменной, а не файле-семафоре - это разные решения, не надо путать.
Даже новичок ТС заметил, что нужно делать две проверки, а не одну.
Что и я пытался вам объяснить.
В своем примере выполните вторую проверку и он заработает.
Примеры для ДимыТ из хелпа - надо в нем набрать "SAVE TO".
Так ПОКАЖИТЕ свой пример? ГДЕ Вы его привели?

И еще раз, любой анализ переменных основан на том факте, что вы ШТАТНО завершили приложение. Т.е. непосредственно перед выходом как-то там изменили переменные. А если выход был НЕ штатным. Т.е. выйти-то вышли, а вот переменные не изменились. Ваш пример, который Вы неизвестно где привели, эту проблему решает?

Переменные внутри файла - это всего-лишь "бантики". Принципиально НИЧЕМ не отличаются от факта создания-удаления файла. Разве что, это более сложное решение.

aswsВладимирМ,

Файл нужно держать открытым во время работы программы - тогда проблем не будет.
Не лень было так подробно расписывать очевидные недостатки криворукого решения, когда файл не держится программой окрытым?
Я исходил из предположения, что объясняю человеку, который искренне заблуждается. Показал в чем ошибочность выбранного способа решения

aswsМеханизм открытия файла в монопольном режиме прост и универсален, потому что даёт возможность гибких решений,
Чем этот вариант отличается от банальной блокировки записи в DBF-таблице? Вот ЭТО действительно просто и понятно для программиста FoxPro. Более того, чрезвычайно гибко и удобно. А с файлами, встает вопрос администрирования доступа.

А вопросы администрирования доступа к файлам и директориям в настоящее время уже достаточно сложен. Судя по уровню вопросов спрашивающих, решить эту проблему они не смогут. Скорее всего, у большинства пользователей просто не будет прав на создание и блокировку файлов в ряде директорий. Придется "мудрить" не с расположением, а с именами файлов. Т.е. ни о какой "простоте" и "понятности" не может быть и речи...