상황설명

UserControl 부모와 UserControl 자식이
UserControl.Resource 하위에 같은 이름을 가진 스토리보드를 가지고 있는 상황에서,
자식을 생성하여 부모의 LayoutRoot.Children에 Add를 하려고 시도하면,
경우에 따라서 다음 그림과 같이 ArgumentException을 유발합니다.

정확히 어떤 경우에 이렇게 되는지 실험을 통해 알아 보았습니다.

실험조건

Fafamama 클래스 - 부모 역할을 하는 UserControl 입니다.
Son 클래스 - 자식 역할을 하는 UserControl입니다.
Daughter 클래스 - 자식 역할을 하는 UserControl입니다.

Fafamama는 LayoutRoot의 Opacity를 조정하는 sbShow란 Storyboard를 UserControl.Resources 하위에 가지고 있으며,
Son은 Fafamama를 쏙 빼 닮아 자신의 LayoutRoot의 Opacity를 조정하는 sbShow란 똑같은 이름의
Storyboard를 가지고 있습니다.
Daughter는 Son이 가지고 있는 스토리보드와 똑같은 스토리보드를 이름만 다르게 하여 가지고 있습니다.

Fafamama.MakeSons() 메서드 - 두 명의 아들을 생성합니다.
Fafamama.MakeDaughters() 메서드 - 두 명의 딸을 생성합니다.

총 6가지 케이스를 실험하기 위해 6번 Fafamama를 생성합니다.

Case 1) Fafamama의 생성자에서 MakeDaughters 호출
Case 2) Fafamama의 Loaded 이벤트에서 MakeDaughters 호출
Case 3) 버튼 클릭에 의해 이미 생성되어 있는 Fafamama의 MakeDaughters 호출

Case 4) Fafamama의 생성자에서 MakeSons 호출
Case 5) Fafamama의 Loaded 이벤트에서 MakeSons 호출
Case 6) 버튼 클릭에 의해 이미 생성되어 있는 Fafamama의 MakeSons 호출

라이브 실험

아래 실버라이트 어플리케이션 안에 실험 Case 6개에 대한 버튼을 준비 하였습니다.
한번 씩 눌러보십시오.

실험결과

부모와 같은 이름의 Storyboard를 가지고 있지 않은 Daughter의 경우, 언제나 예외발생 없이 생성이 된 반면,
UserControl 부모, 자식이 같은 이름의 스토리보드를 가지고 있는 Son의 경우,
생성자에서 호출 시를 제외하고서는 부모의 Panel에 Children.Add 할 수 없었습니다.
이런 경우를 만나신다면 당분간은 피해서(스토리보드 이름을 중복되지 않게 준다거나, 이름을 유지하고, 다른 객체의 Resources 하위로 옮김) 사용해야 하겠습니다.

다운로드

실험에 사용된 프로젝트입니다.

 

리듬잇 같은 BMS류의 게임을 Silverlight로 제작하다가 발견한 문제입니다.
예를 들어 어떤 곡에서 270여 개의 음원을 사용하는 이유로,
이 음원에 대한 MediaElement를 미리 270개 생성해 놓고 사용하고자 하였습니다.
그 곡을 재생시켜보자 군데군데 연주되지 않는 음이 발견되었습니다.

왜그런가 테스트를 해보다가 123번째 MediaElement 이후에 생성된
MediaElement들은 Play() 메서드가 제대로 작동하지 않는 것을
발견하였습니다.

시뮬레이션

다음은 직접 문제를 체험해 볼 수 있는 샘플입니다.
스피커를 켜고 테스트를 해 보십시오.



소스

아래 링크를 클릭하여 다운 받으십시오.


실험의 결론

Silverlight 2 Beta1에서는 123개 이하의 MediaElement만 만들어 사용해야 합니다.
123개 이상의 MediaElement가 필요한 경우에는 이미 생성해 놓은 MediaElement를
Source만 변경하여 재활용해야 합니다.

예를들어 한 Silverlight Page 내에 123개를 초과하는 동영상, 음악이 존재하는 경우에는
초과분에 해당하는 미디어는 재생을 시킬 수 없습니다.

다른 테스트를 통해 다음과 같은 사실도 추가적으로 알 수 있었습니다.

1) XAML에 <MediaElement ...> 형태로 추가를 해도 124번째부터는 작동을 안 합니다.
2) MediaElement마다 서로 다른 Source를 입력해 주어도 결과는 같습니다.

원인이 무엇인지 궁금합니다.
원인에 따라 차후에 발표되는 Beta2나 정식 릴리즈에서
개선될 수도 있고, 개선되지 않을 수도 있겠네요.

포럼 피드백

실버라이트 포럼에도 같은 글을 게시해 놓고 피드백을 기다리고 있습니다.
http://silverlight.net/forums/t/11735.aspx

