"D:\Books_e\LibRusLib\Script\fb2lrf_c.exe -i %F -o %f.lrf -s default_styles.sini" ищет default_styles.sini в директории, откуда запущен LibRusLib - и, конечно, не находит так как его там нет.

Если специфицировать "D:\Books_e\LibRusLib\Script\fb2lrf_c.exe -i %F -o %f.lrf -s D:\Books_e\LibRusLib\Script\default_styles.sini" то пакетная обработка начинает работать.

Нельзя ли правильно выставлять lpCurrentDirectory при выдаче CreateProcess либо считая ее всегда такой-же как и путь запускаемой программы, либо позволить вводить этот путь в диалоге настроек пакетной обработки как сделано в shortcut propierties в Windows - "Start In"?

Добавлено (24.01.2010, 02:38)
---------------------------------------------
Можно ли сделать так, чтобы окно процесса пакетной обработки не прыгало на экран? Например выставив wShowWindow в CreateProcess в SW_HIDE и указав в dwFlags STARTF_USESHOWWINDOW?

Еще неплохо было бы редиректнуть output этих программ а то очень трудно понять когда возникает ошибка - STARTF_USESTDHANDLES в тех же dwFlags

абсолютно правильно. ведь пакетные операции - это не только данный скрипт, а любой другой, пути к файлам которого могут располагаться где угодно.

Вот тебе функция запуска скрипта. Что ты хочешь тут изменить?

function TMAINFORM.RunScript(prg,param: string):Boolean;
var
SEInfo: TShellExecuteInfo;
ExitCode: DWORD;
begin
FillChar(SEInfo, SizeOf(SEInfo), 0);
SEInfo.cbSize := SizeOf(TShellExecuteInfo);
with SEInfo do
begin
fMask := SEE_MASK_NOCLOSEPROCESS;
Wnd := Application.Handle;
lpFile := PChar(prg);
lpParameters := PChar(Param);
// lpDirectory := PChar(StartInString);
nShow := SW_SHOWNORMAL;
end;
if ShellExecuteEx(@SEInfo)
then
begin
repeat
Application.ProcessMessages;
sleep(1);
Application.ProcessMessages;
GetExitCodeProcess(SEInfo.hProcess, ExitCode);
until (ExitCode <> STILL_ACTIVE) or Application.Terminated;
end
else ShowMessage('Ошибка запуска '+prg);
end;

nShow := SW_SHOWNORMAL;

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

Неплохо бы.. Но, честно говоря, не знаю как

Дык, они и не могут считаться скачанными... Иначе, у меня все записи горели бы зеленым А если хочешь, что бы считались скачанными - распакуй дейли, кинь их на время в каталог скачиваемых файлов (можно все в один отдельный каталог) и актуализируй... Хотя, это жестоко...

Ой, вот это и получился изврат.... Хорошо-хоть убирается с глаз... Ну не художник я иконки рисовать, 16х16 - это жесть... 32х32 - еще ничего, а мелкие - тут надо спецом быть, что б и вид имели и понять можно было - что изображено...

Увы, не могу согласиться Это создает определенные неудобства при написании командных строк, как мы видим на примере "D:\Books_e\LibRusLib\Script\fb2lrf_c.exe -i %F -o %f.lrf -s default_styles.sini" . Неоправданно длинная командная строка и необходимость ее коррекции каждый раз, когда изменяется место, откуда запускается программа. Кроме того, это может создавать проблемы при поиске DLLs. Альтернативой могло бы быть введение нового параметра, дающего полный стартовый путь - "... -s %pdefault_styles.ini", но стандартным в Windows является указание "Start In" директории. Нетривиальная пакетная программа предполагает свою иерархию директорий для правильной работы.

Да, я про это. Дело в том, что в LibRusLib уже имеется диалог, показывающий прогресс пакетной обработки. Выпрыгивающее окно закрывает его, а прочесть в консоли все равно ничего нельзя успеть. Если я обрабатываю 50 книг - мой экран мигает 50 раз. Выглядит это весьма и весьма странно. Я не знаю, о каких программах вызывающих консоль идет речь, но ни одно IDE (включаая и Delphi) не мигает консолью во время билда например. Интересной альтернативой было бы создание и запуск командного файла содержащего обработку всех книг - тогда окно было бы одно, я правда не уверен, что это имеет смысл.

Я бы вообще не использовал ShellExecute - не понятно зачем нужна функциональность интеграции с Windows Explorer, которая все равно не используется. Вместо этого я бы выдал CreateProcess (не помню есть ли в Delphi или надо звать Windows API) - а там установка своих handles для stdout и stderr - стандартная функциональность, как и проверка кода возврата.

Вот где то так...

Единственная проблема, которая была замечена - 4 нод, почему-то блокирует автозапуск апдейта, но в файлах вируса не находит. Скорее, даже не блокирует, а слишком долго проверяет и программа по таймауту отваливается. Так что, скорее всего, проблема у тебя.

Если будут возникать подобные проблемы - проще стянуть новую версию в архиве без инсталлятора и перезаписать имеющиеся файлы.