там в config.fpw есть
TMPFILES=c:\INCOME
EDITWORK=c:\INCOME
SORTWORK=c:\INCOME
PROGWORK=c:\INCOME

И мне надо программно эти настройки поменять!
Хотя бы чтоб, SYS(2023) - Temporary Path выдавало то, что я сам задам уже в приложении.
Я может туплю, не получается. Ищу Set ... TO ...



Исправлено 1 раз(а). Последнее : Ydin, 03.01.22 22:38

Изменить то можно, но изменения считаются только после перезапуска

Может быть, можно сделать переприсвоение маршрута c:\INCOME через переменную окружения Windows командой SET?

Если можно, то тогда это надо делать, например, в bat-файле перед загрузкой приложения FoxPro. А после завершения приложения FoxPro в том же батнике можно вернуть "оригинальный маршрут" для c:\INCOME

Это на уровне "идеи", так сказать.

Simple777
в bat-файле перед загрузкой приложения FoxPro

Chemberzhy
изменения считаются только после перезапуска

И нахера огород городить, когда при таком раскладе можно просто сам config.fpw изменить?

Нет, там все легко, но сейчас надо именно так, в рантайме!
Сейчас надо именно в рантайме, долго объяснять. Там где-то за 30 предприятий и туда ездить долго, а сам исполнимый файл (это Фреймворк) мы обновляем легко.
Через общую для них БД. Это я так говорю, чтоб коротко. Короче сейчас мне надо именно так. Думал, что 2 пальца, похоже, что больше.
Просто думал, что я туплю или забіл, а все знают. Там мелко, человек с отпуска вернется и порешаем. Но очень хотелось в Exe сразу поставить. Завтра.
Не парьтесь, с Bat-файлами нет, тут другая схема.
- Там переменное значение должно быть. Вычисляется легко, но по месту


Исправлено 3 раз(а). Последнее : Ydin, 03.01.22 23:10

Ydin
Нет, там все легко, но сейчас надо именно так, в рантайме!

Ну раз сильно надо - обращайся к Чену, пусть добавляет такую возможность в своей версии VFP. Обычный фокс считывает эту установку лишь единожды, при запуске, и далее уже не меняет. Независимо от того, читает он TMPFILES из config.fpw (если таковой параметр в этом файле имеется), или же читает он TMP/TEMP переменные окружения винды (если параметры в config.fpw не заданы).

P.S. Задавать все 4 параметра в config.fpw в одно и то же значение не имеет никакого смысла - хватит одного лишь TMPFILES. Да и тот нужен лишь если по какой-то причине не подходит использование штатной временной папки винды. Лично я никогда эти пути в конфиге не задавал - не было такой надобности.

Цитата:

Независимо от того, читает он TMPFILES из config.fpw (если таковой параметр в этом файле имеется), или же читает он TMP/TEMP переменные окружения винды (если параметры в config.fpw не заданы).

Для полноты картины - если программа запускается через PRG, FXP или APP, то при отсутствии TMPFILES в config.fpw этот параметр сначала ищется в реестре, куда попадает из Tools -> Options -> File locations -> Temporary Files.

Спасибо всем! Вопрос снят.

Бли-и-и-и-ин.., мы только размялись

Не горюй, ведь не последний
То у фрица самолёт.
;)

Simple777
Не горюй, ведь не последний
То у фрица самолёт.
;)

Не промедливши с ответом,
Парень сдачу подает:
— Не горюй, у немца этот —
Не последний самолет!

;)

akvvohinc
Для полноты картины - если программа запускается через PRG, FXP или APP, то при отсутствии TMPFILES в config.fpw этот параметр сначала ищется в реестре, куда попадает из Tools -> Options -> File locations -> Temporary Files.

Точнее сказать, "если запускается IDE". Там уже не суть важно начнёт что-то сразу исполняться, и как именно (можно настроить _STARTUP или COMMAND, так что даже банальное открытие dbf или frx будет сопровождаться исполнением некоторого пользовательского кода). Кстати, при запуcке IDE можно ключиком отключить чтение конфигурации из реестра (и config.fpw файла тоже). В т.ч. можно прописать этот ключик на файловые ассоциации ОС (команды, которыми винда запускает фокс если пытаться открывать prg,fxp,dbf и т.д.)

Не очень хорошее решение -использование таймера в программе,
по его событию читать config.fpw
и делать изменившиеся set
Я такой трюк использую в тех моих программах,
что работают ночью или по расписанию на сервере.
Сам я на сервер залезь прав не имею.
Скажем, нужно мне остановить текущее исполнение на сервере,
чтобы что-то поменять в таблицах в монопольном режиме.
Проставляю в управляющем файле некий флаг, таймер его видит,
конечно не сию секунду, и роняет программу.
Она сама запуститься на сервере по расписанию, я то запустить там тоже не могу.
Но за время, пока программа не работает, делаю то, что мне нужно.

boba
Не очень хорошее решение -использование таймера в программе

Для фокса - нормальное решение. Сам так делал для автообновления, и в т.ч. "выгнать всех из программы для административных процедур" - типа обновить структуру фоксовой БД, или принудить юзеров перейти на свежую версию (т.к. после перезапсука уже запустится новый exe или набор файлов fxp и т.п.)
Я делал несколько таких файлов-флагов. Для собственно "кода", для БД (в папке с dbf-ами). С разными grace period (интервалом когда можно "погодить" с обновлением и завершить текущую работу с программой - не в смысле побыстрее закрыть её, а добить "документ" или там закончить "печать отчётов").
Если юзер вообще не реагирует на диалог "вышла новая версия, надо бы обновиться" - т.е. "уснул" или уехал в отпуск на месяц, то прога по истечении этого периода (вроде ставил на 10-15 минут, точно не помню уж) закрывается принудительно.
Да, сами файлы-"флажки" создаются прогой-обновителем (или же вручную оператором) в режиме "открыл и держу" - т.е. такой файл нельзя удалить или повторно создать пока он заблокирован - а значит и при запуске проги (если кто-то хитрый решил быстро перезапустить её, а админ-процессы ещё не завершены) можно вывесить сообщение "постой, паровоз" - и не пускать к реальной работе.

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

Смотря какое окно. Даже "системный" MESSAGEBOX можно в принципе "снаружи" (из таймера) закрыть и обойтись без аварийного убийства процесса. Свои собственные формы - тоже вполне закрываемы. Да, это не самый тривиальный код, и сильно зависит от применяемого подхода к UI но в принципе решаемо.

Проще сделать прибор из тех кубиков, которые есть в VFP, и не париться (изучение других фреймверков над СПП и и СШарп), ну... в моем случае. Все пазлы, из которых можно построить все, есть

Доб. Это я про "все решаемо"



Исправлено 1 раз(а). Последнее : of63, 11.01.22 22:59