crossdomain.xml과 clientaccesspolicy.xml 파일은 아시다시피,
크로스 도메인 접근을 가능 여부를 설정하는 파일입니다.

'무엇에 쓰는 물건인고?'
더 궁금하신 분은 공도님이 실버라이트 2 Beta 1 시절에 정리한
포스트가 있으니 참고 바랍니다. xml 파일 내용은 변경되었지만, 큰 틀은 같습니다.

매번 필요할 때마다 웹서핑하는게 좀 소모적인 것 같아서,
블로그에 세간살이로 들여 놓습니다.


clientaccesspolicy.xml


crossdomain.xml

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM

  "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

  <allow-http-request-headers-from domain="* " headers="*" />

</cross-domain-policy>

출처 : How to: Make a Service Available Across Domain Boundaries

개요

오늘은 Application.Current.Host.Content.FullScreenChanged 이벤트에 대해서
한 말씀드리려고 합니다.

실버라이트 2 버전에서부터 Grid 등의 등장과 함께 화면구성하기가 용이해 졌습니다.
예를들어 LayoutRoot의 Width, Height를 Auto로 설정하고,
HorizontalAlignment, VerticalAlignment를 Stretch로 설정하고,
Margin 적당히 주면, 어떤 화면 사이즈에서도 척척 알아서 변하는 UI로 꾸밀 수 있죠.

FullScreen Mode에서는 어떨까요?
네! 화면이 FullScreen이 되면 위에 언급한 것과 같이 구성된 UI는
전체화면 사이즈에 맞게 변화합니다.

하지만 여기에 시차가 존재합니다.

FullScreenChanged 이벤트 핸들러 함수에서 어떤 UIElement의 ActualWidth, ActualHeight
등 사이즈에 관련된 프로퍼티를 참조하는 것은 바람직하지 않습니다.

그 이유를 실험을 통해 알려드리겠습니다.

다운로드 : 실험을 위한 샘플 프로젝트

FullScreenChangedSample.zip

실험방법

50ms의 Interval로 설정된 DispatcherTimer가
ScrollViewer와 LayoutRoot, Application.Current.Host.Content의 Width를 출력합니다.

FullScreenChanged 이벤트 핸들러에서, [IsFullScreen = true / false]를 출력합니다.

샘플 어플리케이션이 실행되면, FullScreen On/Off 버튼을 눌러 전체화면으로 갔다가,
ESC 키를 눌러 전체화면을 해제한 다음 Stop Timer를 눌러 타이머에 의한 출력을 중단합니다.


실험결과

실험 결과를 보면 'FullScreen Mode가 전환되는 시점'에서
Application.Current.Host.Context.ActualWidth를 제외한 다른 UIElement의 ActualWidth는
바람직한 사이즈 값을 갖게 되는데 시간 지연이 있음을 알 수 있습니다.


결론

FullScreen 전환에 따라 변화한 UIElement들의 사이즈를 참조하려면,
Application.Current.Host.Content.FullScreenChanged 이벤트 핸들러 보다는

SizeChanged 이벤트 핸들러에서 Application.Current.Host.Content.IsFullScreen의
분기문을 작성하여 구현하는 것이 안전하다.

실험의 목적

Application.Current.Host.Source의 주석은 아래와 같습니다.

// Summary:
//     Gets the URI of the XAML file that specifies the XAML content to render.
//
// Returns:
//     The URI of the XAML file or XAML scripting tag that contains the content
//     to load into the Silverlight plug-in. Generally, this is a reference to a
//     XAML file. The URI can also be an inline XAML reference using the "#" prefix;
//     see Remarks.

xap 파일을 활용하여 object 태그를 사용하여 퍼가기를 한 경우
실버라이트 객체가 자기가 호스팅되는 위치를 Application.Current.Host.Source를
통해서 정확히 참조 할 수 있는지 확인하는 것입니다.

퍼가기 코드



테스트

아래 버튼을 클릭해 보십시오.



결과

사용자가 object 객체의 Parameter 중 source로 입력한 경로를
무조건 '상대경로'로 인식하여 프로퍼티에 저장하고 있는 문제를 확인하였습니다.

웹서비스를 사용 시 로컬에서 실행될 때와 서버에서 실행될 경우에 관계없이
자동으로 Host 인식해서 Service Reference를 현재 서버경로로 바꿔주는
방식을 구현하는데 Application.Current.Host.Source를 사용할 경우 주의가 필요할 것 같습니다.

리듬잇 같은 BMS류의 게임을 Silverlight로 제작하다가 발견한 문제입니다.
예를 들어 어떤 곡에서 270여 개의 음원을 사용하는 이유로,
이 음원에 대한 MediaElement를 미리 270개 생성해 놓고 사용하고자 하였습니다.
그 곡을 재생시켜보자 군데군데 연주되지 않는 음이 발견되었습니다.

