Visual Studio 2008을 사용하여 C# 또는 VB.NET용 프로젝트를 생성하여 디자인 창에서 여러 개의 UI 컴포넌트를 사용하여 Form을 구성한 경우 아래와 같은 문제가 발생하게 됩니다.
[CASE-1] Form.cs의 소스코드를 수정하거나 디자인 창을 닫았다 열었을 때 폼 디자인 창을 갱신(Reload)하는 시간이 늘어나는 문제
[CASE-2] .Net Compact Framework의 버그로 인해 디버깅 시작(트레이스 모드)을 진행할 때 연결이 종료되는 문제 (종료 시 오류 발생 메시지가 출력됩니다.)
※ 해당 문제는 .Net Compact Framework와 Visual Studio 2008의 문제로 SmartX와는 관련이 없습니다.
CASE-1. 폼 디자인 창의 갱신 속도가 느려지는 문제Visual Studio 2008을 사용하여 C# 또는 VB.NET용 프로젝트를 생성하여 디자인 창에서 여러개의 UI컴포넌트를 사용하여 Form을 구성한 경우 Form.cs의 소스코드를 수정하거나 디자인 창을 닫았다 열었을 때 폼 디자인 창을 갱신(Reload)합니다. 디자인 창을 갱신(Reload)하는 과정에서 메모리 릭(메모리 누수)가 발생하여 Visual Studio의 메모리 사용량이 늘어나게 되어 폼디자인의 갱신 속도가 점점 느려지게 됩니다.
메모리 릭의 경우 .NET Compact Framework에서의 문제로 이미지가 사용되는 .NET CF의 컴포넌트에서도 동일한 문제가 발생합니다. (PictureBox 등)
사용되는 컴포넌트의 개수에 비례하여 화면 갱신(Reload)시간과 메모리 사용량이 늘어나게 되며 일정 횟수 이상 Loading이 반복되었을 때 폼 디자인창이 오류와 함께 열리지 않는 문제가 발생할 수 있습니다.
에러가 발생하여 폼 디자인창이 열리지 않는 경우 Visual Studio 2008을 종료 후 다시 실행하시기 바랍니다.
프로젝트에서 많이 사용되는 SmartX Framework 컴포넌트인 SmartLabel, SmartCheckBox, SmartRadioButton, SmartButton의 화면 로딩 시간을 비교해보면 SmartLabel < SmartCheckBox < SmartRadioButton < SmartButton 순서로 컴포넌트가 무거우며 동일한 개수의 컴포넌트라도 가벼운 컴포넌트를 많이 사용하는 경우와 무거운 컴포넌트를 많이 사용하는 경우의 화면 갱신(Reload) 시간은 다릅니다.
CASE-2. 디버깅 시작(트레이스 모드)을 진행할 때 응용 프로그램 에러가 발생하는 문제권장 개수 이상의 UI 컴포넌트를 추가하고 코드의 복잡도가 높으며, 이벤트가 많이 추가되어 있는 경우 .Net Compact Framework의 버그로 인해 디버깅 시작(트레이스 모드)을 진행할 때 응용 프로그램 에러가 발생하게 됩니다.
응용 프로그램 에러가 발생하는 시점은 프로그램에 따라 다르며, Form_Load에서 발생하거나 임의의 동작에서 발생하게 됩니다.
해당 현상은 디버깅하지 않고 시작으로 프로그램을 배포하거나 실행파일을 Run폴더에 복사해 Runtime Mode로 실행할 경우에는 발생하지 않습니다. 이와 같은 불편함 점을 줄이고자 HNS에서는 프로젝트 제작 시 하나의 폼 당 적정 컴포넌트 개수를 제안 드리니 프로그램 개발 시 참고하시기 바랍니다.
[영상자료]프로젝트에서의 하나의 폼에 사용하기 적정 컴포넌트 개수를 안내하오니 프로젝트 제작 시 결과를 참고하여 프로젝트를 제작하시기 바랍니다. 안내해 드린 컴포넌트 개수를 초과하는 경우 소스코드 수정 후 디자인 화면 로딩 시 갱신(Reload) 되는 시간이 늘어나게 되며, 폼 디자인창이 열리지 않고 에러가 발생할 수 있습니다.
MDI 구성방식 | SmartButton 50개 |
SmartButton 100개 |
---|---|---|
SmartForm + SmartForm |
2.xx초 | 4.xx초 |
SmartForm + SmartInnerForm |
4.xx초 | 7.xx초 |
권장하는 컴포넌트의 개수는 50~60개 내외미만이며 동일환경에서 .Net Compact Framework와 SmartX Framework 컴포넌트의 사용시 시간차이는 거의 없습니다.
MDI 구성 방식 | 권장 컴포넌트 개수 |
---|---|
SmartForm(부모폼) + SmartForm(자식폼) |
50~60개 정도 사용시 갱신시간은 평균 3초 |
SmartForm(부모폼) + SmartInnerForm(자식폼) |
50~60개 정도 사용시 갱신시간은 평균 4초 |
※ 해당 표의 경우 실제 제작하신 프로그램에서는 차이가 발생할 수 있으므로 참고하시기 바랍니다.
※ 테스트는 .Net Compact Framework로만 구성된 프로그램과 SmartX New Framework로만 구성된 프로그램 2개로 진행하였습니다.
UI Component 개수 | Form 5개 | Form 10개 |
---|---|---|
50개 | 에러가 발생하지 않음 | 에러가 발생하지 않음 |
100개 | 에러 발생 | 에러 발생 |
1. 컴포넌트의 개수에 비례하여 디자인 화면의 갱신(Reload)시간 및 메모리 사용량은 증가하며 개발 프로젝트의 컴포넌트 사용시 테스트 결과를 참고하여 적정한 컴포넌트 개수를 사용바랍니다. (적당한 컴포넌트 수는 폼당 50~60개 내외)
2. 하나의 폼에서 컴포넌트 개수가 100개를 초과한다고 해서 프로그램에 문제가 발생하지는 않으며 소스 수정 시 디자인 화면의 갱신(Reload) 시간이 늘어나는 불편함이 존재하며, 디자인창의 갱신이 반복될 경우 폼 디자인창이 에러가 발생하면서 열리지 않는 문제가 발생할 수 있습니다.
3. 폼에 적정 개수 이상의 컴포넌트를 추가할 경우 디버깅 시작(트레이스 모드)으로 프로그램을 실행했을 때 연결이 종료되는 문제가 발생합니다. (연결 종료 시 에러 메시지가 출력됩니다.) 해당 문제는 .Net Compact Framework와 Visual Studio 2008의 버그로 SmartX Framework와는 관련이 없습니다.
4. 프로젝트에서 사용된 전체 폼의 개수가 많은 경우 SmartForm(부모폼) + SmartInnerForm(자식폼) 형태의 MDI(Multi Document Interface)보다 SmartForm(부모폼)+SmartForm(자식폼) 형태로 MDI를 구성하여 사용바랍니다. SmartForm(부모폼) + SmartInnerForm(자식폼) 형태의 MDI는 Form 컨테이너 객체위에 포함되므로 폼의 개수가 많아지는 경우 디자인 모드에서 한번에 로드되는 컴포넌트의 개수가 많아져서 폼의 개수만큼 화면의 갱신시간이 증가됩니다.
5. SmartX에서 특정 기능의 컴포넌트와 .NET Component의 동일 기능의 컴포넌트를 비교하는 경우 폼 디자인창의 로딩 시간과 응용 프로그램 에러 발생 유무는 크게 차이가 없었습니다.