Status cells/onClick actions

[mlengle]

Запрос фичи: надо в каком-то виде экранные кнопки бы сделать, пока что вижу максимально приближенное к этому - ячейки полосы статуса, осталось только к ним обработчик нажатий прикрутить. На уровне скрипта вообще всё просто -- событие кидать с номером ячейки, на уровне тинтина надо подумать как (но мне лично хватило бы и скрипта)

[konelav]

Предлагаю рассмотреть такой вариант: 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.

[mlengle]

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

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

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

[mlengle]

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

[konelav]

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

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

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

[mlengle]

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

[mlengle]

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

например, смотрим магазин:

2. Leggings 200 a brass dragonscale leggings
3. Helm 600 a brass dragonscale helm

4. Helm 600 a green dragonscale helm

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

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

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

[mlengle]

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

держу Control нажимаю мышкой

event gui txt LDown -1 9 <--

все еще держу Control отпускаю мышку

event gui txt LUp -1 8 <---

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

[mlengle]

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

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,

[konelav]

@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)

[Lakssoc]

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

[mlengle]

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

[Lakssoc]

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

[konelav]

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

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

[mlengle]

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

[konelav]

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

[mlengle]

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

[konelav]

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