vsview report와 chartFX 는 unicode를 지원하지 못함
현상
사용자 PC의 환경에 따라 언어 표현은 잘되지만, 다른 나라 언어 표현 시 글자가 깨지는 현상이 발생함(한국어로 설정된 PC에서 중국어로 표현 시 등등)
제조업체에서 98버전 지원함을 기본으로 하여 ansi string 처리로 변환하여 처리하는 것으로 판단됨
IE에서도 마찬가지로 안되고, 제조업체에서 수정되지 않는 한 Miplatform에서 할 수 있는 방안이 현재로서는 없음.
대안
다국어 지원되는 chart나 report를 사용할 것 (윈도우 98에서 작동 안 될 수 있음)
Internet Explorer(이하IE) 에서 MiplatformX 를 사용할 때
현상
Miplatform V3.1 Wantallkeys라는 속성을 true로 하면 모든 keyboard값을 다 사용한다는 의미로 사용되는데. 이때 f1 key와 f10 key는 Miplatformx.ocx에서 사용한다고 하더라고 IE가 이 key를 별도로 사용함.
F1은 help를 실행하고 f10은 메뉴가 activate 됨. ms사에서 이 F1,F10 key를 무조건 먼저 사용함.
대안
IE에 embbeding을 하는 한 대안은 없으며 IE에서 사용 시 f1,f10 key는 MiPlatform도 사용하고 IE에서도 사용하게 됨. 전용브라우저를 사용하면 이 문제를 피할 수 있음.
Local DB작업시 ADO로 personal oracle과 연동 시 문제점
현상
Personal Oracle이나, Oracle DB를 Local DB adaptor로 접근할 때 Active Data Object(이하ADO)를 사용 시 오류가 있음
Connect를 한 뒤, 조회/update할 때 마다 windows handle 자원이 2씩 증가하고, 줄어들지 않는 현상
종종 종료 시 Miplatform이 zombie상태로 process가 남아있음.
원인은 Ms사의 ADO driver와 Oracle사의 ADO용 Adaptor COM module이 서로 잘 맞지 않아서 발생하는 현상으로 oracle사의 ADO 및 OLE DB관련 patch가 있으나, patch하여도 종료 시 Miplatform이 zombie상태로 process가 남는 현상이 종종 발생함.
대안
Local DB Adaptor에서 Oracle을 사용 시 자사에서 제공하는 AdatorDBoraXXX.dll을 사용할 것
AdaptorDBoraXXX.dll은 Oracle사에서 제공하는 OCI function을 이용하여 제작한 것으로 OracleDB와는 안정성이 좋으며, 최적의 성능을 보임.
Miplatform 전용Browser에 WebBrowser 컴포넌트를 사용 시 문제점
현상
MiPlatform 내에 IE를 포함하고, 다시 IE내에 Miplatform을 넣거나, 그 Miplaform 내에 다시 IE ActiveX를 넣는 등, ActiveX를 중첩되게 사용할 경우에 발생하는 현상으로, Microsoft Foundation Classes (이하 MFC)의 메시지 처리 루틴이 Focus관련 메시지를 수행할 때, 처리해야 할 Window를 제대로 찾지 못하는 경우에 무한루프가 발생해 스택 오버플로우가 발생하는 현상임.
MFC의 ActiveX 메시지 loop 버그로, Miplatform form 안에, IE ActiveX 를 embedding하고, 그 ActiveX안에 Miplatform ActiveX를 넣어서 처리할 경우, MFC ActiveX 메시지 loop에서 제대로 return해 주지 않는 문제로 대안이 없음.
대안
MFC를 사용하는 한 대안이 없음. Miplatform V3.2에서는 이런 식의 코딩을 피할 것.
Microsoft사의 RichTextBox component를 Miplatform에서 사용 시 문제점
현상
PID 종료현상
Miplatform에 ActiveX로 Microsoft RichTextbox Component를 사용하는 경우, Appearance또는 BorderStyle, ScrollBar등 일부 속성이 적용된 RichTextbox를 포함하는 Form을 편집한 후 폼을 닫는 경우 PID가 비정상 종료되는 현상이 발생함.
RichTextBox Component가 로딩되면 또는 사용자가 속성을 변경하면, RichTextBox Component가 내부적으로 RichTextBox의 Window를 Re-Create하는 것으로 판단됨.
MFC의 ActiveX container 자체 버그로 ActiveX 내부에서 발생하는 Window의 Re-Create를 감지하지 못해 발생하는 문제로 판단됨.
Miplatform 종료현상
Miplatform에 ActiveX로 Microsoft RichTextbox Component를 사용하는 경우, Appearance또는 BorderStyle, ScrollBar등 일부 속성이 적용된 일부 Form을 닫거나, 다른 폼으로 이동하는 경우, Miplatform이 비정상 종료됨 (단 UsePeristData속성을 false로 한 경우에만 종료됨)
RichTextBox Component가 내부적으로 Window를 재생성 하는 것으로 판단됨.
MFC의 자체버그로 ActiveX 내부에서 발생하는 Window의 재생성을 감지하지 못해 발생하는 문제로 판단됨.
대안
PID 종료현상
RichTextbox 가 포함된 편집할 폼을 제외한 모든 폼을 저장 후 닫는다.
해당 Form을 편집한다.
편집된 Form을 저장하고 Form을 닫거나, PID를 종료한다.
(이때, Form을 닫아도 PID는 비정상 종료됨. 단, 저장은 성공함.)
다시 PID를 기동해 다음 편집작업을 계속한다.
Miplatform 종료현상
RichTextbox 의 UsePeristData를 True로 등록하여 개발하고, 사용할 것.
OnKillFocus에서 Open 사용 불가
현상
MiPlatform의 각 컴포넌트들의 OnKillFocus에서 Modal 형태인 Alert/Confirm/Dialog의 메시지처리는 정상작동하나 Modalless 형태인 Open 의 메시지처리는 MiPlatform이 오 동작.
대안
KillFocus에서의 Open은 사용자의 작성오류라고 봐야 함. 이와 같은 경우를 사용하지 않도록 해야 함.
Form의 Scroll Property의 기본값 복원 안 됨
현상
Form에 명시적으로 TRUE로 설정된 경우는 TRUE로 전환할 수 있지만, PID에서 Form의 Scroll값이 TRUE인 경우 저장하지 않음.
대안
FormXML이 로딩되기 전에 MainForm/ Div/TabPage/Dialog/Open등의 각각에 설정된 기본값으로 Scroll의 값을 초기화한다. 따라서 PID에서 Scroll을 true로 선택해 저장 한경우 저장이 되지 않는 특성 때문에 기본값에 따라 동작하게 된다.
MainForm은 기본값이 TRUE이며, Div/TabPage/Dialog/OpenWindow는 모드 기본값이 FALSE이다. 그러나, Design시에 Div/TabPage의 ScrollProperty를 FALSE에서 TRUE로 설정해 저장하는 것으로 기본값을 TRUE로 변경할 수 있다. 또한 Dialog/OpenWindow는 Dialog/OpenWindow를 생성하는 Dialog()/Open()함수의 인자중에 OpenStyle에 ‘Scroll=true’를 추가하는 것으로 기본값을 TRUE 변경할 수 있다.
OnDrop이 처리되지 않은 경우 상위 폼으로 전달되지 않음
현상
각 Component의 DropMode가 TRUE이고, OnDrop/ OnDragEnter/ OnDragOver /OnDragLeave의 경우 각 Event가 처리되지 않은 경우 상위 Form에서 각 Event가 발생하지 않음.
그러나, 각 Component의 DropMode가 FALSE인경우 Form의 해당이벤트가 발생함.
Miplatform V3.1에서 입력이 관련된 Event중 각 Component에서 뿐만 아니라 전체적으로 처리될 필요가 있는 경우(OnRButtonDown, OnRButtonUp, OnMouseOver, OnMouseLeave, OnKeyDown), 각 Component에서 해당 Event를 처리하지 않으면 Form에서 처리할 수 있도록 설계하여 해당 Event가 발생하게 됨. 그러나, Drag&Drop 계열의 경우 상위 Form으로 발생하지 않음.
Form의 Drag & Drop 관련 Event의 경우 해당 Event가 초기 설계 시에 위와 같은 사항을 고려하지 않고 설계되어 발생한 문제임.
대안
Drag & Drop 계열의 입력 이벤트의 경우, 해당 Component의 DropMode가 FALSE로 설정되면, Drop을 Form이 대신 받으므로 Component의 DropMode를 FALSE로 설정하는 것으로 전체적인 처리를 할 수 있음.
특정 Component에서 Drag & Drop을 받지 않고자 하는 경우 DropMdoe를 TRUE로 설정하고, 각 Drag & Drop의 이벤트 내에서 Return값을 “NONE”으로 주어 Drop을 받지 않겠다는 표시를 하는 것으로 처리할 수 있음.
DropMode를 TRUE로 준 상태에서 Form의 Drop과 같은 처리를 하고자 하는 경우, 별도로 구현하거나, Form의 Drag & Drop을 구현한 Event Handler를 함수형태로 호출 하여 사용할 수 있음.
MFC로 제작된 ActiveX 컴포넌트에 TrackpopupMenu 함수 사용 시 오류
현상
MFC로 제작된 ActiveX 컴포넌트 객체로 script에서 trackpopupMenu 함수의 objObject값으로 주고 호출시 모든 메뉴 item이 disable되는 현상
TrackPopupMenu(strDatasetID,strLevelColID,strMenuIDColID,strTextColID,strStatusColID,strImageColID,nXPos,nYPos,strCallBackFunc, objObject, nRow, nCell);
내부 작동원리는 다음과 같다
TrackPopupMenu 함수의 objObject는 이 objObject의 window handle로 popup menu를 생성하여 dataset의 정보대로 리스트를 나열하게 되는데, 이때 objObject의 child로 popup menu가 생성됨.
문제는 MFC ActiveX에서는 이 popup Menu item에 대해 enable/disable할수 있는 기능이 제공되지 않음으로 인해 문제가 발생하였음.
대안
Microsoft support : 해당 Error에 대한 Microsoft의 공식 입장을 적은 페이지.
이 자료를 참조하여 내부적으로 조치하여도 MFC application에서 이 MFC ActiveX컴포넌트를 삽입하여 trackpopup을 생성시켜도 enable되지 않음.
대안으로는 TrackPopupMenu의 objObject를 해당ActiveX객체로 주지 말고, form object를 대신하여 사용하고 좌표정보를 보정하여 사용할 수 있음.
TrackPopup menu에 대한 처리는 callback함수에서 처리하면 되므로 이상 없음.
MS internet Explorer에 MiplatformX를 embedded하여 사용할 때, 화면로딩 시 종종 늦어지는 현상 발생
현상
Ms Internet Explorer에 MIplatform ActiveX를 embedded하여 사용할 때, script에 idle함수를 이용하면 CPU가 100%되면서 늦어지는 현상, 매번 발생하는 현상이 아니며, 불특정 하게 늦어졌다, 빨라졌다 하는 현상이 나타남.
이 원인은 MS internet Explorer의 iframe화면과, miplatformX의 화면이 동시 로딩되는 경우에 특히 잘 발생되는 것으로 보임.
MIplatform의 idle함수는 내부적으로 window에 Message pump에 쌓여있는 message를 단순히 꺼내어, 강제로 메시지내용들을 수행시켜, 결과를 얻을 때 종종 사용하게 되는데, MS의 internet Explorer와 Message pump를 같이 사용할 경우, 메시지 수행을 강제로 수행 시 화면 로딩이 종종 늦어지는 현상이 나타나게 됨.
대안
전용 브라우저에서는 문제가 없으나, MS의 Internet Explorer에서는 idle 함수 사용 시 MS사의 internet Explorter에서 cpu 를 100% 사용하게 되면서, 잠시 멈춰지는 현상이 나타나게 됨.
이 문제는 문제발생시 thread를 확인해 본 결과이므로, 되도록 idle 함수를 사용하지 않음으로써 이 문제를 피할 수 있음.
idle 함수 사용은 좀 더 신중히 판단하여 사용할 것.
Tablet PC에서 MiPlatform 3.1 기동 시 CPU점유율이 100%되는 현상
현상
Tablet PC에서 MiPlatform 3.1 ™을 기동할 때, 간혹 또는 자주 CPU 점유율이 100%가 되면서 MiPlatform이 정상적으로 기동하지 못하는 현상이 나타남.
MiPlatform 3.1이 정상적으로 로딩 완료되지 못할 뿐 아니라, 시스템 전체에 속도를 저하시킨다. 따라서 MiPlatform을 강제 종료하게 됨.
다음 3가지 조건이 모두 만족할 때 증상이 나타나는 것으로 확인되었다.
Tablet PC이어야 한다.
초기 XML 등을 로딩할 때, Async 통신을 사용해야 한다.
Dock Bar의 Form의 OnLoadComplete에서 Alert/ Dialog/ Idle()등을 사용한다 (Message pump가 동작하는 모든 경우가 해당됨.)
Tablet PC의 IME에 ‘모든 프로그램에 고급 텍스트 서비스 지원 확장’ 옵션이 켜져 있어야 한다.
대안
다음 대안들 중에서 1가지를 조치하면 증상은 나타나지 않는다.
초기 통신을 sync방식으로 한다.
StartXML의 Protocol에 Sync=”true” 옵션을 주어 동기화(sync)방식으로 로딩한다.
단, 이 경우 일반적으로 통신으로 인해 프로그램이 동작 불능이 되는 경우를 방지하기 위해 로딩 완료 시점에서 다시 비동기(async)통신으로 방식으로 Protocol Adapter를 설정해야 한다.( global.프로토콜.sync = false의 형태로 설정할 수 있다)
초기 Dock Bar의 OnLoadCompleted이벤트가 완료되기 전에 idle(), Alert, Dialog()등을 사용하지 않도록 한다.
DockBar에 로딩되는 Form의 OnLoadCompleted가 Return되어 완료되기 전에 idle(), alert(), confirm(), Dialog() 등 OnLoadCompleted가 Return되지 못하도록 하면서, 새로운 창이 뜨지 않도록 한다 (Open과 같이 OnLoadCompleted가 바로 return되는 경우는 문제가 되지 않는다.)
Timer를 이용해 OnLoadComplete가 완료된 뒤에 동작하거나, Go를 이용해 다른 Form을 로드 한 경우에는 증상이 나타나지 않는 것으로 확인되었다.
Tablet PC의 IME에 ‘모든 프로그램에 고급 텍스트 서비스 지원 확장’ 옵션을 끈다.
Tablet PC의 IME에 ‘고급 텍스트 서비스를 모든 프로그램에 확장’ 옵션을 끄도록 사용자에게 안내한다. ‘모든 프로그램에 고급 텍스트 서비스 지원 확장’은 필기인식, 가상 키보드 등을 위해 존재하는 서비스 이다. ‘모든 프로그램에 고급 텍스트 서비스 지원 확장’옵션을 꺼도 별도의 필기인식, 키보드 창을 사용하여 입력할 수 있다.
‘모든 프로그램에 고급 텍스트 서비스 지원 확장’옵션을 끄는 방법.
1
다음과 같은 방법으로 IME의 설정 창을 연다.
아래 그림과 같이 IME의 오른쪽에 붙은 ‘▼’모양을 클릭해 나온 메뉴에서 ‘설정(E)’을 클릭한다.
2
다음과 같은 설정 창이 뜨면, ‘고급’ 탭을 선택한다.
3
‘모든 프로그램에 고급 텍스트 서비스 지원 확장’ 체크박스가 켜져 있으면 선택을 해제하고, ‘확인’을 누른다.
4
다음과 같은 메시지가 발생하면 ‘예’를 눌러 시스템을 다시 시작한다.
일부 Component의 Property가 해당 Component의 Event Handler에서만 실패하는 경우
현상
MiPlatform에서 기본제공되는 Component의 속성 중 일부 속성에 대해 해당 Component의 Event가 진행중인경우 변경이 제한되어 ‘~~프로퍼티 값 변경에 실패했습니다.’라는 메시지가 발생함.
제한된 Component와 속성 목록은 아래 표와 같다.
Component | Property |
---|---|
Combo | Editable |
TextArea | HScroll VScroll |
Calendar | MonthOnly |
변경이 제한된 Property는 해당 Component의 Event Handler내부에서 변경을 제한 한 것이며, 해당 Event Handler가 아니면 변경할 수 있다.
화면에 Combo1이라는 Combo가 있고, Combo1의 OnChagned 의 Event Handler가 Combo1_OnChanged라면 Combo1_OnChange와 Combo1_OnChanged에서 호출한 함수에서는 Combo1의 Editable을 바꿀 수 없다.
단, Combo0라는 Combo가 추가적으로 있는 경우 Combo1의 Event Handler에서 Combo0의 Editable을 변경 하는 데에는 제약이 없다.
위와 같은 제약을 한 이유는 위 표 에서 명시된 Property들의 경우 해당 Component의 Window를 재 생성 하는 과정이 변경 과정에 포함되기 때문이다. 따라서 해당 Event Handler 안에서 변경을 허용할 경우 MiPlatform의 동작이 비정상 종료될 수 있어 제한하였다.
대안
위의 Property들에 대해 동작 시에 변경해야 하는 경우, SetTimer를 통해 변경 시점을 해당 Event Handler가 처리를 완료한 다음에 Property를 변경하거나, 다른 Component의 Event Handler에서 표에 명기된 Property를 변경하도록 해야 한다.
Destroy Form API를 사용한 뒤 MiPlatform이 비정상 종료하는 현상
현상
Destroy Form API를 사용해 특정 Component를 파괴한 뒤 해당 MiPlatform이 비정상 종료하는 현상은 파괴된 Component에 대해 접근을 시도하기 때문에 MiPlatform이 죽는 현상으로 봐야 한다.
첫 번째 경우는 Event Handler의 obj를 통하거나, Object등을 사용하여 Component의 ID가 아닌 Object를 바로 접근하도록 작성된 Code중에 Destroy가 있는 경우 MiPlatform이 비정상 종료할 수 있다.
Function OnClick(obj)
{
Var obj_dead = Combo0;
Destory(obj_dead.id);
obj_dead.MoveWindow(0,0,100,100); <- 비정상 종료됨
}
두 번째 경우는 특정 Component의 Event Handler를 수행하는 도중 Destroy등을 사용해 Event를 발생한 Component가 파괴될 때 해당 증상이 나타날 수 있다. 이와 유사한 경우로, 특정 Component에서 자신을 포함하는 Form/Tab/Div의 Contents를 바꾼 경우와 같은 이유에서 MiPlatform이 비정상 종료될 수 있다. (단, 이 경우 Form/Tab/Div의 SyncContents 프로퍼티가 TRUE로 설정되어 있는 경우에만 발생한다.)
Function Combo0_OnChanged(obj)
{
Destroy(obj);
} <- 경우에 따라서 비정상 종료됨
대안
첫 번째 원인에 대해서는 Destroy를 사용한 다음에 해당 Component를 접근하지 않도록 스크립트를 수정해야 합니다. 혹은 다시 Component의 ID를 통해 해당 Component로 접근해도 위의 현상은 일어나지 않습니다.
Function OnClick(obj)
{
Var objid = “Combo0”;
Destory(objid);
Object(Objid).MoveWindow(0,0,100,100); <- 에러 발생 후 정상 진행됨
}
두 번째 원인에 대해서는 SycnContents의 사용을 자제해야 하며 Event Handler를 벗어난 시점에서 해당 Component가 파괴될 수 있도록 SetTimer등을 사용해 죽는 현상을 피해야 함.
Function Combo0_OnChanged(obj) { SetTimer(1,100); } Function Form_OnTimer(obj,nEventID) { If( nEventID == 1 ) { KillTimer( 1 ); Destroy( Combo0.id ); } }
TeeChart 사용 시 Form의 파괴와 함께 MiPlatform이 비정상 종료됨
현상
TeeChart를 사용하는 Form을 갱신 하거나, 다른 URL로 이동 시 MiPlatform이 비정상 종료되는 현상으로서 IE에서 사용 시 EIP레지스터가 0x00000000~0x0000000F사이에 있다.
주로 TeeChart가 있는 Form에 2번 이상 URL을 연속으로 변경하거나, Div를 복잡하게 사용하는 Form에서 동시에 여러 개의 URL을 변경하는 경우 발생하게 된다.
대안
원인은 TeeChart가 파괴되는 순간 Windows Message Pump를 강제로 수행하게 되며, 이 과정에서 MiPlatform의 Form파괴가 중복으로 발생하게 되어 MiPlatform에서 메모리 처리 오류가 발생하는 것으로 확인 되었다. 따라서 아래의 2가지 방법 중 한가지를 택하여 처리하면 된다.(QC 3563)
문제의 원인이 TeeChart에 있는 것으로 보이며, TeeChart를 사용하는 Form 이 파괴 또는 이동되는 시점에 해당 Form 또는 다른 Form에 대하여, URL을 연속으로 바꾸지 않도록 해야 한다.(Go/URL의 변경 등이 모두 해당된다.) 이를 위해 Form의 변경 시 URL을 1회 입력하고, 동일한 Form을 다시 로드 해야 하는 경우에는 Form의 Reload()메소드를 사용해야 한다.
위의 문제점이 TeeChart 6.0에서는 없는 것으로 확인 되었으므로 TeeChart 6.0을 대신 사용한다.
위의 문제점이 Tab Component 의 Border가 Flat 일 경우 발생하던 문제는 해결되었음.
ContoureCube 사용 시 알려진 버그
현상
전용브라우저 사용 시에는 문제가 없으나, IE에 MiplatformX를 embedding한경우에 발생하는 버그로, 최초 IE Browser를 구동하여 사용 시에는 문제가 없으나, open 또는 Dialog를 띄운창 에서 MiplatformX를 Embedding하고, 그 안에 ContoureCube를 사용 시 화면에 나타나지 않는 현상이 있음(ctrl-n key로 browser를 복제하여 생성시에도 안됨)
ContourCube 3.0.4.09 이후에는 XP에서는 위와 같은 문제가 나타나지 않게 수정되었음
Vista 의 IE에서 MiplatformX를 구동할 때 Cube 를 사용하는 경우 ThreadModel 충돌로 IE가 죽는 문제가 있음
대안
이 원인은 contoureCube사와 논의를 해보았으나, license 문제로 추측되며, 이 기능에 대해 정확한 답변을 contoureCube사가 주지 않고 있음.
위의 open,dialog안에서 ContoureCube를 사용할 경우에 안 나타나는 현상을 해결할 방안은 현재 없으며, Cube 컴포넌트는 브라우저를 사용할 것.
Vista 의 IE에서 죽는 문제는 ThreadModel 의 충돌에 기인한 것인데 Cube 쪽의 모델을 수정해야 한다는 Microsoft사의 답변을 받았으나 Cube 사에서 받아들이지 않아 부득이하게 강제로 registry 상의 cube 쓰레드 모델을 변경하게 하여 기존 사용자는 사용할 수 있게 함
그러나 추후 사이트에서는 사용할 수 없다고 대응할 것임
NewWindow(Ex) 함수 사용 시 알려진 버그
현상
MDI로 실행되는 경우 NewWindw(Ex)함수 사용 시 Minimize로 띄울 경우 Icon이 보이지 않을 수 있다.
MDI로 실행되는 경우 NewWindow(Ex)함수를 사용해서 새 window를 띄운다. 이때 Window를 Maximize, Normal, Minimize형태로 띄울지 설정할 수 있다. 이 중에서 Minimize형태로 Window를 띄울 때 Main화면 하단에 Minimize된 Window가 ICon형태로 표현된다. Minimize되었을 때 ICon정보는 화면 XML안의 Icon Property-> NewWindow(Ex) 함수 호출 시 첫 번째 인자에 해당하는 FormID에 설정된 IConID->ShortCuts의 Default ImageID순이다.
NewWindow(Ex)의 첫 번째 인자인 FormID가 StartXML의 Forms에 설정된 FormID가 아니고, shortCuts의 Defualt ImageID가 없을 경우에 화면 XML에 Icon Property가 있더라도Icon이 보이지 않는다.
일반적으로 Window가 Normal로 생성된 경우에 Window에 설정된 화면 XML안의 Icon Property에 값을 가져다가 Minimize가 되었을 때 ICon으로 표현해 주는데, Minimize로 Window를 생성하면 화면 XML을 Load하기 전에 이미 Window는 Minimize되어 버리므로 ICon정보를 얻어올 수 없어 ICon을 그릴 수 없다.
대안
보다 정확한 Icon을 주고 싶을 경우에는 NewWindow(Ex) 함수의 첫 번째 인자에 해당하는 FormID를 StartXML안의 Forms에 정의하고 IConID를 설정한다. ShortCuts의 ImageID에 Default Icon을 설정한다.
Vista에서 Aero Glass 테마 사용 시 MDI의 System Button을 타이틀 바에 그리지 못함
현상
Windows Vista 에서는 DWM(Desktop Window Management)라 하여 기존 테마와는 다른 형태의 UI 엔진이 탑재되었다. DWM의 가장 뚜렷한 효과는 Non-Client 영역의 반투명화다. Vista의 기본 테마인 Aero에 DWM이 적용된 반투명 효과가 더해진 테마를 Aero Glass 테마라고 한다. 이 기능을 활성화하기 위해선 그래픽 카드가 128MB 이상의 메모리, DirectX 9 지원, Pixel Shader 2.0 및 32bit 렌더링을 지원해야 한다.
MiPlatform을 전용 브라우저로 실행하고, MDI이며, 메뉴바가 없을 경우에, MDI창을 전체 화면으로 전환했을 때 MDI의 시스템 버튼이 타이틀 바에 위치하게 된다. Windows XP 이하의 OS에서는 이를 구현할 때 Non-Client 영역에 시스템 버튼을 자체적으로 그릴 수 있다.
반면, Windows Vista 는 Non-Client 영역을 DWM을 통하여 별도로 관리하여 Non-Client 영역에 그린 모든 것을 무효화한다. Microsoft는 Non-Client 영역에 컨트롤을 놓지 않고, 표준 Window Frame 을 사용할 것을 권장하고 있다.
대안
메뉴 바를 반드시 사용한다.
MDI의 Title Button을 표시하지 않도록 설정하고 사용자가 직접 MDI의 (Minimize/ Restore/ Maximize/ Close)에 대한 함수를 호출하는 MDI 제어부문을 작성한다.
Aero Glass 테마를 이용하지 않는다. Aero Basic 테마에서는 정상적으로 표시된다.
MiPlatform 3.2에서 버그 회피 방법 : 위의 상황이 나타나는 조건을 충족한 경우에는 DWM을 무효화 시킨 후에 브라우저를 띄우고 있다.
Division 또는 TabPage에서 Dialog나 Open 윈도우를 사용할 때 Parent가 되는 Division이나 TagPage 파괴 시 비정상종료
현상
Division 또는 TagPage에서 Dialog/ Open윈도우를 생성 후 어떠한 사유든 Division 또는 TabPage 파괴 시 대상 Dialog가 파괴된 Division 또는 TabPage를 참조함.
메모리가 해제된 객체 참조에 의한 오류 발생.
Division / TabPage의 파괴시점에서 소유한 Dialog / Open을 파괴할 경우 기존의 Dialog/ Open의 관리 코드와 충돌되며, 관리 코드 전체를 고칠 경우 소스의 안정성에 영향을 받음.
대안
Division / TabPage를 부모로 Dialog / Open을 사용하지 않는다.
기존의 정상적인 동작 코드를 수행하므로 안정적임.
추가적인 코드가 필요 없으므로 처리가 간편함.
공통 함수를 제작해 Div/ TabPage에서의 사용을 막을 수 있음.
Division / TabPage를 부모로 사용해야만 하는 경우 해당 Division/ Dialog 파괴전에 Dialog / Open을 닫는다.
Div / TabPage 단위로 독립적으로 개발할 수 있음
한글 입력시 Edit의 OnChar에서 PreText가 완성문자열로 출력됨
현상
Edit의 OnChar에서 PreText가 화면상에 보이는 완성 문자열로 출력됨.
Edit의 OnCharChanged가 우선적으로 발생하며, 이때 Edit의 Text프로퍼티가 이미 변경되어 PreText가 OnCharChanged에서 변경된 Text의 값으로 출력되어 발생하는 현상임.
수정 시 Edit의 PreText로 이미 구현된 기존 로직이 있을 경우 오류가 발생할 수 있어 차기 버전에서 수정하는 것으로 함.
대안
조합이전의 Text를 얻고자 할 때 OnCharChanged의 PreText를 사용 할 수 있다.
EnforcedIgnoreInput Property를 MS Internet Explorer에서 MiPlatformX를 임베디드해서 사용할 경우 사용 제한
현상
PID의 Project Manager->Attribute창의 EnforcedIgnoreInput Property를 True로 설정함
스크립트에서 SetWaitCursor(true); SetCapture(); 함수를 동시에 사용하면 WaitCursor가 계속 보이는 것이 정상적인 현상임
현재 창이 아닌 다른 창에서 작업을 하고 와도 WaitCursor가 계속 유지되어야 하나 MiPlatformX에서는 풀리는 현상이 있음
MiPlatform사용 시 발생하는 메시지와 MiPlatformX 사용 시 발생하는 메시지가 다르게 발생해서 생긴 문제로 현재 버전에서는 수정할 경우 오류가 생길 수 있음
대안
EnforcedIgnoreInput Property를 사용하는 경우는 대부분 조회 도중 재 조회를 막기 위해 사용하는 방법이므로 MS Internet Explorer에서 MiPlatformX를 직접 사용 시에는 다른 로직을 사용하도록 유도함
전용브라우저를 사용하면 이 문제를 피할 수 있음
Vista에서 Areo기능 사용 시 프린트 다이얼로그창이 사라지지 않고 남는 문제
현상
비스타의 에어로 기능 중 프린트다이얼로그가 늦게 사라지는 것이 있다. 다이얼로기가 다 사라지기 전에 화면을 캡쳐 하면 이러한 현상이 발생한다.
대안
SaveScreen으로 화면을 저장 후 출력
Open으로 폼을 열고 그 폼에서 Alert창을 띄운 후, 다른 창에서 그 Open된 창을 닫았을 때 비정상 종료됨
현상
Open명령으로 폼을 열고 그 폼에서 Alert창을 띄우더라도 다른 창을 마우스로 자유롭게 클릭할 수 있음.
이는 MFC로 샘플을 구성하여 테스트해도 동일한 현상이 일어나며, 이와 같은 현상을 피하기 위해서는 Dialog명령으로 폼을 열어야 함.
Alert창을 닫지 않은 상태에서 창을 닫을 경우 내부적으로 Parent, Child간 연결고리에 문제가 발생하여 비정상 종료가 일어나게 됨.
마이플랫폼에서 Alert은 쓰레드를 새로 생성하여 띄운 후 lock(Modal)을 거는 구조이며, Alert을 띄운 창을 닫았을 때 쓰레드가 어긋나는 현상이 발생 됨.
대안
Open으로 창을 열고 그곳에서 Alert명령을 사용하게 되면, 다른 창에 포커스를 이동할 수 있어 사용자가 언제든지 Open 창을 닫을 수 있으므로, Alert명령과 동일한 효과를 낼 수 있는 Dialog명령을 써서 해당 기능을 대체해야 함. 이때 사용자는 마우스로 다른 어떤 창도 클릭할 수 없으므로 비정상 종료는 일어나지 않음.
Alert 대신 Dialog명령을 사용하는 방법은 다음과 같음.
function Button1_OnClick(obj) { //alert("this is alert!); var msg = "this is alert!";//alert로 보여줄 문구 var xx = '<?xml version="1.0" encoding="euc-kr"?>'; xx += '<Window>'; xx += '<Form Id="test" Title="Alert" >'; xx += '<Static align="center" Bottom="30" Height="25" Id="IE0" Left="0" Right="10 0" Top="5" Width="100" Text="'; xx += msg; xx += '"/></Form></Window>'; Dialog(xx, "", 100, 50); //alert를 대체한 부분 }
Div의 스크롤 위에 다른 프로그램을 올려 놓은 후 스크롤을 시키면 마우스 이벤트가 작동하지 않음
현상
상단의 그림처럼 MiPlatform을 띄운 후 화면구성을 Div에 스크롤이 될 수 있도록 구성함.
Div 스크롤 부분에 다른 프로그램(그림에서는 계산기)을 올려 놓은 후(빨간 타원 부분처럼) 스크롤바를 하단으로 내리면 스크롤바가 진행되지 않고 화면이 멎는 것처럼 보임.
위와 같은 현상이 발생한 경우 키보드 이벤트는 발생하나 마우스 이벤트는 동작하지 않고 있음.
스크롤이 일어나는 순간에 테마가 적용되면서 비정상 동작이 일어나는 증상이나 테마 관련 대체 방안이 뚜렷이 밝혀지지 않고 있음.
해당 증상은 테마기능을 지원하는 윈도우에서만 일어나는 증상임.
대안
뚜렷한 대안이 없으므로 테마 관련 대체 방안이 나올 때 까지 상단과 같은 상황에서는 스크롤을 피해서 사용해야 함.
만약 부득이 스크롤을 한 경우라면 다른 프로그램을 선택하고 다시 MiPlatform을 선택하여(포커스를 다시 받게 함) 정상적인 상태로 되돌릴 수 있음.
Dataset 에서 Null/ Empty 구분 못하는 문제
현상
Dataset Method 사용 중 Null 값을 갖는 인자에 대한 정상적인 처리가 되지 않음.
Dataset Method중에서 몇 개의 함수가 Null/Empty 비교가 안 되는 관계로 문제가 있음
해당 함수 - FindRow() , FindRowAs() , FindRowNF(), FindRowNFAs()
이상의 함수에서 Null 을 사용할 경우 비정상 동작을 할 수 있다.
대안
Dataset 내부에서 Null / Empty 구분 및 비교 로직 변경
향후 버전업 시 적용 예정
Grid Cell Copy/Paste
현상
정확한 현상을 파악해 보면 MP3.2에서는 마우스클릭을 통해 Cell단위와 AreaSelect를 통한 Copy/Paste만은 지원함.
마우스를 통한 동작에 대한 부분에서만 Copy/Paste만을 제공하고 있습니다. 문제의 원인은 Grid의 Copy/Paste 는 component에서 제어를 하고 있음.
모든 컴포넌트에 공통적으로 적용되는 부분이며 Grid의 추가적인 처리가 필요한 기능 변경 및 추가 이슈임.
Grid 내부에서 따로 Copy/Paste관련해서 처리하는 부분은 AreaSelect 를 통한 Copy/Paste만을 제어하고 있음.
Keyborad를 통한 이동 후 Cell Copy시 정확한 동작을 하지 않음.
대안
MP3.2에서 적용하기 위해서는 Event 부분과 구현부의 재구성이 필요하며 다양한 케이스에 대한 테스트 필요함.
향후 추가적으로 지원할 예정임
ExcelExport시 Cell사이즈 문제
현상
SaveExcel 외 SaveExcelEx, ExportObject, ExportExcelEx 등 함수들은 Cell사이즈를 정확하게 표현할 수 없는 문제가 있음.
SaveExcel은 내부적으로 HTML로 저장하여 엑셀에서 오픈 하는 구조로 되어있으며, 그리드의 Cell사이즈(픽셀단위)를 HTML로 저장 후 오픈 하면, 엑셀에서 자동으로 설정 환경에 맞게 사이즈를 변환하여 표시하므로 정확한 사이즈를 표현할 수 있음.
그 외의 함수들은 엑셀을 직접 임베디드 하여 호출하는 구조로 되어있으며, 임베디드한 엑셀에서 셀 사이즈를 설정할 경우, 픽셀 값을 지원하지 않아 사이즈를 직접 계산하여 넘겨줌. 하지만, 엑셀의 환경정보를 얻어오는데 제한적이어서 정확한 사이즈 계산을 할 수 없음.
대안
정확한 사이즈로 출력해야 할 경우, SaveExcel을 사용할 것.
Grid SubProperty ImeMode 문제
현상
ImeMode = "native" 로 되어 있고 Cell Edit가 비활성화 되어있는 상태에서 한글 입력 시 첫 글자가 영문으로 입력되는 현상.
IME가 현재 영문이었을 때 Key를 누르면 Cell Edit가 비활성화 상태에서 Keydown 이벤트가 먼저 발생하고 그 이후, Cell Edit가 활성화 되면서 IME를 변경함.
위의 과정에서 Keydown 이벤트가 native로 바뀌기 전에 발생하므로, 첫 글자는 IME 변환 전 Key값으로 처리되는 문제임.
대안
Cell Edit 비활성화인 상태에서 먼저 활성화(Enter를 입력 등)처리를 한 후 사용.
일본어 확장한자 문제
현상
Edit, TextArea 내부 문장 중 일본어 확장한자가 포함된 경우 확장한자에 커서가 위치하게 되면 확장한자는 2Byte형태의 Unicode가 아닌 관계로 아래의 설명에서 표현된 상위대행과 하위대행으로 구분되어 2개의 문자로 분리되어 표시됨
세계표준기구(ISO)에서 정의한 확장한자는 유니코드 3.0부터 보충언어 판(Supplementary Planes)을 정의됨. 이를 위해 BMP(Basic Multilingual Plane)의 2,048자를 대행코드 영역(Surrogates)으로 할당하고 이중 1,024자를 상위대행(high surrogates), 1,024자를 하위대행(low surrogates)으로 정의하여 이 둘의 조합으로 다시 1백만여 자의 - 1024x1024=1048576 - 문자를 추가로 정의할 수 있도록 함. 유니코드 3.1부터는 실제로 이 영역에 문자를 정의함. 확장한자의 경우는 이 영역에 포함됨.
MiPlatform은 확장한자와 같은 Surrogate pair Character를 지원하지 않음.
대안
MiPlatform에서는 정상적인 동작을 보장하지 않음.
HTML화면의 IFrame에서 PopupDiv가 있는 창(폼)을 띄운 후 닫을 경우 IE브라우저가 맨 뒤로 숨는 문제
현상
HTML화면의 IFrame 안에서 PupupDiv가 있는 마이플랫폼 창(폼)을 띄운 후 닫았을 때 IE브라우저가 현재 띄워져 있는 창들의 맨 뒤로 숨는 현상이 랜덤 하게 발생 됨.
문제가 발견되는 상황
<iframe id="install_miplatform" …>
* window.open(HTML, "install_miplatform", …); // Iframe에 마이플랫폼 Updater가 있는 html페이지를 open. (이때 내부적으로 업데이터 -> 마이플랫폼 실행 -> PopupDiv를 추가한 화면(폼) open됨)
open된 마이플랫폼 화면 닫기.
IE브라우저가 랜덤 하게 맨 뒤로 숨는 현상 발견.
대안
위와 같은 조건일 경우의 대안은 없음.
Dialog를 띄운 상태에서 부모 창을 go로 변경시킨 후 Dialog창을 종료할 때 비정상 종료 문제
현상
Dialog 메소드를 통해 창을 띄운 후 부모 창에 해당하는 창을 go명령(혹은 url 변경)으로 변경시켰을 때 부모창의 로딩이 진행 중에 Dialog창을 종료하는 순간 비정상적으로 마이플랫폼이 종료됨.
이 현상이 발생하는 이유는 dialog로 창을 띄울 경우 모달창이 형성되어 모든 메시지 루프 처리를 모달창이 모두 담당하는 구조로 바뀌게 되어 아래와 같은 시나리오대로 동작하기 때문입니다.
부모창을 GO 명령을 통해 변경하게 되면 내부적으로 새로운 쓰레드가 생성됩니다.
새로운 쓰레드에서는 일련의 작업을 진행하게 되고 그 작업 결과를 처리하기 위해 메시지 루프 쪽으로 관련 메시지를 전달하게 됩니다.
이때 메시지를 처리하는 부분이 부모창이 아닌 모달창으로 전달이 되어 작업 중을 나타내는 wait 상태처리 등을 진행시키게 됩니다.
미처 통신이 완료되지 않은 상태일 경우 wait 상태처리를 계속 해 줘야 하는데 Dialog창을 닫아버리게 되면 wait 상태처리를 하기 위한 내부 자원 핸들값이 무효화되는 반면 메시지 루프에서의 처리는 계속 진행됩니다. 이 경우 시점차이로 인해 그 핸들값이 올바르지 않는 상태로 처리될 수도 있는데 이 상태에서 비정상 종료 현상이 발생됩니다.
대안
위와 같은 조건은 MFC 구조에서 메시지 처리를 하기 위한 동작과 모달창의 특성이 결부된 상황을 만들게 되므로 MFC 구조 기반인 마이플랫폼에서의 마땅한 대안이나 해결 방안을 찾지 못하고 있습니다. 현상을 발생시키는 조건(통신 완료 전에 모달창을 닫는 동작)를 피해서 사용해야 합니다.
MS office 365, 2016 버전의 2017년 03월 패치부터 엑셀 Export 결과물이 변형되는 현상
현상
MS office 365, 2016 버전을 사용하는 시스템에서 엑셀 export 결과물이 기존과 다른 모양으로 나타나는 현상입니다. 2017년 3월 이후의 패치 버전으로 업데이트 시 해당 현상이 나타납니다.
구체적인 현상은 아래와 같습니다.
오류 현상 | 처리 여부 |
---|---|
column width 가 반영되지 않음 | 엑스플랫폼 내부에서 보완, 수정 (2017년 5월 정기) |
font name, color, size 가 반영되지 않음 | 엑스플랫폼 내부에서 보완, 수정 (2017년 5월 정기) |
data가 없는 cell 이 나타나지 않음 | 엑스플랫폼 내부에서 보완, 수정 (2017년 6월 정기) |
cell align 이 반영되지 않음 | 보완 불가 |
merge 된 그리드를 출력 시 모양 변경 | 보완 불가 |
대안
현상이 발생하기 이전의 office 업데이트 버전(16.0.7870.2038)으로 다운그레이드합니다.
Windows 시작 버튼을 마우스 우측 버튼으로 클릭 후 실행을 선택합니다.
실행 창에 아래 내용을 복사 붙여넣기 후 확인을 누릅니다.
"C:\Program Files\Common Files\microsoft shared\ClickToRun\officec2rclient.exe" /update user updatetoversion=16.0.7870.2038
다운그레이드가 완료되면 문제가 해결되었는지 확인합니다.
하위 빌드로 다운그레이드하였기 때문에 재업데이트 시 같은 문제가 나타납니다. 엑셀 실행 후 [파일 - 계정 - 업데이트 사용 안 함] 설정을 통해 Office 업데이트를 해제하여 사용하시면 됩니다.