다중 모니터와 메시지 박스

얼마 전까지 엄청난 스트레스를 받는 프로젝트를 진행했습니다. 빨리 끝나기만을 손꼽아 기다렸던 그런 프로젝트였습니다. 하지만 아무리 스트레스를 받고 짜증나더라도 개발에 관련된 일이건 인간관계에 관련된 일이건 배울 것은 있다는 것을 다시 한번 깨닫게 된 그런 프로젝트였습니다.

그래서 배운 것이 무엇이냐? 바로 다중 모니터를 사용하는 환경을 제어는 방법과 이때 발생되는 문제가 있다는 것입니다.

다중 모니터(Multi Monitor) 제어

일반적인 응용프로그램을 개발할 때, 다중 모니터까지 고려할 일은 거의 없습니다. 다중 모니터라 하여 특별한 처리를 할 필요도 없을뿐더러 운영체제가 다 알아서 해주기 때문입니다. 하지만 개발할 응용프로그램이 두 개 이상의 폼(Form)으로 구성되고 상호작용을 한다면 얘기가 달라집니다. 두 개의 폼이 동시에 실행되고 첫 번째 모니터에 첫 번째 폼이 두 번째 모니터에 두 번째폼이 나타나야 한다면 어떻게 처리해야 할까요? 문득 드는 생각은 주 모니터(Primary Monitor)는 특별한 처리를 할 필요가 없을 것이고, 부 모니터(Secondary Monitor)에 폼을 출력할 경우만 고려하면 될 것입니다.

이는 그리 복잡하지 않은 로직으로 해결할 수 있습니다. 두 번째 폼이 부 모니터에 출력되어야 할 경우 두 번째 폼의 Location을 지정해 주면 됩니다. 부 모니터의 왼쪽 상단 좌표는 주 모니터의 넓이(width)와 0입니다. 즉, SecondForm.Location = new Point(주 모니터의 width, 0)과 같이 설정하면 됩니다. 하지만 닷넷은 이를 좀더 쉽고 편리하게 처리하기 위해 시스템상의모니터(들)을 관리하는 Screen이라는 클래스를 제공합니다.

Screen 클래스는 시스템상의 모든 모니터를 알아내는 AllScreens라는 속성을 제공합니다. 이 속성을 사용하면 현재 멀티 모니터를 사용하고 있는지를 알아낼 수 있으며 특정 모니터에 폼을 출력시킬 수도 있습니다.

_secondForm = new SecondForm();

Screen[] screens = Screen.AllScreens;

           

if (screens.Length > 1)

{

    _secondForm.Show();

    if (screens[1].Primary == false)

    {

// 위치 및 넓이를 설정 

        _secondForm.Bounds = screens[1].Bounds;

        // 위치만 설정

        //secondForm.Location = screens[1].Bounds.Location;

    }

}

 

AllScreens 속성을 통해 모든 스크린을 알아낸 다음, 스크린의 개수가 1개 이상이면 멀티 모니터를 사용하고 있다고 가정할 수있습니다. 0번째 스크린이 주 모니터이며 1번째 스크린이 부 모니터일 것입니다. 좀 더 확실하게 하기 위해 Screen의 Primary속성을 사용하여 주 모니터인지 부 모니터인지를 확인할 수도 있습니다.  이렇게 부 모니터가 있다면 Form의 Bounds 속성에 Screen의 Bounds 속성을 할당합니다. Bounds속성은 비 클라이언트 영역(스크롤 바, 제목 표시줄 등)을 포함한 위치 및 넓을값을 포함하고 있으며 두 번째 폼에 두 번째 스크린의 Bounds를 할당하게 되면 두 번째 모니터에 꽉 차는 폼이 출력됩니다. 만약 위치만 두 번째 모니터에 지정하고 싶을 경우에는 Location 속성을 사용하면 됩니다.

이렇게 Screen 클래스를 사용하여 다중 모니터를 쉽게 제어했습니다. 하지만 이때 새로운 문제가 발생할 수 있습니다.

멋대로 표시되는 메시지 박스

첫 번째 폼과 두 번째 폼에서 각각 메시지 박스를 띄워보면 둘 다 아무 이상이 없을 것입니다. 각 폼을 주 모니터와 부 모니터로 이동하면서 메시지 박스를 띄워 보아도 아무 문제 없을 것입니다. 그렇다면 첫 번째 폼에서 두 번째 폼의 메서드를 호출하여 메시지 박스를 출력해 보도면 어떻게 될까요? 우선 두 번째 폼에 ShowMessage라는 메서드를 만들고 이 메서드를 첫 번째 폼에서 호출하는 코드를 만듭니다.

