Comments 20
А InputManager почему не подошел? С ним вроде бы попроще все было
+2
Отбрасывать все эти логи, кроме первого или последнего, мы явно не можем. Если у вас достаточно большое визуальное дерево, то вряд ли вам что-то скажут сообщения о том, что кликнули в Window, или же в TextBox, особенно при отсутствии имен у элементов.
Могут ли контролы содержать пустое имя? (на сколько помню в Delphi нельзя было использовать контролы без имени, или добавить несколько контролов с одинаковым именем в контейнер).
Если в c# так же, то можно отфильтровать все события нажатия и в лог добавить одно, указав источник события и полный путь в приложении.
Итого вместо 3х событий KeyDown источниками которых являются TextBox1, Part_ContentHost, MainWindow получим одно событие, со следующим содержанием
KeyDown «Кнопка» down from TextBox1 (System.Windows.Controls.Textbox) path: MainWindow.Part_ContentHost.TextBox1
Поскольку у нас есть полный путь до контрола, который содержал фокус в момент нажатия кнопок, мы всегда сможем найти виноватого.
Могут ли контролы содержать пустое имя? (на сколько помню в Delphi нельзя было использовать контролы без имени, или добавить несколько контролов с одинаковым именем в контейнер).
Если в c# так же, то можно отфильтровать все события нажатия и в лог добавить одно, указав источник события и полный путь в приложении.
Итого вместо 3х событий KeyDown источниками которых являются TextBox1, Part_ContentHost, MainWindow получим одно событие, со следующим содержанием
KeyDown «Кнопка» down from TextBox1 (System.Windows.Controls.Textbox) path: MainWindow.Part_ContentHost.TextBox1
Поскольку у нас есть полный путь до контрола, который содержал фокус в момент нажатия кнопок, мы всегда сможем найти виноватого.
+2
В .NET имен может не быть. Мало того, в WPF при MVVM их не будет в 99% случаев. Ну и в общем случае вложенность по визуальному дереву может быть огромная, так что path получится на несколько строк. А оно надо?
+1
Ну и в общем случае вложенность по визуальному дереву может быть огромная, так что path получится на несколько строк. А оно надо?
В текущем случае вы получите гораздо больше строк лога так что аргумент спорный.
В .NET имен может не быть. Мало того, в WPF при MVVM их не будет в 99% случаев.
Понял, спасибо. Вопрос снимается, как неактуальный.
В текущем случае вы получите гораздо больше строк лога так что аргумент спорный.
В .NET имен может не быть. Мало того, в WPF при MVVM их не будет в 99% случаев.
Понял, спасибо. Вопрос снимается, как неактуальный.
+1
В текущем случае вы получите гораздо больше строк лога так что аргумент спорный.
Идея в том, что на клиентах мы максимально просто собираем сырые данные с разных платформ (Win, Wpf, Aps.net, js), а на сервере обрабатываем.
В итоге в клиентах меньше багов, нет проблем с версионностью алгортимов, не надо централизованно обновлять всех клиентов, вся обработка в одном месте и рядом (на сервере), имеем возможность показывать как сырые данные, так и обработанные.
Про представление эвентов в удобочитаемой форме будет отдельная статья.
0
0
А как же DevExpress MVVM Framework? Да и вагон и маленькая тележка других фреймворколв туда же.
0
А что с ним? Там необязательно, чтобы у контрола было имя.
0
Откройте для себя свойство OriginalSource тогда не придется создавать свои поля. Просто проверяете сравниваете sender и OriginalSource
0
В OriginalSource будут лежать внутренние потроха контрола, которые нам скорее всего ничего не скажут. Для примера, если посмотреть OriginalSource у PreviewMouseDown эвента кнопки, то там будет либо Border, либо TextBlock (в зависимости от того, где клик произойдет). А если еще учесть, что мы подписаны на эвенты у Control, то становится понятно, что в данном случае никогда sender не будет равен OriginalSource, так как Border и TextBlock не являются его наследниками, а значит они нам эвент не пришлют.
+2
Но focused генерируют только focusable элементы. По умолчанию — наследники Control.
0
Да с фокусами на сервере и так нет проблемы с выбором какой показывать, так как клиент уже отбивает все ненужные.
0
Я извиняюсь за, возможно, ответы немного невпопад. Дело в том, что сейчас готовится еще одна статья, где как раз будет решаться задача, для которой мы когда-то думали использовать сравнение OriginalSource и sender, но не подошло, по причинам, которые я описал в первом комментарии. Вот я немного мыслями там :)
Да, в задаче фильтрации эвента фокуса ваш подход выглядит лучше. Просто для статьи мы немного адаптировал наш подход, который сложнее, чем описанный тут, вот и получилось такое решение :)
Да, в задаче фильтрации эвента фокуса ваш подход выглядит лучше. Просто для статьи мы немного адаптировал наш подход, который сложнее, чем описанный тут, вот и получилось такое решение :)
+1
Взять Hash Code от OriginalSource, быть может?
0
Со стороны кажется что WPF уже давно умер. Если бы ТС пошарил бы собранную в DevExpress статистику покупок(живых кастомеров, обращений в сапорт и тд) WPF-решений по сравнению с остальными, было бы очень интересно и познавательно.
Заранее спасибо.
Заранее спасибо.
0
Ну не WinForms, конечно, но платформа очень даже живая, активности по ней много, так что нечего ее хоронить! Саппорт трафик сравним с WinForms
0
Вы мне напомнили недавний диалог:
— Да .Net никому не нужен, большинство программ написано на Джаве.
— У меня на Джаве только android studio, HTML-приложений и то больше.
— Да быть такого не может, у меня все приложения на Джаве.
Собственно с тех пор у меня приложений на Java стало только меньше.
— Да .Net никому не нужен, большинство программ написано на Джаве.
— У меня на Джаве только android studio, HTML-приложений и то больше.
— Да быть такого не может, у меня все приложения на Джаве.
Собственно с тех пор у меня приложений на Java стало только меньше.
0
Новых больших проектов (которые разрабатываются больше 3-х месяцев) в этом году на WinForms создавалось раза в два больше чем на WPF. Но на WPF тоже создавалось немало. В прошлом году соотношение было примерно такое же, сильного тренда в ту или иную сторону не видно.
+1
Sign up to leave a comment.
Собираем пользовательскую активность в WPF