Latest post of the previous page:
Нет, это я так, теоретически спросил. Я просто думал, что Фар может и так сообщить, что у него показано в панелях (в настоящий момент, а не при последнем выходе).Копирование файла в панель другого Фара
- John Doe
- Бюрократ
- Posts: 13861
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
Re: Копирование файла в панель другого Фара
Самое простое решение взаимодействовать через файл.
Плагин ждёт появления файла, читает из него скрипт, и выполняет его.
Результатом выполнения скрипта может быть другой файл или файлы.
Плагин ждёт появления файла, читает из него скрипт, и выполняет его.
Результатом выполнения скрипта может быть другой файл или файлы.
Re: Копирование файла в панель другого Фара
Допустим, я попробую реализовать такое решение. Но ведь это означает, что этот файл нужно обновлять каждый раз, когда в панели меняется каталог, так? Т.е. надо как-то "приклеиться" (hook) к событию смены каталога. Есть такая возможность?John Doe wrote:Самое простое решение взаимодействовать через файл.
Кроме того, этот файл неплохо бы удалить при выходе из Фара. Есть возможность зарегистрироваться/подписаться на событие "Фар сейчас закончит работу/существование"?
- zg
- zero-gravity
- Posts: 6035
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Re: Копирование файла в панель другого Фара
есть.fml2 wrote:Кроме того, этот файл неплохо бы удалить при выходе из Фара. Есть возможность зарегистрироваться/подписаться на событие "Фар сейчас закончит работу/существование"?
Re: Копирование файла в панель другого Фара
Как я понял из "Справки по системе макросов Far Manager", для подписки на выход из Фара есть event group "ExitFAR". Но вот события, которое посылается при смене каталога, я не нашел (искал на страничке "ProcessPanelEventInfo" в "Encyclopedia for Developers"). Да и вы (zg) отнеслись только к выходу из Фар. Правильно ли я понимаю, что надежной и "официальной" возможности отслеживать смену каталога в панели Фаре пока нет?
- John Doe
- Бюрократ
- Posts: 13861
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
Re: Копирование файла в панель другого Фара
Не так.fml2 wrote:Допустим, я попробую реализовать такое решение. Но ведь это означает, что этот файл нужно обновлять каждый раз, когда в панели меняется каталог, так?John Doe wrote:Самое простое решение взаимодействовать через файл.
Имелось ввиду примерно такая схема:
- выделяем в профиле папку
- плагин с заданной периодичностью мониторит папку на появление файла с именем "task"
- при появлении файла плагин загружает и выполняет его, результат выводит в файл с именем "result.PID", где PID это значение Far.PID
- до тех пор, пока существует файл "result.PID" плагин ничего не делает
В другом фаре, при выборе плагина из меню происходит следующее:
- папка очищается, и в ней создается файл с именем "task", содержащий скрипт (для получения папок с панелей, или что угодно).
- по таймауту файл удаляется, и собирается содержимое файлов "result.PID"
- далее плагин выполняет свою основную функцию (предлагает выбор из папок, или что угодно)
Re: Копирование файла в панель другого Фара
Я понял вашу схему. Ее прелесть в том, что она универсальна, т.е. позволяет реализовать любые операции. И еще большой плюс: ее можно релизовать с нынешним Фаром. Но есть и пара недостатков:
1. Все завязано на время, т.е. о синхронности вряд ли приходится говорить. Из-за этого возможны всякие трудно воспроизводимые косяки.
2. Используется поллинг, что тоже не всегда оптимально
3. Можно исполнять (или "заказывать") только одну операцию в один момент времени
Я, честно говоря, думал использовать файл просто как средство опросить другой экземпляр Фара насчет его панелей. Т.е. этот файл как бы становится внешним интерфейсом Фара, пригодным для использования другими процессами. Но для этого нужно отслеживать смену каталога на панели, а это пока невозможно. И в этом главный недостаток моего подхода.
1. Все завязано на время, т.е. о синхронности вряд ли приходится говорить. Из-за этого возможны всякие трудно воспроизводимые косяки.
2. Используется поллинг, что тоже не всегда оптимально
3. Можно исполнять (или "заказывать") только одну операцию в один момент времени
Я, честно говоря, думал использовать файл просто как средство опросить другой экземпляр Фара насчет его панелей. Т.е. этот файл как бы становится внешним интерфейсом Фара, пригодным для использования другими процессами. Но для этого нужно отслеживать смену каталога на панели, а это пока невозможно. И в этом главный недостаток моего подхода.
- zg
- zero-gravity
- Posts: 6035
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Re: Копирование файла в панель другого Фара
в плагине создаёте тред. тред получает команду, через ACTL_SYNCRO (тут есть проблема с долгими операциями в самом фаре, но можно поставить таймаут) получает текущие панели, отправляет обратно.
в простейшем случае можно общаться через именованные каналы "блаблабла_pid". получить список процессов не должно быть проблемой. в более сложной реализации можно сделать один сервер, в котором все клиенты будут регистрироваться.
в простейшем случае можно общаться через именованные каналы "блаблабла_pid". получить список процессов не должно быть проблемой. в более сложной реализации можно сделать один сервер, в котором все клиенты будут регистрироваться.
Re: Копирование файла в панель другого Фара
Это то же самое, что "named pipe" (http://msdn.microsoft.com/en-us/library/aa365590.aspx)? Вот этого мне и не хватало для полной картины. Мне было непонятно, как синхронно общаться между процессами. Будет время, попробую чего-нибудь сварганить. Можно даже сделать плагин "InterFar" (или CrossFar или XFar)для общения экземпляров Фара между собой, а потом на его основе сделать функцию копирования.zg wrote:в простейшем случае можно общаться через именованные каналы "блаблабла_pid"
Re: Копирование файла в панель другого Фара
Я пока что все еще мысленно играю с этой идеей и обдумываю, как бы сделать все thread safe. Ведь к одному Фару теоретически (на практике этого, скорее всего, не будет) могут прийти одновременно несколько запросов. А канал только один.
Можно было бы это решить так. Каждый Фар, к которому можно обратиться, является как бы сервером и созадет собственный канал со всем известным именем, но однозначным для каждого экземпляра Фара (например, с PID в имени). Если какой-то другой Фар (или вообще процесс) хочет к нему обратиться, то он пишет в этот канал запрос, состоящий из собственного PID и какого-нибудь однозначного числа (например, порядковый номер запроса). "Сервер" читает из канала запрос, создает канал (с уникальным / случайным) для обработки этого запроса, создает тред и пишет в канал обращения ответ / подтверждение, в котором повторяет PID и порядковый номер запрашивающего процесса, а также имя только что созданного канала.
Запрашиватель, после того, как он послал запрос, читает из канала, в который он послал запрос. Если в ответе его номер совпадает, он переключается на уникальный канал (его имя содержится в ответе), и дальше общение процессов идет через него, т.е. через отдельный "частный" канал. Если номер в ответе не совпадает, то все надо начинать с начала. После трех неудачных попыток можно на все махнуть рукой.
Или как решаются задачи такого рода?
Создание канала -- это "дорогая" операция?
Можно было бы это решить так. Каждый Фар, к которому можно обратиться, является как бы сервером и созадет собственный канал со всем известным именем, но однозначным для каждого экземпляра Фара (например, с PID в имени). Если какой-то другой Фар (или вообще процесс) хочет к нему обратиться, то он пишет в этот канал запрос, состоящий из собственного PID и какого-нибудь однозначного числа (например, порядковый номер запроса). "Сервер" читает из канала запрос, создает канал (с уникальным / случайным) для обработки этого запроса, создает тред и пишет в канал обращения ответ / подтверждение, в котором повторяет PID и порядковый номер запрашивающего процесса, а также имя только что созданного канала.
Запрашиватель, после того, как он послал запрос, читает из канала, в который он послал запрос. Если в ответе его номер совпадает, он переключается на уникальный канал (его имя содержится в ответе), и дальше общение процессов идет через него, т.е. через отдельный "частный" канал. Если номер в ответе не совпадает, то все надо начинать с начала. После трех неудачных попыток можно на все махнуть рукой.
Или как решаются задачи такого рода?
Создание канала -- это "дорогая" операция?
- zg
- zero-gravity
- Posts: 6035
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Re: Копирование файла в панель другого Фара
CreateNamedPipe function
Creates an instance of a named pipe and returns a handle for subsequent pipe operations. A named pipe server process uses this function either to create the first instance of a specific named pipe and establish its basic attributes or to create a new instance of an existing named pipe.
Re: Копирование файла в панель другого Фара
Сообщение fml2 » Сб 20 сен, 2014 01:55
... Но вот события, которое посылается при смене каталога, я не нашел ...
А разве нельзя повесить создание информационного файла на FE_REDRAW или FE_KILLFOCUS?
- zg
- zero-gravity
- Posts: 6035
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Re: Копирование файла в панель другого Фара
нельзя.iva wrote:А разве нельзя повесить создание информационного файла на FE_REDRAW или FE_KILLFOCUS?