View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001722 | Far Manager | Plugins API.Dialog | public | 2011-03-01 12:10 | 2014-04-30 13:13 |
Reporter | shmuel | Assigned To | vskirdin | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | x86 | OS | Windows | OS Version | XP SP3 |
Product Version | 3.0 | ||||
Fixed in Version | 3.0 | ||||
Summary | 0001722: DN_EDITCHANGE приходит лишний раз и с ложной информацией | ||||
Description | [ Far 2.0.1807, Far 3.0.1897 ] Допустим диалог состоит из единственного элемента DI_EDIT, больше элементов нет. При появлении диалога сразу нажмём на клавишу, допустим, W. Приходят два события DN_EDITCHANGE вместо одного, причём в первом из них PtrData указывает на пустую строку. Последующие нажатия на клавиши, вызывающие изменения текста, отрабатываются правильно, лишние ложные события не приходят. | ||||
Tags | No tags attached. | ||||
Build | 3855 | ||||
|
Анализ: Это EditControl посылает первый раз пустышку посредством калбэка (DlgEdit::DoEditChange()). Второй, правильный DN_EDITCHANGE приходит от SendDlgMessage. |
|
Для справки: zg 25.12.2008 04:19:29 +0200 - build 689 1. теперь DN_EDITCHANGE приходит при любых изменениях в строке редактирования за исключеним изменений, производимых в обработчике DN_INITDIALOG. |
|
Ещё подробности. Первый (нулевой) приходит из edit.cpp#711: LeftPos=0; >> SetString(L""); Show(); Т.е. при старте у "этой" строки редактирования выставлен флаг FEDITLINE_CLEARFLAG (серые буковки)... > При появлении диалога сразу нажмём на клавишу, допустим, W. ...в этот момент идет сброс флага FEDITLINE_CLEARFLAG и очистка содержимого строки. Диалоговая процедура видит это как "PtrData указывает на пустую строку". Следом приходит второй DN_EDITCHANGE с теми данными, которые ты ввел. Я так полагаю, что это не Инц, а вполне штатная ситуация, но описать это поведение надо в Энц. Закрываем? |
|
Рассматривать этот тикет надо с точки зрения плагинописателя и не иначе. Плагинописатель желает получать DN_EDITCHANGE только при изменениях, инициированных извне (пользователем или макросом), но никак не при внутренних, промежуточных изменениях, инициированных изнутри (самим Фаром). Штатной эту ситуацию признать никак не могу. В своё время я попытался сам это исправить - увидел, что сделано это в Фаре через ж., понял что много времени на это уйдёт и забил. Кстати, помимо ситуации, описанной в тикете, обнаружил тогда и другие схожие (если не изменяет память - связанные с вставкой). |
|
Тогда предлагай варианты. |
|
Вариант здесь может быть (IMHO) только один - сделать, чтобы было логически правильно, т.е. как описано в моём посте выше. Если имеются внутренние завязки в Фаре, делающие точечное исправление невозможным (а они, насколько мне помнится, имеются), значит нужен рефакторинг более широкой области кода. Это может быть кусок работы, да ещё и с риском поломать что-нибудь. А альтернатива - не трогать, оставить как есть. Но тикет закрывать не следует. |
|
Уфф.. тут можно сделать следующее - для unchanged не посылать в диалог инфу. Вообще не посылать... Или добавить новую нотофикацию аля DN_EDITUNCHANGE, для случая, озвученного выше. ? |
|
Давай пока отложим это немного, совсем времени нет. |
|
|
|
Заметки. 1. при вставке_символа/clipboard past/CtrlY/Bs/CtrlBs/CtrlShiftBs/ShiftEnter сначала идет вставка пустой строки (и нотификация DN_EDITCHANGE), потом всё остальное (вторая нотификация DN_EDITCHANGE). 2. unchanged _технически_ похож на селектед с той разницей, что информация для селектеда об удаленном блоке не поступает в диалоговую процедуру (нотификация DN_EDITCHANGE не приходит). Если первая нотификация от unchanged не нужна, то применим патч m0001722.diff. Решено? |
|
Валентин, в любом случае мне надо будет разбираться, а времени сейчас нет, т.к. есть ряд вещей начатых, которые надо закончить. Если не хочешь меня ждать, делай коммит, переводи статус на feedback, и оно будет ждать меня в этом статусе всё равно. |
|
Просто ответь - нужна или нет нотификация об изменении unchaned? |
|
> Просто ответь - нужна или нет нотификация об изменении unchaned? Мне кажется, не нужна. Что плагин должен предпринимать в ответ на эту нотификацию? Изменение текста - другое дело. |
|
build 3855 |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-03-01 12:11 | shmuel | New Issue | |
2012-04-26 09:00 | vskirdin | Note Added: 0009060 | |
2014-03-25 09:27 | vskirdin | Note Added: 0012028 | |
2014-04-03 14:12 | vskirdin | Note Added: 0012093 | |
2014-04-03 14:42 | shmuel | Note Added: 0012094 | |
2014-04-03 16:47 | vskirdin | Note Added: 0012095 | |
2014-04-03 17:28 | shmuel | Note Added: 0012096 | |
2014-04-03 19:04 | vskirdin | Note Added: 0012098 | |
2014-04-04 10:12 | shmuel | Note Added: 0012110 | |
2014-04-08 06:12 | vskirdin | File Added: m0001722.diff.7z | |
2014-04-08 06:14 | vskirdin | Note Added: 0012150 | |
2014-04-08 15:07 | shmuel | Note Added: 0012172 | |
2014-04-08 15:11 | vskirdin | Note Added: 0012173 | |
2014-04-08 16:06 | shmuel | Note Added: 0012174 | |
2014-04-09 06:32 | vskirdin | Note Added: 0012176 | |
2014-04-09 06:32 | vskirdin | Assigned To | => vskirdin |
2014-04-09 06:32 | vskirdin | Status | new => feedback |
2014-04-30 13:13 | shmuel | Build | => 3855 |
2014-04-30 13:13 | shmuel | Status | feedback => closed |
2014-04-30 13:13 | shmuel | Resolution | open => fixed |
2014-04-30 13:13 | shmuel | Fixed in Version | => 3.0 |