Jakard's Tistory

WPF로 개발하다 보면 XAML 코드 상에서 바인딩을 많이 사용하게 됩니다. 그러라고 WPF가 나오고 XAML이 나온게 아니겠습니까?
그런데 이런 경우가 자주 발생하죠. Height 값에 바인딩 할 Property가 있는데 난 그 값을 반으로 나눠서 바인딩 하고 싶어.. 라든지 또는 TextBlock에 string 프로퍼티를 넣고 싶지만 일정 stringformat을 적용해서 넣고 싶어.. 같은 말이죠.

이럴 때 쓰는게 Binding.Converter 속성이죠.
Binding 걸린 값을 가공하기 위해 IValueConverter를 구현하는 HalfValueConverter 만들어주고 Binding.Converter에 연결해주면 되겠죠.

하지만 반값만 보여줄 때도 있고, 1/3값만 보여줄 때도 있고, 등등 뭐 이렇다고 하면 매번 Converter를 만들어 줘야 할까요?
그에 대한 Cool한 예제가 있더군요.

Embed code in XAML

핵심은 Dynamic Expression API라는 걸 이용했습니다. Dynamic Expression API는 보통 LINQ를 사용할 때 이렇게 쓰는 것을



이렇게 쓸 수 있게 해주는 녀석이랍니다.



코드는 구쓰리 아저씨 홈페이지에서 퍼와서 VB 코드입니다.
이런 식이라면 말 그래도 동적으로 런타임시에 쿼리구문을 결정해 줄 수 있겠네요.
역시 Cool한 코드는 널리고 널렸습니다.

Visual Studio 2010 and .NET Framework 4 Release Candidate가 MSDN 영어 페이지에 공개되었습니다.

 

The Visual Studio 2010 and .NET Framework 4 Release Candidate (RC) is available to MSDN subscribers on Monday, February 8th, with general availability on February 10th.

 

미국시간으로 2월 8일인 오늘 MSDN 구독자에게만 먼저 공개가 되었네요.
일반 사용자에게는 모레 공개가 되는 모양이군요.

다른 분들의 얘기를 들어보니 Visual Studio 2010 beta2에서 발생했던 가상메모리 문제와 성능관련 문제가 크게 개선되었다고 합니다.
저도 beta2를 간간히 써보니 XAML 디자이너에서 뻗어버리는 경우가 종종 있었는데 말이죠.
4월에 정식 버전이 출시될 예정이라고 하는데 beta2를 밀고 RC를 깔아볼까? 아니면 정식버전을 기다릴까 고민중이네요.... ^^

WPF 바인딩 문법을 깔끔하게 정리한 문서가 있어 소개합니다.

WPF Binding CheatSheet version 1.1

디밥의 블로그 이 분의 블로그를 RSS로 눈팅하고 있다가 보게 되었는데, 문서가 한 눈에 잘 들어오드라고요.
지속적으로 업데이트가 될 예정인가 본데, 정리가 완료되면 좋은 자료가 될 듯 합니다.
SVN 같은 걸로 업데이트 받아볼 수 있게 하면 좋을텐데....

Windows Vista가 나오면서 UI측면에서 많은 변화가 있었습니다.
대화상자의 변화도 그 중에 하나라고 볼 수 있습니다. XP까지의 대화상자는 어떤 작업에 대한 메세지와 실행 여부를 묻는 버튼 정도로 구성되었다면 Vista부터는 위에서 보는 것처럼 다양한 Message를 보여줄 수 있고, UI도 다양하게 꾸밀 수 있고, 상황에 따라 여러가지 Command를 선택할 수 있게 하다거나 ProgressBar 등도 표시되는 것을 볼 수 있습니다.

이는 Windows Vista에 추가된 Task Dialog라는 새로운 대화상자 형태입니다. COMCTL32.Dll v6에 추가된 API입니다.
MFC 10.0에는 TaskDialog API를 Wrapping한 CTaskDialog라는 클래스가 새로 추가된다고 합니다. (MFC 10.0 이면 .NET Framework 4.0과 함께 업데이트 되는 건가요?)

[MFC] 태스크 대화상자(Task Dialog) - (1/3) : 기능 소개

실은 위의 Article을 읽다가 C#에서는 어떻게 사용할 수 있을까 궁금했습니다. C#에서도 사용할 수 있도록 Wrapping 클래스를 만들어 놓으신 분들이 있더군요.

Using Windows Vista's TaskDialog API in managed code (C#)
Vista TaskDialog Wrapper and Emulator

프로그램을 Windows Installe로 설치하는 과정에서 다음과 같은 메세지가 나온다면?
관련 내용을 찾아보니 한글로는 도저히 검색이 되질 않더군요. 대충 영문으로 "Installation User Interface Optiion"으로 검색을 해보니 이런 Q/A는 찾을 수 있었습니다.

http://www.developmentnow.com/g/54_2005_10_0_0_614959/Installation-User-Interface-Option.htm
http://help.wugnet.com/windows/Changing-installation-user-interface-option-ftopict621849.html

아마도 이전에 설치되어 있던 버전에 대한 Installer 정보가 Registry에 남겨져 있는 것 같습니다.
하지만 레지스트리 편집기에서 관련 내용을 찾기도 만만한 일이 아니더군요.

한참을 레지스트리 편집기를 들어가서 프로그램 명으로 검색을 해서 지우고, 예전 버전을 설치했다가 다시 삭제를 해봐도 소용이 없었습니다.
게다가 버전이 여러번 바뀌어서 아주 오래전 설치 프로그램을 찾을 수도 없었구요.

다시 검색을 해보니 이런게 있더군요.

Windows Installer CleanUp 유틸리티 설명

