$<цифры-буквы><13>
С баксом проблем нет, грид его пропускает. И все остальное тоже, кроме 13. . |
Цитата:
Цитата:
Пробовал найти такую опцию в классах: Ext.view.AbstractView Ext.view.View Ext.panel.Table Ext.grid.Panel . |
Цитата:
Хм. Если подумать, то задачка-то забавно нетривиальная даже без учёта вопроса с браузерным окном. Отслеживание активного компонента тут слабо поможет, особенно если вашему приложению нужно работать в IE. Я бы пошёл другим путём: можно установить обработчик события keydown на уровне документа со срабатыванием в фазе перехвата, и при опознавании префикса "подставлять" под следующие за ним "нажатия клавиш" некое специальное поле. Примерно так: Ext.define('My.app.Application', {
extend: 'Ext.app.Application',
launch: function() {
this.scannerField = new Ext.form.field.Text({
renderTo: Ext.getBody(),
floating: true,
hidden: true,
focusOnToFront: true,
cls: 'x-hidden-clip',
shadow: false,
listeners: {
specialkey: function(field, e) {
if (e.getKey() === e.ENTER) {
e.preventDefault();
e.stopEvent();
// Это просто чтобы не заморачиваться с разрешением
// scope через references в этом примере
Ext.app.Application.instance.fireEvent('scanner_input', this.getValue());
this.setRawValue('');
this.hide();
}
}
}
});
Ext.getDoc().on('keydown', function(e) {
// 52 это код клавиши для '$'
if (e.getKey() === 52) {
e.preventDefault();
e.stopEvent();
Ext.app.Application.instance.scannerField.show();
return false;
}
}, { capture: true });
}
});
Это решение не на 100% свободно от побочных эффектов, но в вашем случае такого решения скорее всего вообще нет. Для пущего спокойствия душевного, я бы проделал серию бесчеловечных экспериментов над живым сканером; главный вопрос это насколько быстро случается "ввод", т.е. каков разрыв по времени между префиксом и постфиксом. Я очень сильно подозреваю, что разрыв близок к 0 мс, но могут быть варианты. Если разрыв минимален, то вышеописанное решение должно иметь приемлемую надёжность. Я протестировал по-быстрому в Chrome, но по идее в IE тоже должно сработать. Учтите также, что несмотря на кажущуюся простоту кода, механизмы здесь задействуются сложные и колдунство вельми сильное. Если нужно что-нибудь поменять, лучше сперва спросите. Я с удовольствием объясню, что и как, но это может оказаться надолго. :) |
Цитата:
Цитата:
Здесь я ничего не нашел: http://docs.sencha.com/extjs/6.0/6.0...iner-method-on Цитата:
2) И еще вопрос: А зачем после $ надо показывать поле Ext.app.Application.instance.scannerField.show(); а потом после 13 - скрывать? Из-за этой опции focusOnToFront: true? Хитро однако... . |
Цитата:
Цитата:
Цитата:
Цитата:
Поэтому поле сделано невидимым, но фокусируемым, с помощью CSS правила clip: rect(0,0,0,0), которое применяется стилем 'x-hidden-clip'. Остальные хитрости как раз для автомагического управления фокусом: поле у нас "плавающий" компонент с абсолютным позиционированием в теле документа, поэтому в раскладках не участвует и на другие компоненты не влияет. Когда мы это поле показываем через scannerField.show(), глобальный ZIndexManager сортирует свою коллекцию плавучих компонентов и выпихивает наверх наше поле, попутно его фокусируя. Поле, оказываясь наверху стека и получая фокус, запоминает предыдущий сфокусированный элемент и отпуливает фокус обратно, когда мы это поле скрываем. Флаг focusOnToFront должен быть true по умолчанию для всех плавучек, но я просто подстраховался, т.к. некоторые классы его меняют и я не помню точно, какие именно. Примерно так, если без нюансов. :) А ещё если подумать, то надо очистку поля через setRawValue('') передвинуть из обработчика specialkey в глобальный перехватчик. И вопрос о длительности интервала между $ и Enter был вовсе не праздным, промышленную версию этого решения неплохо бы обвешать предохранителями на тему ложных срабатываний. Как говорил незабвенный поручик, случаи разные бывают... |
Цитата:
Это для задач, где пользователь не решает, какой браузер ему использовать. Цитата:
Я попробовал в действии опцию { capture: true }. Для keydown она работает, грид не может перехватить и заблокировать событие, а вот для keypress эта опция не сработала, грид заблокировал событие, почему такая разница??? В итоге, мне в общем-то достаточно опции capture, чтобы решить проблему, разве что событие keypress придется поменять на keydown. Но, единственный недостаток решения это то, что capture это недокументированная опция, надо заметить... . |
Здесь тоже есть опция capture, но недокументированная
http://docs.sencha.com/extjs/6.0/6.0...xt.util.KeyMap http://docs.sencha.com/extjs/6.0/6.0...xt.util.KeyNav плюс еще опция priority тоже есть. |
Цитата:
Цитата:
Цитата:
Цитата:
|
Цитата:
Но ведь опция { capture: true } гарантированно решает эту проблему. Зачем "максимально использовать возможности браузера", если проблема перехвата так легко решается? Хотя бы ценой смены события keypress на keydown. |
Цитата:
А самое главное: для обработки этих событий вам нужно писать код, а код === баги === стоимость поддержки. Единственный способ уменьшить количество багов, это уменьшить количество кода. Но вы не подумайте чего, я не буду вас уговаривать. Ваш проект, ваша головная боль... ;) |
| Часовой пояс GMT +3, время: 18:00. |