Microsoft MVP성태의 닷넷 이야기
.NET Framework: 149. WPF - UI 업데이트를 바로 반영하고 싶다면? [링크 복사], [링크+제목 복사],
조회: 45333
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 7개 있습니다.)

WPF - UI 업데이트를 바로 반영하고 싶다면?


기존 WinForm과 WPF의 UI 스레드 동작 방식은 다릅니다. WinForm에서는 기존 Win32의 Window Procedure 구조를 단순히 확장한 것이었던 반면, WPF에서는 UI 스레드에 대해 WorkItem 방식으로 큐를 대기시켜서 처리하는 Dispatcher가 착 달라붙었습니다.

아직, WPF의 스레드 방식에 대해서 잘 모르시는 분들은 아래의 글을 참조하십시오.

WPF - Threading Model
; https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/threading-model

이와 같이 큐에 쌓여서 처리되는 WorkItem 방식의 구현으로 바뀌면서 눈에 띄게 차이나는 점이 하나 있습니다. 몸소 체험하기 위해 다음의 코드를 한번 볼까요?

우선, WinForm의 경우

using System;
using System.Windows.Forms;
using System.Threading;

namespace WindowsFormsApplication1
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            this.button1.Enabled = false;

            Thread.Sleep(5000);

            this.button1.Enabled = true;
        }
    }
}

실행시킨 후에, button1을 누르면 응용 프로그램 상의 버튼이 금방 회색빛으로 바뀌면서 비활성 상태로 바뀌고 잠시동안 응용 프로그램은 먹통이 된 후 다시 활성 상태로 바뀌게 됩니다.

하지만, 이와 동일한 작업을 WPF에서 해보면,

private void button1_Click(object sender, RoutedEventArgs e)
{
    this.button1.IsEnabled = false;

    Thread.Sleep(5000);

    this.button1.IsEnabled = true;

} 

이상하게도(?), 버튼은 회색으로 전혀 바뀌지 않고 5초 동안 먹통이 된 다음 아무 일도 없었다는 듯이 다시 사용자 반응이 가능해집니다.

아마도 많은 분들이 이 점에 대해서 의아하셨을 텐데요. 이 궁금증은 "WPF - Threading Model" 글을 읽어보시면 금방 풀리게 됩니다.

이유인 즉, IsEnabled = false로 되었을 때 비활성 상태를 그리는 이벤트가 직접 발생하기보다는 새로 그려야 한다는 repaint 관련 작업이 큐에 쌓이고 현재의 가장 우선시 되는 사용자 코드가 모두 실행된 다음 여유 있는 시간에 Dispatcher의 큐에 쌓여 있는 코드를 처리하기 때문입니다.

즉, 아래와 같은 그림이 되겠지요.

[그림 1: 큐에 쌓인 repaint 작업 항목]
wpf_dispatcher_execution_1.png

자, 그럼 WPF에서도 WinForm과 같이 금방 버튼을 비활성화 상태로 맞추려면 어떻게 해야 할까요?
방법은 간단합니다. Dispatcher 큐에 있는 Repaint 작업 항목을 실행시켜 주면 되는 것입니다. 그러기 위해서 아래와 같은 코드를 중간에 넣어주면 됩니다.

private void button1_Click(object sender, RoutedEventArgs e)
{
    this.button1.IsEnabled = false;

    this.Dispatcher.Invoke(
        (ThreadStart)(() => { }), DispatcherPriority.ApplicationIdle);

    Thread.Sleep(5000);

    this.button1.IsEnabled = true;

} 

Dispatcher.Invoke로 동기화 호출을 했으니 현재 스레드는 람다 메서드 () => {}를 실행하기까지 더 이상 진행을 안하게 됩니다. 그런데, 빈 함수의 우선순위를 ApplicationIdle (우선순위 2)로 낮게 잡았으니 Repaint(Render: 우선순위 7)가 실행이 되는 것을 보장하기 때문에 결국 버튼은 비활성화 상태로 변하게 됩니다.

