XPLATFORM 101
그럼 간단한 애플리케이션을 만들면서 디버깅에 대해 살펴보겠습니다.

만들어볼 애플리케이션은 간단한 그리드에 간단한 데이터가 들어가고
각 셀을 클릭하면 이벤트를 발생시키도록 했습니다.

새로운 프로젝트를 만들고 (File > New > Project)
새로운 폼을 만듭니다 (File > New > Item > Form)

툴바에서 그리드를 선택하고 폼에 배치합니다.
크기는 상관없습니다.
그리고 DataSet도 하나 만들어줍니다.
DataSet 은 실체는 있지만 눈에 보이지 않는 객체로 폼에서 그려도 상관없지만
폼에 표현되지 않고 Invisible Objects 영역에 표시됩니다.


데이터도 설정해놓고 DataSet을 그리드로 드래그앤드롭해서 연결하면 셋팅이 완료됩니다.
그리드 이벤트에서 oncellclick 를 선택하고 다음과 같이 function을 만들어줍니다.

function Grid00_oncellclick(obj:Grid, e:GridClickEventInfo)
{
var a = 'test :';
trace(a);
}

oncellclick 이벤트에서는 Event 가 발생한 객체인 그리드와 이벤트정보가 담긴 값을 던져줍니다.
이벤트정보에 들어가는 값은 GridClickEventInfo 라는 형태로 던져지는데
이 값에 어떤 내용이 들어가는지 확인을 하고 싶다면 하나하나 로그를 찍어보는 것보다
디버깅 모드에서 확인하는 것이 좀 더 간단합니다.
자 그럼 Grid00_oncellclick 라는 function 내에 브레이크포인트를 찍어주고 해당 애플리케이션을 실행해봅니다.
화면이 실행되면 그리드에 표시된 셀을 클릭합니다.
그럼 이벤트가 처리되는 function 내 브레이크포인트에서 멈춘 상태에서 몇가지 정보를 담은 패널을 확인할 수 있습니다.

- variables 패널
: 현재 상태에서 확인 가능한 변수의 상태값을 보여줍니다.


하위 속성을 가지고 있는 오브젝트인 경우에는 하위 트리를 감춘 상태에서 보여지고
문자열 변수인 경우에는 바로 값을 보여줍니다.

여기서 알고 싶은 것은 GridClickEventInfo 안에 어떤 값이 들어가는지 알고 싶은 것이니깐
해당 부분을 펼쳐줍니다.


각 속성에 대한 값을 확인할 수 있습니다.
어떤 셀을 클릭했는지 확인하기 위해서는 row와 col 값이 필요한데
여기서 바로 확인이 가능합니다.

여기서 특정 변수를 계속해서 관찰해야 한다면 매번 수많은 속성 가운데서 찾는것이 쉽지는 않을겁니다.
그럴때에는 원하는 속성을 Watch 패널로 옮길 수 있습니다.
옮기는 방법이 좀 애매하긴 한데
그냥 직접 입력하는게 가장 편합니다.
Expression 항목에 e.col, e.row 를 입력하시면 다음과 같이 보이게 됩니다.



각 속성 뿐 아니라 오브젝트 자체를 가져다 놓을 수도 있습니다.

그리고 또 하나 확인 가능한 패널은 Call Stack 입니다.
브레이크 포인트까지 거쳐온 함수를 역순으로 표기해줍니다.
특정 변수값이 이상하게 꼬였을 경우에는 어떤 경로를 거쳐 왔는지 확인해야만 문제를 찾을 수 있습니다.
엑스플랫폼으로 개발하는 경우에는 그렇게 까지 꼬여서 들어오는 값이 있지는 않겠지만
그래도 모르는 것보다는 낫다는..^^


Call Stack 패널에서도 해당 Function 을 클릭하면 해당 라인으로 이동하게 됩니다.
패널 내에서 바로 이동해서 내용을 확인할 수 있습니다.

* 변수 역추적이 가능할까 싶었는데 거기까지는 안되네요.
필요하다면 각 프로세스에서 스냅샷처럼 가져가는 방식을 취해야 할듯 합니다.

http://cafe.naver.com/xplatform101/27
 
