Status cells/onClick actions about jmc HOT 17 OPEN

Предлагаю рассмотреть такой вариант: https://github.com/konelav/jmc/releases/tag/3720
Т.е. можно сделать что-то вроде этого:

#message event on
#act {/^#event gui status LDown 1/} {#showme {Status 1 Left clicked!};#drop}
#act {/^#event gui status RDblClk 1/} {#showme {Status 1 Right doubleclicked!};#drop}
#wout 2 {command1 command2 command3}
#act {/^#event gui txt LDown 2 (\d+) (.+)/} {#showme {Word in window 2 clicked: %1};#drop}
#act {/^#event /} {#drop} 9

Ну или скриптами по событию Incoming.

from jmc.

двойные нажатия на экране никак не показываются, только правая или левая кнопки (средняя тоже не отрабатывает)

на ячейках в статусе двойные нажатия работают, но не средняя кнопка

P.S. а, уже вижу, что это документированное поведение :)

from jmc.

а почему в скриптах на Incoming? отдельный обработчик логичнее

from jmc.

Двойные нажатия в окнах не работают т.к. они "захватывают" (capture) мышь для выделения текста, что меняет поведение (получателя) события даблклика; наверное, тоже можно перехватить, я посмотрю.

Среднюю кнопку, по-моему, доделать будет легко; ещё есть XButton1/XButton2, чтобы это ни значило; мне не на чем потестить, но сами события словить можно.

А вот со скриптами надо подумать. С одной стороны, сделать дополнительный обработчик и логично и не трудно. С другой, пока получается некая "унификация" с (почти) всеми прочими системными сообщениями, которые так же можно отлавливать в скриптах (например, #oob) на общих правах с триггерами; и в то же время сравнительно легко перевести обработку полностью в скрипты, как показано в примере для Python: #92 (comment) . При этом для Telnet-событий отдельный обработчик таки был сделан, хотя тоже можно было сделать через системные сообщения #event telnet ... и Incoming, т.е. тут, по идее, либо и телнет-обработчик убирать, либо и для новых событий обработчик добавлять... как бы его в этом случае назвать, чтобы не создавать неоднозначности с именованием поля для передачи данных во все обработчики jmc.Event?

from jmc.

GuiEvents или просто gui?

from jmc.

кстати, потестил реальные случаи использования обработчика в главном окне, и понял, что одного только слова под мышкой мало, нужен еще один параметр события с полной строкой с экрана.

например, смотрим магазин:
2. Leggings 200 a brass dragonscale leggings
3. Helm 600 a brass dragonscale helm
6. Helm 600 a green dragonscale helm

хотим купить brass helm - нельзя нажать на brass, и нельзя на helm, надо смотреть всю строчку.

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

пример:
набрал b и нажал мышкой на строчку в магазине - купил, набрал s, нажал - продал

from jmc.

кстати, а с чем связано изменение nFlags при нажатии и отпускании книпки?

держу Control нажимаю мышкой
#event gui txt LDown -1 9 <--
все еще держу Control отпускаю мышку
#event gui txt LUp -1 8 <---

можно ссылку на нужное место в msdn?

from jmc.

еще заметил явную багу с порядком аргументов -- для статуса сначала идет номер ячейки, а по документации должна идти сначала кнопка мыши, а вот для текста сначала кнопка мыши, потом окно

#event gui status 1 LDown 1
#event gui status 1 LUp 0
#event gui status 2 LDown 1
#event gui status 2 LUp 0
#event gui txt LUp 0 8 Wednesday,
#event gui txt LUp 0 8 Wednesday,
#event gui txt LUp 0 8 Wednesday,

from jmc.

@mlengle Ок, вот следующий вариант реализации https://github.com/konelav/jmc/releases/tag/3721

jmc.RegisterHandler('GuiAction', 'OnGui');
function OnGui() {
    jmc.ShowMe("Gui action description: " + jmc.Event(0));
};

Вместо слова теперь пишется номер символа, на который кликнули, плюс целая строка. В принципе, при большом желании это можно обработать в TinTin посредством #match, хотя и неудобно, конечно... То же самое с флагами: битовые операции #math не поддерживает, а делать их из арифметических -- можно, но неудобно. Отличие флагов при нажатии-отжатии, скорее всего, означает, что какие-то биты в этих флагах отображают состояние кнопок самой мыши (а не только клавиатуры); надо в MSDN смотреть.

(возможно, требуется перерегистрация ttcoreex.dll)

from jmc.

Простите, что влезаю в чужую беседу.
Однако с нажатиями в главном окне есть еще один нюанс (тестировал на первоначальном варианте реализации): нажимаешь на одну строку, она матчится как заявлено, но когда отпускаешь (при этом экран скроллится входящими из мада строками) то следом матчится и строка ниже.
Так же прошу в послежующей редакции все же оставить первоначальную реализацию, когда по нажатию захватывалось слово.
Пока не понимаю как это использовать, но слово явно полезнее символа.

from jmc.

@konelav да, действительно, убирать параметр-слово не стоило, по крайней мере в тинтин синтаксисе, в скрипте не проблема по позиции вытащить.
В остальном всё хорошо, большое спасибо

from jmc.

Небольшой апдейт. Запустил, проверил.
Строка ниже матчится по правой кнопке мыши (нажимаешь на первую строку, она обрабатывается, появляется #event gui ... и следом матчится строка ниже). По левой нет.

from jmc.

Ну, надо всё-таки как-то определиться с форматами.
Во-первых, обработка tintin'ом всё-таки должна быть какой-то более человечной. Для этого всё-таки в сообщении #event должно быть, на мой взгляд, только нажатое слово, т.к. строку всё равно парсить трудно. Плюс, флаги можно преобразовать тоже в строку (типа ctrl,shift,... или с иным разделителем), тогда написание триггеров существенно упростится; в итоге выходит #event gui status|txt LUp|LDown|... <index> <flags> <word>.
Во-вторых, обработка скриптом может иметь дополнительные данные в других элементах jmc.Event, например полную строку в jmc.Event(1) .
Что-то в этом роде?

@Lakssoc странно, что для разных кнопок по-разному; сейчас нет возможности проверить, но в целом "разные строки" -- это норма при наличии прокрутки, ведь событиями являются сами нажатия-отжатия, в промежутке между ними курсор может как угодно сместиться относительно строк, либо строки -- относительно курсора. На практике ведь, скорее всего, нужно только нажатие, т.е. xDown.

from jmc.

да, видимо тинтину придется обойтись одним словом :) а в скрипт отдавать максимально полную инфу.
показ флагов в виде строк усложнит парсинг в тинтине, ведь придется матчить сочетания из нескольких флагов типа alt+shift, control+shift -- с одной цифрой не проще ли? впрочем, тут я не уверен, надо пробовать.

from jmc.

Ок, вот такой вариант нарисовался: https://github.com/konelav/jmc/releases/tag/3722
В принципе, довольно нейтральный.

from jmc.

а Alt флаг там никак нельзя получить? LMR флаги имхо вообще не имеют смысла, т.к. дублируют то, что есть в предыдущем параметре.
остальное одобряю :)

from jmc.

Вообще можно. Можно даже разделить "левый-правый".
LMR флаги, по идее, должны позволять сделать, например, триггер на "нажатие сразу двумя кнопками".

from jmc.