//FirstForm.cs

private void btnSendMessage_Click(object sender, EventArgs e)

{

    if (_secondForm != null)

    {

        _secondForm.ShowMessage(txtMessage.Text);

    }

}

 

//SecondForm.cs

public partial class SecondForm : Form

{

    public void ShowMessage(string message)

    {

        //소유자를 설정하지 않으면 메시지 박스는 주(primary) 모니터에 표시된다.

        MessageBox.Show(message);

}

}

 

첫 번째 폼의 btnSendMessage 버튼을 클릭하면 두 번째 폼의 ShowMessage 메서드가 호출되며 이 때 어떤 일이 발생하는지 보도록 하겠습니다. 메시지 박스는 주 모니터에 출력될 것입니다. 뭐 그럴 수도 있지 하며 넘어갈 수 있는 문제 같아 보이지만 개발자가 아닌 일반 사용자들은 버튼을 클릭하면 두 번째 폼에 어떤 동작이 수행될 것이라 예상하고 있습니다. 이 때 메시지 박스는 주 모니터에 출력되고 메시지 박스가 모달 다이얼로그(ModalDailog)이다 보니 두 번째 폼은 비활성화 되어 아무런 동작도 수행되지 않게 됩니다. 사용자는 메시지 박스를 보지 못하고 응용프로그램이 죽었다 또는 얼었다고 말할 것입니다. 개발자 입장에서 해결은 해야 하지만 사용자로부터 전달받은 오류의 내용은 그냥 죽었다 또는 얼었다라는 말뿐입니다. 당연히 오류를 재현하기도 힘들어 문제의 원인을 찾기 어려울 것입니다.

이 부분은 전적으로 개발자의 잘못이며 개발자가 해결해야 할 부분입니다. 이 글의 목적이 바로 이 문제를 해결하는 것입니다.

왜 메시지 박스가 주 모니터에 뜨는 것일 까요?

MessageBox 클래스는 수 많은 오버로드(overload)를 제공하고 있습니다. 하지만 저를 포함한 대부분의 개발자들은 메시지 매개변수 하나만을 받는 오버로드를 사용하는 경우가 많습니다. 이것이 바로 문제의 원인입니다. MessageBox는 첫 번째 매개변수로 소유자(Owner)를 지정할 수 있습니다. 소유자는 MessageBox를 소유하게 되는 개체로 보통 메시지 박스를 띄우는 폼이 소유자가 됩니다. MessageBox는 소유자를 지정하지 않을 경우 자동으로 소유자를 지정하게 됩니다. 자동으로 소유자를 지정하는데 왜 문제가 될까요? 리플렉터(.NET Reflector)를 통해 MessageBox의 내부를 보면 소유자를 지정하는 다음과 같은 코드를 볼 수 있습니다.

else if (owner == IntPtr.Zero)
    owner = UnsafeNativeMethods.GetActiveWindow();

 

소유자가 IntPtr.Zero, 즉, 소유자가 지정되지 않으면 UnsafeNativeMethods.GetActiveWindow()를 통해 현재 활성화된 윈도우를 소유자로 지정하게 됩니다. 드디어 문제가 해결되었습니다.

소유자를 지정하지 않은 상태에서 첫 번째 폼의 버튼을 클릭하면 활성화된 윈도우는 첫 번째 폼이 됩니다. 이때 두 번째 폼에서 메시지 박스를 띄울 것이며 이 메시지 박스의 소유자는 활성화된 윈도우 즉, 첫 번째 폼이 되는 것입니다. 

문제점이 명확해 졌으니 해결해 보도록 할까요? 네 그렇습니다. 소유자를 지정하기만 하면 됩니다.

public void ShowMessage(string message)

{

    //메시지 박스의 소유자를 설정하지 않으면 메시지 박스는 주(primary) 모니터에 표시된다.

    //MessageBox.Show(message);

    //이 문제를 해결하기 위해서는 소유자를 반드시 설정해야 한다.

    MessageBox.Show(this, message);

}

MessageBox의 첫 번째 매개변수로 소유자를 반드시 지정하는 습관을 기르는 것이 아주 중요합니다. 이런 습관이 없었기에 이런 아티클을 쓰고 있지만 어쨌든 좋은 것 하나 알았으니 만족하며 저를 포함한 모든 개발자 분들이 소유자를 지정하는 습관을 길렀으면 합니다.

출처 : http://kyeongkyun.tistory.com/87