Page 2 of 5

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 13:34
by Max Rusov

Latest post of the previous page:

Skirda wrote:И, кстати, когда я говорил про Write, имел ввиду WriteConsoleInput
А, я не понял. Тогда ладно, мне все равно. Давайте уже сделаем как-нибудь :)
Skirda wrote:На экран писать негоже
ПисАть на экран - тоже востребованная задача. Screen Gadgets пишет. Я в PanelTabs тоже бы воспользовался - табы тогда моргали бы меньше...

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 13:50
by HaRT
Max Rusov wrote:
Skirda wrote:На экран писать негоже
ПисАть на экран - тоже востребованная задача.
Чтобы сделать это цивилизованно, надо либо в Фаре поддерживать свою оконную систему, либо организовывать „псевдографические слои” и ими управлять. Без чего-то подобного рискуем получить путаницу и неразбериху из-за конфликта плагинов за области окна.

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 13:55
by Max Rusov
Это фантастика (c). По факту, сейчас плагины уже что-то пытаются писать на экран, и ставят для этого хуки. Я предлагаю дать им для этого "цивилизованный" способ, не переделывая весь FAR.

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 14:12
by Skirda
писать в консольный ФАРовский буфер :-)
и, как правильно подметил HaRT, нужен еще слой, который будет отрисовываться последним, т.е. как мне видится - ФАР в буфер вывода кидает в буфер свои творения, потом накладывает плагиновый слой и готовое варево выкатывает на экран.

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 14:23
by Max Rusov
Все бы хорошо, только, боюсь, в этой жизни мы этого не дождемся :(

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 15:27
by HaRT
Skirda wrote:потом накладывает плагиновый слой и готовое варево выкатывает на экран.
Строго говоря, надо хотя бы по одному слою каждому плагину, который попросил. Плюс средство управления порядком наложения слоёв.

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 15:36
by Max Rusov
Я предлагаю рассматривать эти задачи (Input и Output) по отдельности. С Input'ом все более/менее понятно, давайте сделаем? Это более востребованная фича, на мой взгляд.

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 15:38
by Skirda
на мантис про Input

Re: ProcessConsoleInput

Posted: Mon 24 Jan, 2011 15:47
by Max Rusov

Re: ProcessConsoleInput

Posted: Thu 27 Jan, 2011 10:02
by Skirda
Max Rusov wrote: - Откуда вызывается функция(?). Тут я не до конца уверен, но есть проблемка в MacroLib'е, что он не может различить, когда ReadConsoleInput вызывается FAR'ом из основного цикла обработки сообщений(?), либо плагином для обработки прерывания. Может ее удастся разрулить флагами.
Правильно я понимаю, что тебе:
- не важно знать из каких (внутренних) мест Far`а вызывается функция ReadConsoleInput
- важно различать, что это из Far`а или из плагина

В чем профит от этого "тайного" знания?

Re: ProcessConsoleInput

Posted: Thu 27 Jan, 2011 23:06
by Maximus5
Пример.

1. Выполняется длительная операция (сканирование сетевого каталога, копирование файлов, мало ли...) Фар в этот момент в принципе считывает ввод, но обрабатывает только опеределенный набор клавиш (только Esc?). Правильно ли это - другой вопрос (imho неправильно, нельзя, например, ввести текст в ком.строку с опережением), но позволять MacroLib-у менять поведение фара - наверное неправильно. То есть либо нужно все-таки знать из какого места вызван ProcessConsoleInput, либо не вызвать ProcessConsoleInput в спорных случаях. И так фар валится на раз.

2. Запускается PicView. Он зовет ReadConsoleInput. В этот момент перехватывать ввод и выполнять макросы как-то некошерно. Так что, imho, ProcessConsoleInput должен вызываться только тогда, когда ввод считывает сам фар, а плагины - вообще не трогать, пусть живут своей жизнью

Re: ProcessConsoleInput

Posted: Thu 27 Jan, 2011 23:33
by Max Rusov
Второй пример - неудачный. Если плагин вызывает ReadConsoleInput, то это его личное дело. FAR про это ничего не узнает и ProcessConsoleInput вызываться по любому не будет (хуки сейчас тоже не сработают - ведь они устанавливаются только на модуль FAR.exe).

Другое дело: если плагин вызывает AdvControl ACTL_WAITKEY. Вот тут уже вопрос: должен ли вызываться ProcessConsoleInput? Если да - то эту ситуацию хотелось бы уметь отличить по флагу.

ProcessConsoleInputW

Posted: Thu 12 May, 2011 09:47
by Skirda
Как вы заметили в build 2027 появилось зачаточное состояние mantis#1687.
Вкратце "для чего": что бы плагины могли получать необработанные события консоли и не лазили "на задний двор" ФАРа (в таблицы импорта - к чему это может привести - описано на мантисе).

Пол-дела сделано. Вторая итерация (уже не 2027, а чуть дальше :-)) выглядит так:

