Kuix의 이벤트 처리 메커니즘 (모래판) 2

이로써 DoLayout의 강제 재레이아웃을 호출했다. Revalidate Assoon AsPossible의 비고에 따르면 이 함수는 개발자가 인터페이스를 강제로 리셋하는 것을 편리하게 하기 위해 제공한 것이다. Kuix 자체는 이 함수를 호출하지 않고 사용 장소가 바로 내가 만난 이 장면이다.솔루션은 다음과 같습니다.
 

	    	Kuix.getCanvas().revalidateAsSoonAsPossible();
	    	//     
			ScrollPane main=(ScrollPane)screen.getWidget("main");
			main.bestScrollToChild(screen.getWidget("selUserName"), false);	

 
사례2: 아래 상자의 버그
만약 아래 테두리 (choice) 를 사용하고 Kuix의 도배 메커니즘 (예:transition: slide (left);) 을 사용한다면그러면 드롭다운 상자의 버그를 쉽게 발견할 수 있고 시스템이 다운될 때 확인 키를 빨리 눌러서 드롭다운 상자를 팝업하고 선택할 수 있다. 그러면 몇 번 사용하지 않으면 인터페이스가 완전히 응답을 잃고 다운될 수 있다. 그리고 드롭다운 목록의 항목이 몇 가지 항목을 잃어버렸다.상기 버그를 일으킨 원인은 동기화 메커니즘이 부족하기 때문이다. 버튼을 입력할 때 Kuix는 키를 key Events에 저장하고 메시지 처리 라인의 처리를 기다리며 확인 키를 여러 번 입력하여 지난번 팝업/닫기 목록 창이 처리되지 않았고 메시지 처리 라인이 다시 목록을 조작하여 다운되는 현상이 발생한다. 가장 좋은 해결 방법은 바로 팝업 목록을 팝업할 때 동기화 메커니즘을 추가하는 것이다.그러나 우리는 버튼을 입력한 후에도 인터페이스가 천천히 여러 번 뜨고 닫히는 것을 원하지 않는다. 쉽게 말하면 캐시 입력 키가 필요하지 않기 때문에 아래의 해결 방안은 상술한 버그를 신속하게 해결할 수 있다.
 

	protected void processKeyEvent(byte type, int keyCode) {
		if (initialized) {
			
			int kuixKeyCode = adoptKeyCode(keyCode);
			
			// Intercept debugInfos key
			if (type == KuixConstants.KEY_RELEASED_EVENT_TYPE) {
				if ((debugInfosKuixKeyCode & kuixKeyCode) == kuixKeyCode) {
					debugInfosKeyCounter++;
					if (debugInfosKeyCounter >= 3) {
						initializer.processDebugInfosKeyEvent();
						debugInfosKeyCounter = 0;
					}
				} else {
					debugInfosKeyCounter = 0;
				}
			}
			
			// Add event to queue
			synchronized (this) {
				if(keyEvents.isEmpty()) //add by shappy
					keyEvents.addElement(new int[] { type, kuixKeyCode });
			}
			
		}
	}

만약 (keyEvents.isEmpty()) 는 키보드 이벤트가 처리되지 않았을 때 새 키보드 입력이 시스템에서 무시되는 것을 보장합니다.이론적으로 이런 코드는 입력을 잃어버릴 수 있다
키, 하지만 다행히 다수의 휴대전화에 키보드가 없고 쿠릭스도 문자를 직접 입력하는 것을 지원하지 않기 때문에 이렇게 하자.
첨부,choice의 키 처리 함수, 여기에는 동기화 메커니즘이 분명히 없습니다
 

	/* (non-Javadoc)
	 * @see org.kalmeo.kuix.widget.AbstractActionWidget#processActionEvent()
	 */
	public boolean processActionEvent() {
		Desktop desktop = Kuix.getCanvas().getDesktop();
		if (desktop != null) {
			
			if (lastSelectedRadioButton != null) {
				lastSelectedRadioButton.catchChildrenFrom(choiceContainer);
			}
			
			// Retrieve the owner screen instance
			ownerScreen = desktop.getCurrentScreen();
			
			// Keep the cleanUpWhenRemoved property value
			ownerScreenCleanUpWhenRemoved = ownerScreen.cleanUpWhenRemoved;
			ownerScreen.cleanUpWhenRemoved = false;
			
			desktop.setCurrentScreen(screen);
			
		}
		return super.processActionEvent();
	}