실험을 위해서, 만약 ApplicationIdle 값을 Render보다 높게 잡으면(예를 들어 Normal - 우선순위 9) Dispatcher.Invoke 시에 기존 큐에 있는 Repaint보다 우선순위가 높으므로 그것을 실행하지 않고 곧바로 반환되어 원하는 효과를 볼 수 없습니다. (재미있는 것은 같은 우선순위인 Render를 주어도 원하는 비활성화 코드가 실행이 안됩니다. 아마도 같은 우선순위인 경우 이전에 쌓인 큐보다 먼저 처리되는 것 같습니다.)

여기서 끝이 아닙니다. 버튼이 비활성화되어 있는 5초 동안 마우스로 버튼 영역을 클릭하게 되면, Thread.Sleep이 끝나고 button1_Click 이벤트 핸들러가 반환되자 마자 Dispatcher에 쌓여 있던 MOUSEDOWN 작업항목이 처리되어 곧바로 비활성화 상태로 빠지게 됩니다. 이것이 문제가 되는 경우가 있을 텐데, 예를 들어 사용자가 극장표 예약을 위해 "예약 확인" 버튼을 한번 누른 상태에서 비활성화 상태로 된 것을 다시 누른 경우 2번 실행될 수 있게 됩니다.

그렇다면, 역시 Dispatcher에 있던 MOUSEDOWN 작업 항목을 비워버리고 나서 버튼을 활성 상태로 만들어야 할 텐데, 이런 경우에도 역시 위의 트릭을 그대로 쓸 수 있습니다.

private void button1_Click(object sender, RoutedEventArgs e)
{
    this.button1.IsEnabled = false;

    this.Dispatcher.Invoke(
        (ThreadStart)(() => { }), DispatcherPriority.ApplicationIdle);

    Thread.Sleep(5000);

    this.Dispatcher.Invoke(
        (ThreadStart)(() => { }), DispatcherPriority.ApplicationIdle);
    this.button1.IsEnabled = true;

} 

위와 같이 한 라인을 더 넣어주면 역시 Thread.Sleep 된 동안 시스템에 의해 전송된 MOUSEDOWN으로 인한 Dispatcher 큐에 쌓인 작업 항목을 비워내고 다음으로 진행하기 때문에 원하는 결과를 얻어낼 수 있습니다.

어떠세요? Dispatcher의 동작방식에 대해서 좀 이해가 되셨나요? ^^

*** 첨부 파일은 WinForm/WPF 폼에서 간단한 예제코드를 추가한 것입니다.



