[연구] 리스트뷰에서 클릭과 마우스다운, 키업이벤트(ListView, MouseDown, KeyUp)

리스트뷰(ListView)에 항목을 표시하고나서 항목을 클릭함으로 관련 내용을 표시하는 경우가 많다. 예를 들면 메일 프로그램에서 건명(타이틀)을 선택하면 메일 본문을 표시하는 것이 그것이다.

리스트뷰 항목 클릭으로 하는 일

이러한 단순한 처리지만 어떤 이벤트 핸들러(Event Handler)에서 세부처리를 하는가에 따라 처리속도의 차이를 가져온다. 결국 처리속도의 차이가 전체의 성능과 사용자 경험(UX)에 영향을 준다.

대개는 리스트뷰의 항목클릭(ItemClick) 이벤트 프로시저에 세부처리를 할당한다. 그랬을 경우 마우스 클릭이 아닌 키보드의 화살표에 의해 리스트를 이동할 경우 연타에 의한 클릭발생이 화면 갱신 처리에 OS의 처리가 따라가지 못한다.

항목 클릭의 성능설계

이런 기본적인 처리라도 성능설계가 필요하다. 세부처리의 이벤트 핸들러는 마우스와 키보드의 두가지 경로를 고려해야 한다.

• 마우스처리: 마우스를 눌렀을 때 처리(MouseDown Event)
• 키보드처리: 키보드를 뗐을 때(KeyUp Event)

항목클릭이벤트 한가지로 표시를 제어하지 말고 마우스를 누를때 화면이 갱신되면 자연스럽게 변화를 감지할 수 있다. 그리고 마우스를 뗄 때보다 효과적이다. 왜냐하면 마우스를 눌렀을 때 바뀌어야 성능이 좋다고 느끼게 된다. 반대로 키보드는 계속 화살표를 누르고 있기 때문에 KeyUp에서 표시제어를 해야 성능이 개선된다. 이렇게 두가지의 경로를 가지므로 어느한쪽에 처리코드를 작성하는 것이 아니라 비표시용 컴포넌트(예를 들면 델파이의 TAction control)를 써서 이벤트를 연결하는 것이 편리하다. 

(돌미끄럼틀: 매끄러운 돌미끄럼틀은 아이들이 아주 좋아하는 놀이기구다. 만약 이 미끄럼틀이 최속강하곡선으로 만들어졌다면, 미끄럼은 기가막힌 놀이경험이 될 것이다. 물론 안전성도 생각해야겠지만.)

지금까지 본 대표적 예

  실제 소스코드가 어떻게 구현되어 있는지는 알수 없지만 썬더버드(ThunderBird)는 항목 클릭에서 메일본문처리를 하고 있어서 화살표에 의한 이동에 CPU사용율이 100%에 가깝게 올라간다. 그럼에도 불구하고 본문은 아무것도 안나온다. 이에 비해 에드맥스(EdMax)는 화살표 키보드를 떼야 본문이 표시되는 구조로 되어 있다. CPU 사용율도 올라가지 않고 본문표시가 아주 경쾌하다. 이외에도 에드맥스는 메일 표시가 빠르다는 장점이 있다. 썬더버드같은 좋은 프로그램도 성능설계에 좀더 고속 처리를 해주었으면 하는 바램이다.(이글을 쓰고나서 며칠후에  다시 확인해 본 결과 썬더버드도 버전이 올라가서 인지 개선되어 있었다.)

DirectInput에서의 클릭

Microsoft DirectX SDK를 이용한 어플리케이션에서는 때로 키보드 입력을 받아오는 경우가 있는데 Keydown은 쉽게 알아낼 수 있어도 KeyUp은 알아내기 어렵다. 사실은 KeyUp이 기본 디폴트로 되어 있기 때문이다. KeyBuffer && 0x80 이면 KeyDown이고 아니면 KeyUp이다. 그러나 클릭이라는 이벤트는 발생하지 않는다. 어떻게 해야할까? 대개의 RAD 툴이 그렇듯이 클릭이란 KeyDown -> KeyUp의 순서로 발생한 것을 하나의 클릭으로 처리하므로 이러한 로직을 구현해야 한다. DIK_NUMPAD1등의 클릭을 알아보고자 할 때 유용하다. 단 DirectInput에서는 KeyUp으로는 판단하기 어렵다. 항상 기본이 KeyUp이기 때문에 예상치 못한 결과를 가져오게 된다.