설치를 하고 검색을 해보니 아예 프로그램 명도 안뜨는 프로그램이 하나 Install 되어 있더란 말입니다. 아마 이놈일꺼야 싶어서 과감하게 "Clean" 버튼을 누르고 다시 설치를 해보니 정상적으로 설치가 되더란 말입니다.
음... 역시 Install Shield 같은걸 써야 하는 걸까요?

컬렉션이나 문자열을 반환할 때 보통 생각없이 Null을 리턴하는 경우가 있었는데 Microsoft의 Guideline에는 Mananged Code인 경우에 Null을 리턴하는 경우를 피하라고 하네요.
링크에 걸린 글에서 말하기를

1. Null을 리턴하는 경우에는 NullReferenceException이 발생할 가능성을 있기 때문이고,
2. Null을 리턴하는 경우와 빈 컬력션이나 빈 문자열을 반환할 경우 처리가 그리 다르지 않기 때문이며,
3. .NET Framework의 경우에도 예외적인 경우가 아닌 경우에는 Null에 대한 고려를 개발자가 할 필요가 없게 하기 위해 Null을 리턴하지 않는다고 합니다.

생각해보면 메소드에서 Null을 리턴하는 경우는 그 코드를 작성한 사람이 아닌 경우에 Null인 경우를 고려해서 Null 체크를 해 주거나, 또는 Null과 Empty인 경우를 둘다 처리하는 경우가 자주 있었던거 같습니다.

Link된 글에서는 빈 Array나 빈 문자열에 대한 메모리 할당에 대한 트레이드오프도 언급하고 있습니다.
하지만 그 비용이 아주 미미하고, 빈 컬렉션에 대한 스태틱변수를 공유하면 우려할 만한 문제는 아니라고 언급하고 있습니다.

FAMFAMFAM
http://www.famfamfam.com/
약 1,000개의 SILK 셋트(PNG) 파일과 국기 셋트 파일을 제공합니다.

Tango Icon Library
http://tango.freedesktop.org/Tango_Icon_Library

Paint.NET 블로그 사이트를 통해서 알게 된 아이콘 라이브러리 입니다.
Paint.NET도 위 두 사이트에서 아이콘을 사용한 것 같은데 Tango는 GNOME이나 KDE의 데스크탑 Theme을 위해서 만들어진 것 같은데
Paint.NET 팀은 여기서 어떻게 아이콘을 뽑아낸건지 모르겠네요. 구글링해보면 PNG 파일로 제공한 사이트도 있는데 좀 만족스러운 곳이 없습니다.

libsvg를 사용해서 png 파일로 뽑아낼 수 있는거 같은데 자세한 방법은 모르겠네요.

이전 Component.DesignMode Property에서 말했던 방법이 결코 만능은 아닌 듯하다.
뭔가 이상하게 그 때는 제대로 Form에서는 보였는데 지금은 또 말썽이다.
이와 같은 문제와 관련된 Article을 구글링으로 찾아볼 수 있었다.

Identifying the Run-Time and the Design Mode

이 글에서도 Component.DesgnMode와 LicenseManager.UsageMode, 그리고 Process 이름을 가지고 판별하는 세 가지 방법을 소개했는데 다 상황에 따라 달라서 범용적으로 적용하기가 애매하다.

Designer에서 문제가 될 소지가 있는 코드는 생성자에서 제거하고 Public 메소드로 분리해서 상위 컨트롤에서 호출해주는게 제일 좋은 방법 같다.

UserControl을 상속받아서 어떤 컨트롤을 만들때, 때로는 Control이 Load되는 시점에서 DB로 부터 Control에 속한 ComboBox나 Grid를 초기화하는 코드들을 집어 넣어야 할 때가 있습니다.
그래서 OnLoad 함수를 오버로드하거나 이벤트 대리자 함수에서 위의 과정들을 구현하게 됩니다.
이제 UserControl이 만들어졌으니 마르고 닳도록 써먹어야지 하면서 Form위에도 올리고, 다른 UserControl에도 올립니다.
실행을 해보니 정상적으로 동작을 합니다.

하지만 해당 UserControl을 올린 Form의 Layout을 수정할 일이 생겨서 다시 Form의 디자이너 창을 띄웁니다.
그런데 이게 왠일?

이런 에러메세지가 나면서 작업을 할 수가 없게 됩니다.
이유는 아시겠지만 디자이너창에서 Form을 띄울때 UserControl의 OnLoad가 실행되기 때문입니다.

이럴 때 System.ComponentModel.Component의 DesignMode Property를 자주 사용하였습니다.

        protected override void OnLoad(EventArgs e)
        {
            if (this.DesignMode == false)
            {
                // Do Something....
            }
        }

이런식으로 말이죠.

하지만 이 DesignMode 속성도 믿을만한게 못 됩니다.
첫째, 이런 코드들을 생성자에서 사용할 때는 DesignMode로 제어할 수가 없습니다. 생성자내에서 DesignMode의 값은 언제나 False입니다.
생성자가 실행된 후에 DesignMode의 값이 셋팅되기 때문입니다.

두번째는 UserControl(A)을 올려둔 다른 UserControl(B)을 다른 UserControl(C)이나 Form(C)에 올려놓을 때 발생합니다. 이 때는 첫번째 UserControl(A)에서 DesignMode로 제어해봐야 C에 해당하는 UserControl이나 Form에서는 마찬가지로 디자이너 창에서 에러가 발생하게 됩니다.


이런 경우에 System.ComponentModel.LicenseManager의 UsageMode속성을 사용하면 만족스런 결과를 얻을 수 있습니다.
아까 위의 코드를 다음과 같이 고치면 되겠습니다.

        protected override void OnLoad(EventArgs e)
        {
            if (LicenseManager.UsageMode == LicenseUsageMode.Designtime)
            {
                // Do Something....
            }
        }