Всем привет.

У меня есть USB устройство и мне нужно отображать данные от него в окне. Работает, но медленно. 

Тему "отображение данных в окне в реальном времени" http://forum.vingrad.ru/topic-332264.html читал, но ответа не нашел.

У меня есть некое USB устройство, с которым я общаюсь через класс SerialPort. При открытии порту назначается скорость 115200. Мне нужно получать от него данные и отображать их в двух TextBox'ах в реальном времени. Я подписываюсь на событие DataReceived

И прослушиваю устройство

Окно должно отображать данные


Так вот, несмотря на то, что за секунду приходит около 50 паектов данных, отображаются примерно 2-3 (определено на глаз), отображаются несинхронно (сначала меняется значение _xTextBox, потом, через долю секунды _yTextBox), неравномерно (между сменой значений проходят разные интервалы времени: от трети секунды до секунды), входной буфер устройства забивается.

Насколько я понимаю, тормозит вызов Dispatcher.Invoke. Сейчас уже понял, что мне придется делать какое-то сглаживание, даже если удастся добиться, чтобы данные отображались в реальном времени в textBox'ах, но все равно,
подскажите, как лечить.

Это сообщение отредактировал(а) Aldegid - 24.8.2012, 09:04

Просто Dispatcher.Invoke так работает. Вы передаете ему Action, но это не значит что он сразу побежит его выполнять. Он поставит ваш Action в очередь и когда не будет других более приоритетных заданий Action будет выполнен. Попробуйте изменить приоритет вашего Dispatcher.

Попробовал повысить приоритет до максимального. Стало немногим быстрее. Но это меня не устраивает. Как-то это для меня очень странно. У меня есть приложение с UI, но этот UI я обновлять не могу в том темпе, который мне нужен... Хоть переписывай под Windows Forms.

Ну в этом есть определеная логика. Зачем обновлять данные быстрее чем пользователь сможет их прочитать.
На крайний случай вы можете не использовать Dispatcher, а вычислять данные в потоке формы, но скорее всего из-за этих дейсвий интерфейс перестанет реагировать на пользователя.
Еще можно использовать DispatcherTimer, и показывать актуальное значение в момент срабатывания таймера, но в таком случае некоторые значения могут так и не оказаться на форме.

erm0l0v, согласен. Но дело, кажется в другом.

Еще на одном форуме я жаловался, что VS как-то странно работает с этим WPF. Сначала я переименовал созданный control, попробовал написать его идентификатор в тексте - и не IntelliSense, ни компилятор его не нашли. А потом через несколько минут нашли.

Потом я добавил обработчик нажатия кнопки, поставил туда точку останова, запустил, нажал на кнопку - точка останова не сработала.

Насколько я понимаю, в студии с этим WPF намудрен какой-то не для простых смертных механизм синхронизации. И компилятор и IntelliSense узнают об изменениях, внесенных в XAML далеко не сразу  >:(((((((( 

Теперь вот подергал XAML еще немного - TextBox'ы стали обновляться быстро. ###.

Видимо вы используете при разработке на WPF тот же подход, что и при разработке в WF.

В этом случае конечно будут незаметны все прелести WPF и технологии XAML по сравнению с разработкой через события в WF. Я при разработке в WPF использую шаблон MVVM, и в лучших традициях этого шаблона код в .xaml.cs вообще не трогаю.

У меня с IntelliSense все нормально, правда нужно постоянно делать ребилд чтобы студия узнала о новых изменениях, но это нормально.

В вложении кинул свою реализацию задачи с помощью MVVM.

Это сообщение отредактировал(а) erm0l0v - 24.8.2012, 13:16

Присоединённый файл ( Кол-во скачиваний: 4 )
 TestUpdate.rar 65,82 Kb

erm0l0v, наконец-то добрался до Вашего примера. Посмотрел на бегущие счетчики, посмотрел, что совсем нет привычного C# кода, и не понял, как предложенный Вами подход работает, чего он позволяет достичь, и в чем его преимущества.

Поясните или дайте ссылку или запрос для поисковика, пожалуйста.

Даже не знаю не какой хорошей ссылке где это все было просто и понятно написано, хотя статей очень много по теме, ключевые слова WPF Binding MVVM.

В примере я разделил код на представление(MainWindow.xaml) и модель(MainViewModel.cs). 
MainWindow.xaml отвечает только за отображение
в MainViewModel.cs находится вся логика. Традиционно модель наследуется от интерфейса INotifyPropertyChanged, который содержит одно единственно событие, сигнализирующее о изменении свойства модели. У меня модель унаследована от BaseViewModel.cs там реализованы дополнительные синтаксические плюшки, но можно обойтись и без них.

И так в нашей модели есть свойства X Y которые будут отображаться, с вызовом метода OnPropertyChanged в сетере, который в свою очередь вызывает событие интерфейса INotifyPropertyChanged. То есть как только мы меняем например свойство X событие PropertyChanged сигнализируют нашему представлению что нужно перерисовать все элементы в которых задействовано X.

Элементы X Y у меня меняются в потоке thUpdate который запускается при нажатии на кнопку Start.

Далее идем к нашему представлению. Во первых в представлении необходимо указать модель, за это отвечает свойство DataContext. Я унаследовал  BaseViewModel от MarkupExtension который возвращает сам себя, благодаря этому я проициализировал DataContext одной строчкой:

В реальных проектах, конечно присваивать DataContext нужно не напрямую а с использованием некоторой фабрики или механизма внедрения зависимостей.

Можно было и без этого, например создать MainViewModel в ресурсах окна, или в коде в файле MainWindow.xaml.cs, но мне кажется так удобнее.
Далее у нас идет обычная разметка страницы, и там где необходимо мы привязываем свойства нашей модели с помощью Binding. Например код TextBlock который будет отображать значение X выглядит так:

Здесь мы говорим что хотим чтобы в поле Text отображалось значение X, и при этом при изменении значения X Text будет автоматически обновляться.

С кнопкой все аналогично, только мы биндимся на свойство Start типа ICommand.

В принципе все.

По поводу преимуществ, самое главное это то что мы разделяем представление и реализацию, в результате мы можем заменить без проблем и то и другое, использовать UnitTest, да я сам код выглядит чище и понятнее.
Плюс там есть еще очень много плюшек, такие как валидация, DataTemplate и другое, что делает нашу жизнь слаще)))

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

Ну да, в свое время я немножко затронул шаблон MVC. Было в нем что-то. Но как-то пока это для меня грузновато. Ни одного класса из перечисленных не знаю. Наверняка Вы написали этот пример раньше и не для меня одного. Ну или большую часть.

Я думал, какой же компонент выбрать для отображения графика данных, постапающих в реальном времени. Теперь еще нужно думать, как его всунуть в этот шаблон.     

Про графики можно посмотреть здесь.

Если вы в качестве коллекции данных для графика будите использовать ObservableCollection<T>, то график будет обновляться после каждого изменения коллекции.

При всем моем уважении: 17:40