Total Commander

ask-rus
Пожалуйста

Но скажу так: чтобы убился неправильный ТС, придётся запустить два и более 64-битных ТС, расположенных на разных логических дисках, притом по одинаковому пути! Реально ли это?...
Хотя действительно не важно реально или нет, жду помощи.

Забыл одно исправление указать. См. выше.

ApceH писал(а):жду помощи.

Чем ждать, лучше обратиться в места специализированные.
http://www.delphimaster.ru/cgi-bin/forum.pl?n=10

ask-rus
Я ведь так и программировать на винапи научусь! Спасибо!

Версия 0.3.0.81. SHA1: dad293eb8978d7a0e6b63d3245efe7e10d7eba36
^ Секции [pe(t,q,r): корректная реализация сверки пути 64-битного процесса.
+ 5.2.1.1
+ 5.2.2.1

Прямая ссылка.

Чуть обновил спецификацию.

Один раз вышло это:

---------------------------
Total Commander 8.0Я6
---------------------------
Invalid pointer operation.
Invalid pointer operation
Windows 7 SP1 6.1 (Build 7601)

Please report this error to the Author, with a description
of what you were doing when this error occurred!

Stack trace (x64):40B13D
40BDCA 8907FB 89BE90 7BEDFE 7BF40A 7D85EB 7B9D5D 7B9D47
7B9D47 7BC738 7CE25E 43405E 434554 698294 440462 431944

Press Ctrl+C to copy this report!
Continue execution?
---------------------------
Да Нет
---------------------------

Больше не возникало.

Добавлено спустя 13 минут:

Я думаю, это проблема беты 8-ки.

Добавлено спустя 39 минут:

Надолго (5-8 сек.) задумывается, после запускает новый экземпляр. Напрашивается очередная коррекция.

ask-rus
С 7.56а такое бывало хоть раз? У меня нет.
Какое действие совершается? Я предполагаю [per или [peq.

На завершение процесса влияют следующие параметры:
1.1.1.13) CloseProcessWait

При выполнении команды [p?q|...] ожидать завершения процесса. Время указывается в миллисекундах. Особые значения: 0 — не ждать, –1 — ждать бесконечно. Реальное время ожидания может быть большим, так как это же значение применяется в SendMessageTimeout при попытке закрыть очередное окно процесса. Никакого принудительного закрытия окон не осуществляется, но по окончании перебора окон процесса снова осуществляется ожидание в течение CloseProcessWait посредством WaitForSingleObject.

1.1.1.14) TerminateAfterWait

По завершении ожидания завершения процесса в рамках команды [p?q|...], если процесс так и не завершился самостоятельно, завершить его принудительно вызовом TerminateProcess.

Кроме того, нужно учитывать, что для корректного закрытия процесса сообщение WM_CLOSE шлётся каждому окну процесса. Окна перечисляются примерно так: EnumWindows(@EnumWindowsProc, PID). Если бы я слал только главному окну, то это было бы гораздо менее надёжно. Простейший пример: открытый диалог копирования молчаливо воспрепятствует закрытию. Возможно Г. не правильно реализовал wndproc в 8-ке, внёс какие-то зависимости... "Invalid pointer operation" вообще как-то неприятно звучит... Надо внимательно тестировать.

В самом kIT UP корректное закрытие процесса всё же, признаю, не так корректно, как должно быть. Например, если в блокноте изменить документ, то kIT UP всё равно её закроет без запроса на сохранение. В то время как диспетчер задач сделает более правильно. Уже запряг соавтора доработать.

ApceH писал(а):С 7.56а такое бывало хоть раз?

Не проверял.

ApceH писал(а):Какое действие совершается? Я предполагаю [per или [peq.

Код: Выделить всё

[PostActions]
per|TOTALCMD64.EXE

Добавлено спустя 5 минут:

ApceH писал(а):В самом kIT UP корректное закрытие процесса всё же, признаю, не так корректно, как должно быть.

>>>

ask-rus писал(а):Надолго (5-8 сек.) задумывается, после запускает новый экземпляр.

Т. е. не работает, а значит совсем не корректное.

Добавлено спустя 9 минут:

Как и предполагал, перезагрузка системы проблему устранила, не поленился на 20 per-ов. Вопрос, надолго ли, и не появится ли вновь.

ask-rus
Всегда можно запустить tskill (taskkill) из пресета, если не устраивает [per(q). Уж не говоря о спец.средствах вроде TWinCmd.exe.
Но реализовывать именно per(q) как-то по-другому будет неправильно (соавтор практически убедил меня в этом сегодня), ведь нам именно это и нужно от пресета — выполнять действия в автоматическом (пакетном) режиме. А значит мой пример с блокнотом является надуманным.

Ошибка повторилась:

---------------------------
Total Commander 8.0Я6
---------------------------
Invalid pointer operation.
Invalid pointer operation
Windows 7 SP1 6.1 (Build 7601)

Please report this error to the Author, with a description
of what you were doing when this error occurred!

Stack trace (x64):40B13D
40BDCA 8907FB 89BE90 7BEDFE 7BF40A 7D85EB 7B9D5D 7B9D47
7B9D47 7BC738 7CE25E 43405E 434554 698294 440462 431944

Press Ctrl+C to copy this report!
Continue execution?
---------------------------
Да Нет
---------------------------

Это повод для репорта.

Добавлено спустя 6 минут:

Однако, действительно ли это ошибка беты.

ask-rus
Ну лично я (и остальные пользователи kIT PPP) много раз использовали [per|totalcmd.exe] с версией 7.56а. И такого не было действительно ни разу.
Кстати, почему не 8b8? И это 64-битная, да? Может в этом дело?
Попробуй ещё закрывать через диспетчер задач (через вкладку Приложения, а не Процессы), там примерно такое же действие происходит.
Репорт в любом случае нужен. Даже если kIT UP неправильно поступает, что шлёт всем окнам верхнего уровня WM_CLOSE, всё равно нормальная программа не должна от этого рушиться...

ApceH писал(а):Кстати, почему не 8b8?

Перейду на нее сегодня.

ApceH писал(а):И это 64-битная, да?

Да.

ApceH писал(а):Может в этом дело?

Тебе следовало бы и на ней тестировать свою утилиту.

Добавлено спустя 9 минут:

ApceH писал(а):Репорт в любом случае нужен.

Он здесь.

ask-rus
Не надо было палить утилу перед самим Гислером!

Ну версия 0.3 же всего лишь! Кинь в ту тему вот этот мой код. Я там не зарегистрирован.

Код: Выделить всё

procedure CloseProcessByPID(PID: Integer);
  function EnumWindowsProc(hwnd: HWND; lParam: LPARAM): Boolean; stdcall;
  var
    PID: Cardinal;
    Res: Cardinal;
  begin
    GetWindowThreadProcessId(hwnd, @PID);
    if PID = Cardinal(lParam) then
    begin
      SendMessageTimeout(hwnd, 16, 0, 0, SMTO_NORMAL, MainInfo.Configuration.CloseProcessWait, Res);
    end;
    Result := True;
  end;
begin
  EnumWindows(@EnumWindowsProc, PID);
end;

Я не могу и не собираюсь подстраивать функционал и реализацию под конкретные проги, пусти и такие важные. Я должен делать правильно лишь с точки зрения архитектуры Windows, в соответствие с рекомендациями и информацией из MSDN. Хотя, конечно, руководствуюсь здравым смыслом. Секции [I... тому пример.
Ну это в целом. А на практике, конечно, тестирую теперь и на x64. Хотя нигде ещё официально не упоминалась поддержка kITUP-ом x64

Кажется, действительно, косяк висит на 6-й бете (на 7-й не проверял), на 8-й он отсутствует, но совсем точно я это утверждать не могу, т. к. ошибка возникала раз в сессию Windows (следующая ошибка только после перезагрузки системы), обычно это первый запуск TC. Если же ошибки не было, то её и не будет до перезагрузки Windows (7 sp1 x64).

Не понял совсем, что это могло бы значить, а главное, хорошо это или плохо - то, что он у себя "отловил".

ask-rus
Честно говоря, тоже не понял))) Наверно имеет в виду, что улучшит обработку OnClose...
Значит хорошо)))

ApceH писал(а):Наверно имеет в виду, что улучшит обработку OnClose...

Я на это надеюсь, ведь сейчас у меня вообще не перезапускает - всегда создает новую копию.

Total Commander

kIT Universal Presets