XPLATFORM 101
애플리케이션 개발 시 가장 어려운 부분이 어디서 문제가 생기는지 확인하는 작업입니다.
과거에는 alert 메시지나 로그만으로 오류가 발생하는 지점을 찾아야 했지만 
최근에 나오는 도구는 대부분 디버깅 기능을 제공하고 있어
그나마 개발자들의 부담을 덜어주고 있습니다.



엑스플랫폼 개발시 사용하는 UX 스튜디오에도 기본적인 디버깅 기능을 제공합니다.
전체 프로젝트 단위 또는 개별 화면 단위로 라인 디버깅(Line Debugging)을 지원하며
특정 함수나 서브루틴 실행 시 상위 호출 함수 관계를 확인할 수 있는 Call Stack 기능을 제공합니다.

또한 디버깅 외에도 Trace Log를 설정할 수 있는 기능을 디버깅과 별도로 제공합니다.

일단 UX 스튜디오에서 디버깅과 관련된 기능을 살펴보겠습니다.
다른 툴을 다루어보셨다면 익숙하겠지만 그렇지 않다면 처음에 좀 혼란스러울 수 있거든요.

- 디버깅 툴바
메뉴에서 Debug를 선택하거나 툴바에서 선택할 수 있습니다.


이건 툴바에 표시된 모습입니다.
약간 순서가 다르네요. 하지만 내용은 동일합니다.


자 이제 메뉴부터 하나하나 알아보겠습니다.
Start Debugging 단축키 F5 : 프로젝트 디버깅 시작 모드입니다. 폼에 대한 내용이 아니라 프로젝트 자체에 대한 디버깅이라는 것에 주의해야 합니다.
Start Form Debugging 단축키 F6 : 폼에 대한 디버깅입니다. 퀵 뷰와 대응하는 디버깅 메뉴네요.
Stop Debugging 단축키 Shift + F5 : 디버깅 프로세스를 중지시킵니다. 
디버깅 프로세스 동안에는 시작과 관련된 버튼은 비활성화됩니다.
Restart : 디버깅을 다시 시작합니다. 원래 의도는 디버깅 진행중에 현재 디버깅 프로세스를 중단하고
다시 시작하는 모드랍니다.

Step 과 관련된 항목은 항상 혼란스러운 부분입니다.
하지만 일반적인 디버깅 프로세스에 공통적으로 사용되는 부분이기 때문에 잘 알고 넘어가시면
도움이 되실 겁니다.
Step Into 단축키 F11 : 한 스텝씩 디버그. 함수내에서 다른 함수를 호출하는 경우에는 해당 함수로 이동합니다.
Step Into는 소스 코드의 첫 줄부터 차례로 실행하는 명령입니다.
첫번째 브레이크 포인트를 만나는 지점부터 활성화되며 소스의 흐름을 따라 프로세스를 점검할때
유용하게 사용할 수 있습니다.
Step Over 단축키 F10 : 현재 함수의 나머지 부분을 실행하고 함수 호출이 이루어진 다음 문장에서 멈춤이라고 메뉴얼에는 나와있는데 어렵네요. ㅠㅠ

예를 들어
==================================================================
function Grid00_oncellclick(obj:Grid, e:GridClickEventInfo)
{
(1) trace('test1');
(2) Grid00_test1();
(3) trace('test2');
}

function Grid00_test1()
{
(4) trace('test3');
(5) trace('test4');
}
==================================================================

이런 코드가 있고 (1)번에 브레이크 포인트가 있었다면 Step Into를 선택하면
프로세스가 (1)(2)(4)(5)(3)순으로 따라가며 멈춥니다.
하지만 Step Over 의 경우에는 (1)(2)(3)번에서만 멈추고 (4)(5)번이 포함된 함수는 지나갑니다.
그렇다고 아예 (4)번 프로세스가 실행이 안되는 것은 아닙니다.

두가지 경우 모두 로그는 아래와 같이 찍힙니다.
uxs (5096): test1
uxs (5096): test3
uxs (5096): test4
uxs (5096): test2

Step Out 단축키 Shift+F11 : 한 스텝을 모두 실행하고 다음 스텝으로 이동이라고 나와있는데..
앞의 예로 설명하면 (4)번까지 Step Into로 따라갔다가 (5)번은 별 볼일 없다고 생각될때 Step out을 선택하면
(3)번으로 바로 넘어갑니다. 현재의 함수에서 뒤에 오는 프로세스는 무시하고 넘어가는 거라고 보면 됩니다.

