Паток UI / тэма перыядычнай апрацоўкі

Чаму гэтая тэма часта заходзіць у тупік

У WPF / WinForms, як толькі асінхронны код, абнаўленні UI і перыядычная апрацоўка змешваюцца, становіцца цяжка зразумець, які код на якім патоку выконваецца. Гэта старонка збірае ў адно цэлае завісанні UI, абнаўленні з іншага патоку і сумненні пры выбары таймера.

• Незразумела, куды вяртаецца выкананне пасля await
• Апрацоўка, якая павінна ісці ў UI, змешваецца з апрацоўкай, якую варта вынесці ў фон
• Адказнасць DispatcherTimer, System.Threading.Timer і PeriodicTimer нечаткая
• Складана разгледзець, якой формы код WinForms / WPF будзе зручным у суправаджэнні

Пытанні, якія часта ўзнікаюць на кансультацыях

• .Result / .Wait() застаюцца ў кодзе, і экран лёгка завісае
• Мяжа паміж Task.Run і абнаўленнем UI нечаткая
• Перыядычны запуск рэалізаваны ў розных месцах, і з’яўляюцца drift і паўторныя запускі
• Хочацца менш залежаць ад патоку UI, не парушыўшы адказнасць экранаў

Рэкамендаваны парадак дзеянняў

У гэтай галіне на практыцы больш карысна не разглядаць асобна толькі async / await або толькі таймеры, а ўпарадкаваць паток UI і перыядычную апрацоўку разам. Калі разгледзець звязаныя артыкулы і старонкі паслуг разам, лягчэй вырашыць, з чаго пачынаць: з праектных рашэнняў ці з выпраўлення рэалізацыі.

Звязаныя артыкулы

Звярніцеся па кансультацыю

Калі ў вас ёсць праблема, блізкая да зместу гэтай старонкі, параіцеся з намі і напішыце, у якім вы цяпер становішчы і якая падтрымка вам патрэбна.