왜그런가 테스트를 해보다가 123번째 MediaElement 이후에 생성된
MediaElement들은 Play() 메서드가 제대로 작동하지 않는 것을
발견하였습니다.

시뮬레이션

다음은 직접 문제를 체험해 볼 수 있는 샘플입니다.
스피커를 켜고 테스트를 해 보십시오.



소스

아래 링크를 클릭하여 다운받으십시오.


실험의 결론

Silverlight 2 Beta1에서는 123개 이하의 MediaElement만 만들어 사용해야 합니다.
123개 이상의 MediaElement가 필요한 경우에는 이미 생성해 놓은 MediaElement를
Source만 변경하여 재활용해야 합니다.

예를들어 한 Silverlight Page 내에 123개를 초과하는 동영상, 음악이 존재하는 경우에는
초과분에 해당하는 미디어는 재생을 시킬 수 없습니다.

다른 테스트를 통해 다음과 같은 사실도 추가적으로 알 수 있었습니다.

1) XAML에 <MediaElement ...> 형태로 추가를 해도 124번째부터는 작동을 안 합니다.
2) MediaElement마다 서로 다른 Source를 입력해 주어도 결과는 같습니다.

원인이 무엇인지 궁금합니다.
원인에 따라 차후에 발표되는 Beta2나 정식 릴리즈에서
개선될 수도 있고, 개선되지 않을 수도 있겠네요.

포럼 피드백

실버라이트 포럼에도 같은 글을 게시해 놓고 피드백을 기다리고 있습니다.
http://silverlight.net/forums/t/11735.aspx

왠만한 문제를 제휴를 통해서 해결한다고 가정했을 때, 5번 항목이 조금 걸리네요.
실버라이트에서 사용하려면 API를 통하지 않고 지도 이미지를 사용할 수 있어야 하는데요.
이 문제가 제휴를 통해서 극복이 가능한지 모르겠습니다.

참조 : http://openapi.naver.com/page.nhn?PageId=faq 중 7.네이버 지도 API FAQ


Naver Open API Reference 문서

지도, Deep Zoom 등 2차원 솔루션에서, 정보의 구축과 검색을 원활히 하기 위해서,
QuadTree 형식의 자료 구조가 구현되는 것이 바람직합니다.

예를들면 방대한 영역에 존재하는 데이터 중,
보이는 화면영역에 해당하는 데이터만 빨리빨리 찾아와야 할 때 유용합니다.

QuadTree는 4개의 자식을 갖는 트리구조입니다.
평면을 계속 4분할해 나가면서 트리가 구성됩니다.

1개의 Cell은 maximum capacity를 가지고 있어서, 그 값이 넘게 자식이 존재해야할
필요성이 있을 때 또 분할됩니다.


수직선, 수평선이란 자식까지 정의하여 총 6개의 자식을 갖도록 설계하는 경우도 있습니다.
(CAD/CAM 프로그래밍 할 때 그렇게 했었음.)

한번 이렇게 구성된(Build) QuadTree는 영역에 대한 검색을 실시 할 때,
유용하게 사용됩니다.

5년동안 MFC로 CAD/CAM 프로그래밍하는 동안 매일 만지작거려왔는데,
이제는 실버라이트에서도 사용하기 위해서 QuadTree를 C#으로 포팅할 때가 된 것 같습니다.

그전에 혹시 쓸만한 좋은 소스가 있는지 코드플렉스를 뒤져봤습니다.
XNA 관련된 소스만 찾을 수 있었습니다.

XNA에서는 QuadTree가 어떻게 활용되고 있는지
Youtube에 올라와 있는 데모 동영상을 보시죠.

사실 이 동영상에는 쿼드트리 이상의 것이 들어있어서 요점을 흐릴 수 있습니다만,
쿼드 트리가 없으면 퍼포먼스가 엄청 떨어지는 데모입니다.

ClientBin, bin 디렉토리 내용물 지우기,
'다시 빌드' 해보기,
VS2008 종료 후 재실행,
컴퓨터 리부팅

위와 같은 민간요법을 주로 애용 했었는데요.
이렇게 해도 안되면 Project를 아예 새로 만들었던 과격프로그래머!!!

웹사이트 속성에서 해결 할 수 있는 것을 공도님한테 배웠습니다.

속성창에서 Start Options 항목의 Debuggers Group에서
Silverlight 체크박스에 체크를 합니다.
(원래 이 항목은 실버라이트 기본프로젝트 만들 당시에 체크가 되어있습니다.
허나 무슨 이유에서인지 쓰다가 이런 문제가 있어서 보면 해제되어 있습니다. -_-;;;
해제되는 단축키라도 있는거야????)

이렇게 하고 나니 다시 중단점에서 프로세스가 잘 걸리네요.
모르면 손발이 두잇이죠... ^^