Code: Select all

typedef unsigned __int64 PROCESSCONSOLEINPUT_FLAGS;
static const PROCESSCONSOLEINPUT_FLAGS
	PCIF_NONE            =0,
	PCIF_FROMMAIN        =0x0000000000000001ULL;
	// PCIF_PEEK
	// PCIF_READ

struct ProcessConsoleInputInfo
{
	size_t StructSize;
	PROCESSCONSOLEINPUT_FLAGS Flags;
	const INPUT_RECORD *Rec;
};

int WINAPI ProcessConsoleInputW(struct ProcessConsoleInputInfo *Info);
ПлагинМанагер будет бегать по всем плагинам, имеющим функцию, и вызывать. Цикл опроса прекращается, если плагин вернул 0 (или 1? или... - нужно уточнять)
В первоначальном варианте планировалось, что плагин сможет "менять" данные (посредством передачи ФАРу RecOut), но пока решили отказаться, по причине непоняток, описанных ниже.
Т.к. "выставлена" INPUT_RECORD, то это подразумевает весь диапазон консольных событий.
Естественно это все еще будет уточняться...

Осталась самая "большучесть":
1. откуда вызывать ProcessConsoleInputW; есть пара идей - либо обернуть вокруг GetInputRecord (здесь тогда не будет peek), либо вогнать в console::PeekInput и console::ReadInput (здесь получается нагрузка)
2. что должна возвращать функция? Достаточно 0 и 1 или нужны какие-то дополнительные указания
3. из-за "непонятки" (1) пока не добавлены PCIF_PEEK и PCIF_READ
4. ...

Надо обсуждать :facepalm:

Re: ProcessConsoleInputW

Posted: Thu 12 May, 2011 10:49
by Yegor
Skirda wrote:Цикл опроса прекращается, если плагин вернул 0 (или 1? или... - нужно уточнять)
Я так понимаю, что если плагин нажатие обработал, то сам Фар ее тоже уже не обрабатывает, так?
Skirda wrote:В первоначальном варианте планировалось, что плагин сможет "менять" данные (посредством передачи ФАРу RecOut), но пока решили отказаться, по причине непоняток, описанных ниже.
Менять структуру приходилось в большинстве случаев, чтобы не дать ее обработать Фару повторно. Хотя такая возможность может и понадобится.
Skirda wrote:1. откуда вызывать ProcessConsoleInputW; есть пара идей - либо обернуть вокруг GetInputRecord (здесь тогда не будет peek), либо вогнать в console::PeekInput и console::ReadInput (здесь получается нагрузка)
Для простоты - обернуть вокруг GetInputRecord. В будущем никто не помешает поменять.
Skirda wrote:2. что должна возвращать функция? Достаточно 0 и 1 или нужны какие-то дополнительные указания
Пусть будет int, для начала 0 и 1, опять же потом посмотрим.

Re: ProcessConsoleInputW

Posted: Thu 12 May, 2011 11:10
by Skirda
Yegor wrote:
Skirda wrote:Цикл опроса прекращается, если плагин вернул 0 (или 1? или... - нужно уточнять)
Я так понимаю, что если плагин нажатие обработал, то сам Фар ее тоже уже не обрабатывает, так?
Как вариант. Кроме того, заканчивается засылка месага плагинам. Обсуждаемо.
Yegor wrote:Для простоты - обернуть вокруг GetInputRecord. В будущем никто не помешает поменять.
Тогда пропадает peek.
Yegor wrote:
Skirda wrote:2. что должна возвращать функция? Достаточно 0 и 1 или нужны какие-то дополнительные указания
Пусть будет int, для начала 0 и 1, опять же потом посмотрим.
Там int и так. Мы тут проектируем кусок АПИ, посему лучше сейчас по максимуму уточнить, иначе потом ждать очередного слома :D

Re: ProcessConsoleInputW

Posted: Thu 12 May, 2011 12:35
by Yegor
Думаю, в такой реализации Peek будет бесполезным, на мой взгляд.

Returns:
0 - продолжаем бегать по плагинам
1 - плагин польностью обработал событие (бегать по плагинам не надо, Фар тоже событие не обрабатывает)

2? - плагин обработал событие, но не хочет его отдавать другим, кроме Фара (Фар обрабатывает событие как обычно).