DN_LISTHOTKEY в меню
- John Doe
- Бюрократ
- Posts: 13867
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
DN_LISTHOTKEY в меню
При нажатии в списке хоткея приходит событие DN_LISTHOTKEY, причём курсор предварительно позиционируется на соответствующий элемент.
Таким образом обработчик получает в Param2 избыточную информацию , и при этом нет возможности выяснить, какой из элементов был текущим в момент нажатия хоткея.
Фар же этой информацией определённо обладает, ведь если обработчик вернёт 1, то курсор возвращается в исходную позицию: (Update: изменено в 4640)
Вопрос: может стоит убрать предварительное позиционирование?
Таким образом обработчик получает в Param2 избыточную информацию , и при этом нет возможности выяснить, какой из элементов был текущим в момент нажатия хоткея.
Фар же этой информацией определённо обладает, ведь если обработчик вернёт 1, то курсор возвращается в исходную позицию: (Update: изменено в 4640)
Вопрос: может стоит убрать предварительное позиционирование?
- John Doe
- Бюрократ
- Posts: 13867
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
Проблема с DN_LISTHOTKEY в ProcessDialogEvent
(Дублирую с багтрекера)
dn_listhotkey wrote: Событие DN_LISTHOTKEY оповещает обработчик о том, что пользователь для смены пункта в списке (DI_COMBOBOX, DI_LISTBOX) воспользовался горячими клавишами.
...
Return
FALSE - разрешить изменение.
TRUE - плагин сам отработал событие.
- Из данного текста складывается впечатление, что обработчик сработает до смены позиции, и вернув TRUE можно избежать позиционирования.
В реальности это не так. То ли поведение стоит уточнить, то ли документацию. - Возможно я неправильно понял, но в следующем примере я не вижу разницы в поведении, возвращая TRUE или FALSE.
В обоих случая поведение получается одинаковым, например в меню плагинов по хоткеям не происходит выполнения пунктов, а только лишь позиционирование.Code: Select all
local F = far.Flags Event { group="DialogEvent"; condition=function(Event,param) return param.Msg==F.DN_LISTHOTKEY and Event==F.DE_DLGPROCINIT end; action=function(Event,param) return 0 --return 1 end; }
- zg
- zero-gravity
- Posts: 6038
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Проблема с DN_LISTHOTKEY в ProcessDialogEvent
а почему бы не проверить на комбобоксах и списках в ДИАЛОГАХ, для которых собственно документация и написана?
- John Doe
- Бюрократ
- Posts: 13867
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
DN_LISTHOTKEY в меню
Действительно, в диалогах порядок.
А поскольку в меню никто ничего не обещал, а значит к документации вопросов нет.
Тему переименовал.
А поскольку в меню никто ничего не обещал, а значит к документации вопросов нет.
Тему переименовал.
- zg
- zero-gravity
- Posts: 6038
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Проблема с DN_LISTHOTKEY в ProcessDialogEvent
если конструктивно. да, формально меню — это диалог с листбоксом. но во-первых у этого диалога есть своя, достаточно богатая на магию, диалоговая процедура. во-вторых — есть как минимум три различия между поведением просто диалога с листбоксом и меню. можно поискать в коде по DMODE_ISMENU.
вот это одно из трёх различий. для меню позиционирование происходит до вызова DN_LISTHOTKEY. вот если тут и ещё в паре мест чуть ниже убратьJohn Doe wrote:Из данного текста складывается впечатление, что обработчик сработает до смены позиции, и вернув TRUE можно избежать позиционирования.
В реальности это не так. То ли поведение стоит уточнить, то ли документацию.
!Parent->CheckDialogMode(DMODE_ISMENU)
, то будет так, как вы хотите. но возможно что-то сломается в фаре. или в плагинах. если же ничего не сломается, то стоит также присмотреться к другим двум местам и выпилить DMODE_ISMENU совсем.
а вот здесь да, неправильно поняли. вешая свой обработчик, вы полностью переопределяете пользовательскую диалоговую процедуру. листбокс не закрывает диалог по хоткею. меню закрывается тут. вы это поведение переопределяете независимо от того, возвращаете 0 или 1.John Doe wrote:Возможно я неправильно понял, но в следующем примере я не вижу разницы в поведении, возвращая TRUE или FALSE.
…
В обоих случая поведение получается одинаковым, например в меню плагинов по хоткеям не происходит выполнения пунктов, а только лишь позиционирование.
- John Doe
- Бюрократ
- Posts: 13867
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
DN_LISTHOTKEY в меню
Спасибо за разъяснение.
А как лучше принудительно отправить произвольное событие в стандартный обработчик?
Можно ли использовать для этого DefDlgProc?
Или только SendDlgMessage? (нежелательно, т.к. хотелось бы избежать нового полного цикла DE_DLGPROCINIT/DE_DEFDLGPROCINIT/DE_DLGPROCEND)
Спрашиваю потому что в коде фара не ориентируюсь, а проверить на практике проблематично, LuaFar сейчас не позволяет.
- John Doe
- Бюрократ
- Posts: 13867
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
DN_LISTHOTKEY в меню
это понятно, но что если я хочу вызвать стандартный обработчик совсем в другой момент. Может даже не в ProcessDialogEvent
- zg
- zero-gravity
- Posts: 6038
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
DN_LISTHOTKEY в меню
DefDlgProc — это заглушка, в которой прописаны стандартные реакции на стандартные события. это и есть стандартный обработчик.
то что вы называете стандартным обработчиком меню — это 9 параметр, передаваемый в far.Dialog.
ps: вы бы задачу описали, может есть другое решение.
то что вы называете стандартным обработчиком меню — это 9 параметр, передаваемый в far.Dialog.
ps: вы бы задачу описали, может есть другое решение.
- John Doe
- Бюрократ
- Posts: 13867
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
DN_LISTHOTKEY в меню
Проясняю для себя неясные моменты. (Когда-то возник вопрос при решении конкретной задачи, но сейчас не вспомню)