Error 1001

오늘도 또 실버라이트의 치부를 공개하게 되는군요.

어제 저는 원하지도 않는 기능을 실버라이트가 지원하고 있다는 사실을 알게 되었습니다.

바로 SpaceBar Click 입니다. 이것은 ButtonBase를 상속한 모든 객체가 적용됩니다.

실제로 Button에 Focus가 가있는 상태에서만 작동을 해서 문제가 되지 않을 수 있지만 다음에

경우 크게 문제가 됩니다.

Button 클릭으로 어떤 새로운 객체를 띄워야 하는 경우.. 이 경우 만약 버튼이 새로운 객체에 의해

가려진다면 실제 의도상으로는 새로운 객체는 한개만 띄워져야 하지만 SpaceBar를 사용하면 여러번

띄워지는 경우가 생기죠.

  이 경우는 개발자가 부주의 한 탓에 생긴 버그라고 할 수 있죠.. 이런 경우 클릭 이후 Focus를 새로 띄운

객체에게 다시 맞춰줘야겠죠.

  다음의 경우는 버그가 좀더 심각합니다. 간단한 프로젝트를 첨부하니 한번 확인해 보시길 바랍니다.




  테스트 방법은 간단합니다.

Button을 하나 만들고 Click 시 이 버튼의 Visibility 를 Collapsed 시켜줍니다.

그리고 Spacebar를 눌러서 Click 이벤트를 발생시킵니다.




  다음과 같은 에러가 발생하는군요...

 이 경우는 명백히 버그로 보이지만 피할 방법은 있습니다.

 이렇게 Button에 Focus가 가있는 상태에서 Visibility를 Collapsed 시켜줄 때는 반드시

Focus를 잃게 만드는 것입니다. 그런데.. Focus를 잃게 만드는 메소드가 없으니 Focus가

가도 상관없는 다른 객체에 Focus가 가도록 설정해두면 됩니다.


  예전에는 Page에서 밖에 KeyEvent를 못받아서 불편하긴 했어도 이런 문제는 없었는데 이제

모든 Control들이 KeyEvent를 받으니 이런 문제가 생기는군요.

   암튼 간단히 결론만 말씀드리자면 다음과 같습니다.
  
  오늘은 결론이 간단하네요.^^ 그럼 Focus관리 잘하셔서

모두들 삽질 덜하시길..^^

                                                                                                       - smile -
 

위의 프로젝트는 여러객체의 VisualState를 동시에 조작할 경우의 오작동을 테스트한 프로젝트입니다.

실험 방법은 간단합니다. 프로젝트를 실행하면 다음과 같은 화면이 나옵니다.




왼쪽에는 작은 직사각형 모양의 UserControl 이 StackPanel 안에 담겨 있고 현재 상태는 Normal 상태로

그냥 빨간색으로만 보이게 해두었습니다. 여기서 마우스 over를 하면 다음과 같이 변합니다.



여기서 왼쪽 패널을 적당히 훑어서 MouseOver 상태가 제대로 작동하는 것을 확인합니다.

이후에 오른쪽에 All Over State 버튼을 눌러봅니다.

   All Over State 를 누르면 VisualState를 직접 조정해주어서 왼쪽에 모든 UserControl을

Over상태로 바꾸어 줍니다.  그러면 오른쪽에 있는 모든 UserControl이 회색빛으로 바뀌어야

겠죠?.. 그런데 결과는 이렇습니다.

 

아주 랜덤하게 중간에 하나씩 이 빠진 놈이 생기게 됩니다.

왼쪽 리스트에 갯수가 적으면 경우의 수가 줄어들지만 많으면 많아질 수록 확율이 증가하는 것 같습니다.


반대의 경우도 생기는데 위의 상태에서 적당히 몇개의 Rectangle만 MouseOver후 빠져나와 다시 빨간색으로

바꾸어 줍니다. 그 후 All Leave State 버튼을 누릅니다. 이 역시 모두 빨간색으로 변해야만 하겠지만 결과는

위의 경우와 똑같이 랜덤하게 한 두 개씩 상태가 변하지 않는 경우가 생깁니다.

 

  두가지 상황 모두 어떠한 애러도 발생하지 않습니다. 이런 경우가 특히 문제가 되는 경우가 바로 MultiSelect

지원 ListBox를 만들었을 때입니다. 이 경우 어쩔 수 없이 여러개의 ListBoxItem의 상태를 동시에 조정해주어야

하는데 이런 경우 위와 같은 애러가 랜덤하게 일어나게 됩니다. 물론 Visual 적으로만 영향을 줄뿐 코드상으로

어떤 문제도 발생하지 않습니다.

  그럼 모두 한번 테스트 해보시고 feedback 부탁드립니다.

  그리고 테스트 방법등이나 이와 관련된 사항에 대해 질문이 있으신 분들도 언제든지 댓글을 남겨주시길

바랍니다.


                                                                                                                   - smile -

  

상황설명

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 하위로 옮김) 사용해야 하겠습니다.

다운로드


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



원문 : http://gilverlight.net/2898