Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

두 개의 윈도우를 각각 실행하는 방법(Windows Forms, WPF)

아래와 같은 질문이 있군요.

WPF에서 로딩중 이미지를 구현
; https://www.sysnet.pe.kr/3/0/5104
; https://www.sysnet.pe.kr/3/0/5107

해당 문제를 간략하게 정리해 보면, 다음과 같이 Main Form에서 스레드가 어떤 작업을 하는 사이,

using System.Windows.Forms;

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

        private void button1_Click(object sender, System.EventArgs e)
        {
            WaitForm waitForm = new WaitForm();
            waitForm.Show();

            // ...[생략: 사용자 작업]...
        }
    }
}

WaitForm에서는 사용자로 하여금 대기하라는 표현을 하고 싶은 것입니다.

using System;
using System.Windows.Forms;

namespace WindowsFormsApp1
{
    public partial class WaitForm : Form
    {
        public WaitForm()
        {
            InitializeComponent();
        }

        Timer _timer;
        int _wait = 10;

        private void WaitForm_Load(object sender, EventArgs e)
        {
            _timer = new Timer();
            _timer.Interval = 1000;
            _timer.Tick += _timer_Tick;
            _timer.Start();
        }

        private void _timer_Tick(object sender, EventArgs e)
        {
            this.Text = _wait.ToString();
            _wait--;
    
            if (_wait < 0)
            {
                _timer.Stop();
                this.Close();
            }
        }
    }
}

기대하기로는, MainForm에서 작업을 하는 사이 별도로 뜬 WaitForm은 10, 9, 8, ...로 화면에 카운팅이 되도록 만들려는 것입니다. 간단한 재현을 위해 MainForm의 버튼 이벤트에 다음과 같이 Thread.Sleep을 추가할 수 있습니다.

private void button1_Click(object sender, System.EventArgs e)
{
    WaitForm waitForm = new WaitForm();
    waitForm.Show();

    Thread.Sleep(1000 * 10);
}

그런데, 실제로 위의 코드를 실행해 보면 MainForm에서 10초 동안 멈춰있는 사이 WaitForm의 동작도 멈추게 됩니다. 왜 그럴까요?




이유는 스레드가 하나이기 때문입니다. WaitForm을 Show한 Thread는 이후 Thread.Sleep의 실행으로 10초 동안 CPU로부터 아무런 자원 할당을 받지 못합니다. (또는, 작업을 한다고 해도 CPU는 그 작업만을 할 뿐입니다.) 이로 인해, WaitForm 내부의 코드는 전혀 실행하지 못하게 되고 자연스럽게 화면은 멈춰버립니다.

이 현상을 해결하려면 WaitForm 윈도우를 별도의 스레드에서 동작시켜야 합니다. 이에 대해서는 전에 다음의 글로 한번 다룬 적이 있습니다.

C# - 작업자 스레드와 UI 스레드
; https://www.sysnet.pe.kr/2/0/11287

따라서 다음과 같이 코드 변경을 할 수 있습니다.

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

    private void button1_Click(object sender, System.EventArgs e)
    {
        Thread waitThread = new Thread(threadFunc);
        waitThread.Start();

        Thread.Sleep(1000 * 10);
    }

    private void threadFunc()
    {
        WaitForm waitForm = new WaitForm();
        Application.Run(waitForm);
    }
}

이제 다시 실행을 하면, MainForm의 경우 Thread.Sleep으로 멈춰 있는 사이 WaitForm은 별도의 스레드를 할당받았기 때문에 정상적으로 카운팅 코드가 실행됩니다.




그런데, 여기서 주의할 점이 있습니다. MainForm과 WaitForm을 생성하는 스레드가 달라졌으므로 서로의 UI 객체를 직접 건드려서는 안 된다는 것인데, 이에 대해서는 예전에도 정리한 적이 있습니다.

UI 요소의 접근은 반드시 그 UI를 만든 스레드에서!
; https://www.sysnet.pe.kr/2/0/11561

따라서 threadFunc에 다음과 같은 식의 코드를 추가하면,

private void threadFunc()
{
    this.Text = "TEST";
    WaitForm waitForm = new WaitForm();
    Application.Run(waitForm);
}

이런 예외가 발생합니다.

System.InvalidOperationException
  HResult=0x80131509
  Message=Cross-thread operation not valid: Control 'Form1' accessed from a thread other than the thread it was created on.
  Source=System.Windows.Forms
  StackTrace:
   at System.Windows.Forms.Control.get_Handle()
   at System.Windows.Forms.Control.set_WindowText(String value)
   at System.Windows.Forms.Form.set_WindowText(String value)
   at System.Windows.Forms.Control.set_Text(String value)
   at System.Windows.Forms.Form.set_Text(String value)
   at WindowsFormsApp1.Form1.threadFunc() in F:\...\WindowsFormsApp1\Form1.cs:line 24
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

해결 방법은 "UI 요소의 접근은 반드시 그 UI를 만든 스레드에서!" 글에서 설명했으니 생략합니다.




그렇다면 동일한 코드를 WPF에서는 어떻게 해야 할까요? 단지 새롭게 도입한 Dispathcher 모델을 사용해야 한다는 정도만 차이가 있습니다.

// MainWindow.xaml.cs

using System.Threading;
using System.Windows;

namespace WpfApp1
{
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            Thread waitThread = new Thread(threadFunc);
            waitThread.SetApartmentState(ApartmentState.STA);
            waitThread.Start();

            Thread.Sleep(1000 * 10);
        }

        private void threadFunc()
        {
            WaitForm waitForm = new WaitForm();
            waitForm.Show();

            System.Windows.Threading.Dispatcher.Run();
        }
    }
}


// WaitForm.xaml.cs

using System;
using System.Windows;

namespace WpfApp1
{
    public partial class WaitForm : Window
    {
        public WaitForm()
        {
            InitializeComponent();
                        
            _timer = new System.Windows.Threading.DispatcherTimer();
            _timer.Tick += _timer_Tick;
            _timer.Interval = new TimeSpan(0, 0, 1);
            _timer.Start();
        }

        private void _timer_Tick(object sender, EventArgs e)
        {
            this.Title = _wait.ToString();
            _wait--;

            if (_wait < 0)
            {
                _timer.Stop();
                this.Close();
            }
        }

        protected override void OnClosed(EventArgs e)
        {
            base.OnClosed(e);

            System.Windows.Threading.Dispatcher.CurrentDispatcher.InvokeShutdown();
        }

        System.Windows.Threading.DispatcherTimer _timer;
        int _wait = 10;
    }
}

(첨부 파일은 이 글의 예제 프로젝트를 포함합니다.)




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 1/7/2019 ]

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

비밀번호

댓글 쓴 사람
 




1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12080정성태12/16/20191203.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/2019948오류 유형: 584. 원격 데스크탑(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/20192184Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [1]
12077정성태12/13/20191076Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/17/20191140디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/18/20191234디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/11/2019822디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/20191499Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/2019592오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/20191005오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/20191851오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/19/20191070디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/20191809디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [2]파일 다운로드2
12067정성태11/27/20191041디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/2019833디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/2019916디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/20191377오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/20191095디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태12/20/2019879디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/20191001Windows: 165. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/21/20191083디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/20191030디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/2019996디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/2019680오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/20191291개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/2019655개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
1  2  3  4  5  6  7  8  9  10  [11]  12  13  14  15  ...