어떤 사람은choice가tabgroup에서야 상술한 문제가 발생한다고 말하지만 사실은 그렇지 않다. 적어도 나는tabgroup이 없는 ui에서 상술한 문제가 발생한 적이 있고 테스트하기 어렵지 않다. 주로transition의 도배 메커니즘이 팝업 창의 지연을 초래하여 문제가 발생한 것이다. 또한 팝업 창을 팝업한 후에 원래의 창으로 돌아가면choice의 선택 항목을 잃어버리는 상황이 발생한다.코드에서choice에 강제로 값을 부여하면 다음에choice를 제출할 수 있는 값을 얻을 수 있지만, 그렇지 않으면null일 수도 있습니다.
Kuix의 코드 프레임워크는 전체적으로 괜찮지만 작은 문제가 상당히 많다. 그는 원본을 개발한 테두리 가위이기 때문에 작가의 업데이트도 상당히 느리고 중국어에 대한 지원도 좋지 않다. 몇 달 동안 초보자에게 원본을 수정하거나 이해할 결심이 없으면 원본을 사용하지 말라고 조언했다.또한 그것의 몇 가지 문제를 열거한 것은 전부가 아니라 손으로 쓴 것일 뿐 해결하거나 완벽하게 해결하지 못한 문제이다.
1 choice의 길이가 한 페이지를 초과할 때 스크롤 바가 표시되지만, 팝업 목록에 현재 선택 항목이 자동으로 표시되지 않습니다
2 스크롤 바가 있고 인터페이스 길이가 한 페이지를 초과할 때 인터페이스의widget을 읽거나 조작할 때(많은 경우 목록을 읽거나 수정할 때) 인터페이스가 자동으로 끝까지 스크롤됩니다.
3 실제 테스트는 인터페이스에 있는 모든 글씨체가 같은 것 같다. j2me의 세 가지 크고 작은 글씨체를 사용할 수 있는 것이 아니라 wtk의 아날로그에서 볼 수 있다. 이것은 kuix가 중국어 글씨체에 대한 지원이 좋지 않은 것으로 의심된다.
4 인터페이스 정체 현상, 스레드로 서버에 연결하여 데이터를 읽을 때 처리 결과를 반환한 후 팝업하거나 인터페이스를 수정할 때 인터페이스 정체 현상이 나타날 수 있다. 임의의 버튼이나 마우스를 누르면 바로 회복할 수 있다. 그렇지 않으면 몇 초의 시간을 기다려야 한다. 이런 상황은 시뮬레이터에서 매우 드물고 실제 기기가 비교적 많다. 만나지 않은 사람은 내가 말한 상황을 이해하기 어려울 것이다. 테스트 판단은 스레드 동기화 문제로 인해 발생한 것이다.조회 과정이 느릴수록 뚜렷해진다(https채널로 암호화하면 이 현상이 더욱 뚜렷해지기 때문에) 당분간 완벽한 해결 방안이 없다.
5 Kuix는 직접 입력을 지원하지 않고 표준 입력 창을 팝업해야 한다. 이것은 소프트웨어의 기능에 영향을 주지 않는다. 그러나 가끔은 흥미진진하고kuix만 있는 것이 아니다. 사실 일부 소스 구성 요소 부분에서 이 문제를 해결해야 한다. 이것은 두 가지 문제를 해결해야 한다. 하나는 kuix의 레이아웃 문제(kuix의 인터페이스는 실행할 때 레이아웃된 것이기 때문에 서로 다른 해상도에 적응하는 문제를 해결할 수 있다). 그리고 하나는 입력법을 해결하는 것이다.너는 반드시 특수 문자를 받아야 할 뿐만 아니라, 한자도 받아야 할 뿐만 아니라, 손으로 쓴 입력도 지원하는 것이 가장 좋다. 이것은 큰 문제이다
6 스크롤 바 문제,kuix 스크롤 바는 기본적으로 세로로 되어 있지만, 사실 가로 스크롤 바도 지원하지만, 그 중 하나만 선택할 수 있다. 작가는 두 가지 방향의 스크롤 바를 동시에 지원하지 않는 것은 레이아웃의 결함과 관련이 있다.
7 로컬script를 지원하지 않는다.kuix는view를 독립적으로 열어서 사용자가 인터페이스를 작성하는 데 편리하지만 클라이언트의 스크립트 판단이 부족하다. 이것은 소프트웨어의 유연성을 제한한다. 예를 들어 내가 로그인하기 전에 사용자의 계정과 비밀번호가 비어 있지 않다는 것을 판단하고 사용자에게 프롬프트를 해야 하기 때문에 반드시 코드를 클라이언트에 써야 한다. 그래서 클라이언트의 스크립트 메커니즘을 도입해야 Kuix는 완벽한 마른 클라이언트 개발 구성 요소를 잃지 않는다. 또한,클라이언트 스크립트 기능을 결합할 때 봉인된 서버 연결 구성 요소를 제공하여 클라이언트의 호출을 편리하게 하는 것이 가장 좋다.
문제가 많지만 그중의 아주 작은 부분일 뿐입니다. Kuix를 공부하고 싶은 사람들을 놀라게 하지 않았으면 좋겠습니다. 나중에 그 중의 일부 문제를 해결할 시간이 있으면 제가 계속해서 블로그를 발표할 것입니다. 하지만 프로젝트가 많이 끝나지 않아서 다른 방향으로 갈 것 같습니다. 문제가 해결된 분은 답장을 해서 다른 독자들에게 참고해 주시기 바랍니다.(내 메일박스[email protected])