View Issue Details

IDProjectCategoryView StatusLast Update
0001722Far ManagerPlugins API.Dialogpublic2014-04-30 16:13
ReportershmuelAssigned Tovskirdin 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Platformx86OSWindowsOS VersionXP SP3
Product Version3.0 
Target VersionFixed in Version3.0 
Summary0001722: DN_EDITCHANGE приходит лишний раз и с ложной информацией
Description[ Far 2.0.1807, Far 3.0.1897 ]
Допустим диалог состоит из единственного элемента DI_EDIT, больше элементов нет. При появлении диалога сразу нажмём на клавишу, допустим, W. Приходят два события DN_EDITCHANGE вместо одного, причём в первом из них PtrData указывает на пустую строку.

Последующие нажатия на клавиши, вызывающие изменения текста, отрабатываются правильно, лишние ложные события не приходят.
TagsNo tags attached.
Build3855

Activities

vskirdin

2012-04-26 12:00

administrator   bugnote:0009060

Анализ:
Это EditControl посылает первый раз пустышку посредством калбэка (DlgEdit::DoEditChange()).
Второй, правильный DN_EDITCHANGE приходит от SendDlgMessage.

vskirdin

2014-03-25 13:27

administrator   bugnote:0012028

Для справки:
zg 25.12.2008 04:19:29 +0200 - build 689
1. теперь DN_EDITCHANGE приходит при любых изменениях в строке редактирования
   за исключеним изменений, производимых в обработчике DN_INITDIALOG.

vskirdin

2014-04-03 17:12

administrator   bugnote:0012093

Ещё подробности.

Первый (нулевой) приходит из edit.cpp#711:
   LeftPos=0;
>> SetString(L"");
   Show();


Т.е. при старте у "этой" строки редактирования выставлен флаг FEDITLINE_CLEARFLAG (серые буковки)...
> При появлении диалога сразу нажмём на клавишу, допустим, W.
...в этот момент идет сброс флага FEDITLINE_CLEARFLAG и очистка содержимого строки. Диалоговая процедура видит это как "PtrData указывает на пустую строку".
Следом приходит второй DN_EDITCHANGE с теми данными, которые ты ввел.

Я так полагаю, что это не Инц, а вполне штатная ситуация, но описать это поведение надо в Энц.
Закрываем?

shmuel

2014-04-03 17:42

developer   bugnote:0012094

Рассматривать этот тикет надо с точки зрения плагинописателя и не иначе.

Плагинописатель желает получать DN_EDITCHANGE только при изменениях, инициированных извне (пользователем или макросом), но никак не при внутренних, промежуточных изменениях, инициированных изнутри (самим Фаром).

Штатной эту ситуацию признать никак не могу. В своё время я попытался сам это исправить - увидел, что сделано это в Фаре через ж., понял что много времени на это уйдёт и забил. Кстати, помимо ситуации, описанной в тикете, обнаружил тогда и другие схожие (если не изменяет память - связанные с вставкой).

vskirdin

2014-04-03 19:47

administrator   bugnote:0012095

Тогда предлагай варианты.

shmuel

2014-04-03 20:28

developer   bugnote:0012096

Вариант здесь может быть (IMHO) только один - сделать, чтобы было логически правильно, т.е. как описано в моём посте выше. Если имеются внутренние завязки в Фаре, делающие точечное исправление невозможным (а они, насколько мне помнится, имеются), значит нужен рефакторинг более широкой области кода. Это может быть кусок работы, да ещё и с риском поломать что-нибудь.

А альтернатива - не трогать, оставить как есть. Но тикет закрывать не следует.

vskirdin

2014-04-03 22:04

administrator   bugnote:0012098

Уфф.. тут можно сделать следующее - для unchanged не посылать в диалог инфу. Вообще не посылать...
Или добавить новую нотофикацию аля DN_EDITUNCHANGE, для случая, озвученного выше.
?

shmuel

2014-04-04 13:12

developer   bugnote:0012110

Давай пока отложим это немного, совсем времени нет.

vskirdin

2014-04-08 09:12

administrator  

m0001722.diff.7z (341 bytes)

vskirdin

2014-04-08 09:14

administrator   bugnote:0012150

Заметки.
1. при вставке_символа/clipboard past/CtrlY/Bs/CtrlBs/CtrlShiftBs/ShiftEnter сначала идет вставка пустой строки (и нотификация DN_EDITCHANGE), потом всё остальное (вторая нотификация DN_EDITCHANGE).
2. unchanged _технически_ похож на селектед с той разницей, что информация для селектеда об удаленном блоке не поступает в диалоговую процедуру (нотификация DN_EDITCHANGE не приходит).

Если первая нотификация от unchanged не нужна, то применим патч m0001722.diff.
Решено?

shmuel

2014-04-08 18:07

developer   bugnote:0012172

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

vskirdin

2014-04-08 18:11

administrator   bugnote:0012173

Просто ответь - нужна или нет нотификация об изменении unchaned?

shmuel

2014-04-08 19:06

developer   bugnote:0012174

> Просто ответь - нужна или нет нотификация об изменении unchaned?

Мне кажется, не нужна. Что плагин должен предпринимать в ответ на эту нотификацию? Изменение текста - другое дело.

vskirdin

2014-04-09 09:32

administrator   bugnote:0012176

build 3855

Issue History

Date Modified Username Field Change
2011-03-01 15:11 shmuel New Issue
2012-04-26 12:00 vskirdin Note Added: 0009060
2014-03-25 13:27 vskirdin Note Added: 0012028
2014-04-03 17:12 vskirdin Note Added: 0012093
2014-04-03 17:42 shmuel Note Added: 0012094
2014-04-03 19:47 vskirdin Note Added: 0012095
2014-04-03 20:28 shmuel Note Added: 0012096
2014-04-03 22:04 vskirdin Note Added: 0012098
2014-04-04 13:12 shmuel Note Added: 0012110
2014-04-08 09:12 vskirdin File Added: m0001722.diff.7z
2014-04-08 09:14 vskirdin Note Added: 0012150
2014-04-08 18:07 shmuel Note Added: 0012172
2014-04-08 18:11 vskirdin Note Added: 0012173
2014-04-08 19:06 shmuel Note Added: 0012174
2014-04-09 09:32 vskirdin Note Added: 0012176
2014-04-09 09:32 vskirdin Assigned To => vskirdin
2014-04-09 09:32 vskirdin Status new => feedback
2014-04-30 16:13 shmuel Build => 3855
2014-04-30 16:13 shmuel Status feedback => closed
2014-04-30 16:13 shmuel Resolution open => fixed
2014-04-30 16:13 shmuel Fixed in Version => 3.0