да ничего сложного, дело вкуса, в данном случае мне нравится event. Под RT я предпочитаю очереди.Borjomy_1 писал(а):Ну парсить. Как будто это так сложно! Есть в конце концов, известный класс Taskings2.Если брать одну очередь, то придётся парсить.
Вы читаете написанное, или просто отвечает по принципу "надо покритиковать"?Моя практика говорит о том, что для серьезных задач так делать категорически нельзя (просто потом все равно придется переделывать). И вот почему: когда вы в событии должны выполнять работу со внешним устройством, вы должны быть готовы, что этот обмен выполняется неопределенное время.События можно обрабатывать каждое в своём кейсе, при этом все кейсы собраны в одну структуру
Где я написал, что всё запихано в один цикл? Повторю свою мысль:
В принципе именно необходимость обрабатывать действия пользователя и привела сначала к использованию event (контролы), а позже к ним добавились события, генерируемые параллельными потоками (те самые потоки взаимодействия с железом).
например, потребность изменить тип передаваемых данных и добавление новых команд. При обработке строк могут проскочить ошибки. Вот чем мне нравится , так это тем, что изменив что-то в контроле, я практически автоматом получаю корректировку всех связанных вещей. А вот изменив отправляемую строку, я могу что-то пропустить. Впрочем, вопрос решается использованием typedef.rbl писал(а):Что плохого в парсере?Artem.spb писал(а): Если брать одну очередь, то придётся парсить.
где именно вы видите усложение? Использование нескольких "почтальонов" для доставки сообщение от разных адресатов одному получателю? Дело вкуса.В чем профит усложнения структуры - я категорически не понимаю.
эта особенность событий и привлекает меня. Отправил одно событие "чуваки, меняем язык", и все открытые окна переименовали контролы. Отправили "суши вёсла", и все завершили работу.Kosist писал(а):По моему, все зависит от того, что нужно делать. Не стоит забывать, что User Event - это Multiply Readers, Multiply Writers; а очередя - это Multiply Writer, Single Reader.Vitekkz88 писал(а):"Что лучше? очереди или User Event" тема древняя, на форуме офицалов разработчики не давали однозначного ответа, что лучше.
А с очередями? ну вот у меня сейчас проект на 20+ одновременно открытых окон (это желание заказчика, я отговаривал). Будете 20 очередей в цикле обрабатывать? Да, можно. И да, дело вкуса.
Впрочем, есть ещё аргумент против очередей с парсером. Есть у меня некое предубеждение против строк, идущее с тех самых пор, как я вычитал механизмы их обработки. Та же справка NI рекомендует по возможности при хитрой работе со строками переводить их в массив U8.
а если вы желаете в этом же цикле обрабатывать часть контролов на экране? если кнопка обрабатывается за миллисекунды (не требует диалога с пользователем), и при этом влияет на SM, то вполне логично её расположить тут же. Мне не нравится схема "UI отловил событие -> поставил в очередь команду -> её отработала SM", это на мой взгляд и есть усложнение кода.Kosist писал(а):А что мешает создать для каждого источника данных свой кейс при использовании очередей? У Вас что так, что так получается дубликация кода. По такой логике, Вы же можете и через один User Events передавать данные + их источник, и делать парсинг. Но так не делаете, т.к. на каждый источник у Вас свой юзер евент. Но ведь то же самое можно сделать с очередью - через одну очередь передавать данные с разных источников на разные страницы кейс-структуры.
Впрочем, тут двояко. Упростив в одном месте, усложняем в другом. Дело баланса и вопрос вкуса.
Вы не смешиваете всё в кучу?Ага.. Только NI не рекомендует использовать несколько Events Structure, запущенных одновременно (это ведь уже проходили - в зависимости от того, какая структура активна, ей и идут возникающие события).По events: с какой целью они были реализованы в DAQmx? А что кто то, где то, как то не смог пробиться к events structure, так это ни как не указывает на ее мифические недостатки, а говорит только об уровне программиста.
NI не то чтобы не рекомендует, а категорически настаивает не располагать несколько event-структур в одном цикле. В вот параллельно работающие структуры в разных циклах никто не запрещал. Если я ошибаюсь, пришлите ссылку, будет полезно освежить теорию.
и что значит "в зависимости от того, какая структура активна"? Структура "активна" всегда, она коллекционирует события, пока её не скажут прекратить делать это (unregister event). Причём не важно, "прошли" мы этот участок кода, или ещё не дошли до него. А вот обработка события зависит именно от активности участка кода. Именно в этом контексте нельзя параллелить event-структуры.
Возможно, это недавнее нововведение. по крайней мере я только недавно наткнулся на эти функции.Я что-то User Events не встречал DAQmx. Он принимает их или выдает?
Есть несколько типов событий, генерирующих оповещение. В частности "данные пришли в буфер". Т.е. не надо подвешивать DAQmx read с таймаутом, можно параллельно другими делами заниматься (обрабатывать другие события), а по приходу оповещения считать готовые данные.
Но на мой взгляд реализация сырая. В частности, зарегистрировать событие можно только для запущенной задачи. Так что реализация схемы с стоп-пуск задачи по команде SM затрудняется. Я нашёл, как это сделать, но вариант мне не сильно нравится, я даже думал не извращаться, но всё же желание опробовать новый механизм одержало победу.