Run to Cursor 는 현재 커서가 있는 줄까지 실행한 다음에 멈춤이라고 합니다.
디버깅중에도 UX 스튜디오 에디터에 커서 이동이 가능합니다.
추가적인 브레이크 포인트도 지정할 수 있구요.
현재 디버깅 포인트에서 뒤에 커서를 놓았다면 그쪽으로 바로 이동하게 되고
혹 디버깅 포인트 앞에 놓게 되면 디버깅이 종료됩니다.

Toggle Breakpoint 단축키 F9 : 브레이크포인트를 지정하는 기능입니다. 토글이기 때문에 한번 실행하면 브레이크포인트가 생성되고 한번 실행하면 제거됩니다.
Delete Selected BreakpointGo To SourceEnable/DisableSelected Breakpoint : 이 친구는 툴바나 메뉴에 있을 필요는 없는데..ㅎㅎ
UX 스튜디오 하단에 보면 브레이크포인트 패널이 있는데 각 프로젝트 내에 설정된
브레이크포인트를 모두 확인할 수 있습니다. 각 항목에 대한 삭제나 활성화, 해당 소스 위치로 바로 가기 기능을 제공합니다.
메뉴나 디버깅 툴바보다는 해당 컨텍스트 메뉴에서 주로 사용하는 항목입니다.


Delete All Breakpoints : 약간 혼란스러울 수 있는데 말 그대로 다 지워주는 겁니다.
열려있는 폼에 대한 것만이 아니라 브레이크포인트 패널에 등록된 것은 다 지워줍니다.
Enable/Disable All Breakpoints : 마찬가지로 모든 항목에 대한 활성화 여부를 결정합니다.
삭제와 활성화의 차이는 삭제하는 경우에는 패널에서 항목을 지워주는 것이고
활성화 여부는 패널에 항목은 있지만 동작만 안하게 처리하는 겁니다.
나중에 포인트는 사용하겠지만 지금은 건너뛰는 경우에 필요하겠죠.

http://cafe.naver.com/xplatform101/26 
XPLATFORM 101
Application 을 한글로 표기할때 어떻게 할지 고민을 많이 합니다.
그냥 응용프로그램이라고 풀어서 쓰기도 하고
어플리케이션 또는 애플리케이션이라고 표기합니다.
어플리케이션과 애플리케이션 중에서 어떤 것이 맞냐고 물어보면
제각각 다른 답변을 남기더군요. ^^

OBS 의 유영선 아나운서가 블로그에 남긴 글을 보면 애플리케이션이 맞다고 주장(?)하고 있습니다.
발음기호 상으로는 오히려 애플러케이션과 애플리케이션으로 표기할 수 있다고 하네요.
국립국어원에서 이 문제는 애플리케이션으로 통일했다고 합니다.

발렌타인데이가 밸런타인데이로 변경되고 있다는것은 처음 알았네요.
어짜피 쓸 일도 없으니..ㄷㄷ


엑스플랫폼에서 Application 객체는 애플리케이션의 기본정보와 초기 생성 시 주어지는 환경정보를 다루는 기본이 되는 객체라고 합니다. 여기서 애플리케이션이라고 표기하면 엑스플랫폼 기반으로 만들어진 프로그램을 의미하게 되고 Application 이라고 하면 객체를 의미한다고 보시면 됩니다.

Application 에 속하는 메소드나 속성은 전역으로 접근 가능합니다.
예를 들어 alert 을 사용한다면 원래는 applicaiton.alert() 으로 표기해야 하지만
그냥 alert() 만 표기해도 됩니다.

Application 에서는 꽤 많은 속성을 제공합니다.
어플리케이션에서 사용하는 ADL 경로를 확인한다든지 (application.xadl)
캐시를 처리하는 경로를 얻어오고 (application.cachedir)
업데이트를 관리하기 위한 몇가지 속성 등을 제공합니다.
그리고 GlobalVariables 에 접근하는 것도 Application의 속성을 접근하게 됩니다.

alert, confirm, trace 같은 메소드도 Application의 메소드입니다. 앞에서 말한것처럼 전역으로 접근 가능하구요.

http://cafe.naver.com/xplatform101/25