[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 10/5/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2009-07-23 06시37분
kevin25
2012-02-15 04시42분
[시피르] 흐음... 이방법에는 문제가 하나 있는거 같은데요

메인 말고 다른 스레드가 동작중일때는 다른 스레드가 끝날때까지
this.Dispatcher.Invoke(
        (ThreadStart)(() => { }), DispatcherPriority.ApplicationIdle);
이 부분을 벗어나질 못하네요

당연한것이겠지만요.. ㅠ

회색버튼을 5초 보여주는게 처음 목적이었겠지만 다른 스레드가 계속 동작중에 있다면 첫번째 Invoke문에서 멈춰가지고 Repaint는 하는데 정작 Invoke문에서 벗어나질 못해서 회색버튼만 다른 스레드가 종료할때까지 계속 보여주다가 다른 쓰레드가 종료되면 그제서야 Sleep문을 들어가 수행하게 되네요.. 이방법 말고 다른방법은 없을까요?
[guest]
2012-02-15 06시06분
"시피르" 님 혹시 재현되는 간단한 예제를 올려주실 수 있으세요?

제가 다음과 같은 코드로 재현을 해보려고 했으나, 아래의 경우에는 정상적으로 Invoke 호출이 벗어났습니다.

        private void button1_Click(object sender, RoutedEventArgs e)
        {
            this.button1.IsEnabled = false;

            this.Dispatcher.Invoke(
             (ThreadStart)(() => { }), DispatcherPriority.ApplicationIdle);

            Thread.Sleep(5000);

            this.Dispatcher.Invoke(
             (ThreadStart)(() => { }), DispatcherPriority.ApplicationIdle);

            this.button1.IsEnabled = true;
        }

        private void Window_Loaded(object sender, RoutedEventArgs e)
        {
            Thread t1 = new Thread(threadFunc);
            t1.Start();
        }

        void threadFunc()
        {
            while (true)
            {
                Thread.Sleep(1000 * 1000);
            }
        }
정성태

1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13868정성태1/17/20253112Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
13867정성태1/17/20254063오류 유형: 943. Hyper-V에 Windows 11 설치 시 "This PC doesn't currently meet Windows 11 system requirements" 오류
13866정성태1/16/20254265개발 환경 구성: 739. Windows 10부터 바뀐 device driver 서명 방법
13865정성태1/15/20253944오류 유형: 942. C# - .NET Framework 4.5.2 이하의 버전에서 HttpWebRequest로 https 호출 시 "System.Net.WebException" 예외 발생
13864정성태1/15/20253908Linux: 114. eBPF를 위해 필요한 SELinux 보안 정책
13863정성태1/14/20253356Linux: 113. Linux - 프로세스를 위한 전용 SELinux 보안 문맥 지정
13862정성태1/13/20253628Linux: 112. Linux - 데몬을 위한 SELinux 보안 정책 설정
13861정성태1/11/20253907Windows: 276. 명령행에서 원격 서비스를 동기/비동기로 시작/중지
13860정성태1/10/20253614디버깅 기술: 216. WinDbg - 2가지 유형의 식 평가 방법(MASM, C++)
13859정성태1/9/20253971디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
13858정성태1/8/20254100개발 환경 구성: 738. PowerShell - 원격 호출 시 "powershell.exe"가 아닌 "pwsh.exe" 환경으로 명령어를 실행하는 방법
13857정성태1/7/20254148C/C++: 187. Golang - 콘솔 응용 프로그램을 Linux 데몬 서비스를 지원하도록 변경파일 다운로드1
13856정성태1/6/20253727디버깅 기술: 214. Windbg - syscall 단계까지의 Win32 API 호출 (예: Sleep)
13855정성태12/28/20244459오류 유형: 941. Golang - os.StartProcess() 사용 시 오류 정리
13854정성태12/27/20244558C/C++: 186. Golang - 콘솔 응용 프로그램을 NT 서비스를 지원하도록 변경파일 다운로드1
13853정성태12/26/20244023디버깅 기술: 213. Windbg - swapgs 명령어와 (Ring 0 커널 모드의) FS, GS Segment 레지스터
13852정성태12/25/20244486디버깅 기술: 212. Windbg - (Ring 3 사용자 모드의) FS, GS Segment 레지스터파일 다운로드1
13851정성태12/23/20244238디버깅 기술: 211. Windbg - 커널 모드 디버깅 상태에서 사용자 프로그램을 디버깅하는 방법
13850정성태12/23/20244741오류 유형: 940. "Application Information" 서비스를 중지한 경우, "This file does not have an app associated with it for performing this action."
13849정성태12/20/20244884디버깅 기술: 210. Windbg - 논리(가상) 주소를 Segmentation을 거쳐 선형 주소로 변경
13848정성태12/18/20244820디버깅 기술: 209. Windbg로 알아보는 Prototype PTE파일 다운로드2
13847정성태12/18/20244855오류 유형: 939. golang - 빌드 시 "unknown directive: toolchain" 오류 빌드 시 이런 오류가 발생한다면?
13846정성태12/17/20245057디버깅 기술: 208. Windbg로 알아보는 Trans/Soft PTE와 2가지 Page Fault 유형파일 다운로드1
13845정성태12/16/20244526디버깅 기술: 207. Windbg로 알아보는 PTE (_MMPTE)
13844정성태12/14/20245212디버깅 기술: 206. Windbg로 알아보는 PFN (_MMPFN)파일 다운로드1
13843정성태12/13/20244391오류 유형: 938. Docker container 내에서 빌드 시 error MSB3021: Unable to copy file "..." to "...". Access to the path '...' is denied.
1  2  [3]  4  5  6  7  8  9  10  11  12  13  14  15  ...