나는 PtInRect (마우스 위치가 프레임 컨트롤의 사각형에 대해 테스트되는 곳)과 함께 DrawFrameControl을 사용하여 컨트롤 (버튼과 같은)의 효과를 시뮬레이션하는 경우를 보았습니다. 왜 자식 창을 사용하는 대신이 작업을 원하십니까?PtInRect 대 자식 창
이 기술을 사용하는 예제는 this docking framework입니다. 도킹 창의 닫기 단추는 실제 창이 아닙니다.
내가 쓰고있는 응용 프로그램의 경우 목록보기 컨트롤을 사용하여 최대 1000 개의 항목을 보관할 수 있습니다. 각 항목에는 10 개의 버튼이 있습니다. 모든 단추는 사용자 지정 그리기입니다.
이 경우 PtInRect 메커니즘을 사용하는 것이 더 효율적 (빠른 방법)이라고 생각합니까?
각 프로세스의 프로세스는 limit of about 10,000 window handles입니다. 1,000 개의 항목 각각에 10 개의 버튼을위한 창을 만드는 것이 비효율적 일뿐만 아니라 반드시 가능하지는 않습니다.
질문에 대답하려면 : 네, 페인팅 및 히트 테스트를 통해 "가상"버튼을 만드는 것이 훨씬 더 좋은 해결책입니다.
별도의 하위 창을 사용하면 특정 오버 헤드가 발생합니다. 각 자식은 창 클래스, 스타일, 창 프로 시저, 위치, 스레드 소유 등의 고유 한 속성을 갖습니다. 이러한 많은 수의 자식을 관리해야하는 경우 시스템 자원을 낭비하는 대부분의 속성이 동일 할 것입니다. 또한 별도의 창으로 그들을 관리 할 어렵게 될 수 있습니다 :
당신은 그림이 글리치 알 수 있습니다. 각 창은 다른 창과는 다소 독립적으로 페인트합니다. 따라서 누군가가 다중 창 상단에 다른 창을 이동 한 다음 멀리 이동하면 사물을 구성하는 방법에 따라 백그라운드에서 불투명 한 중간 상태를 볼 수 있습니다. 아이들이 다시 칠하기 전에 각 어린이의 위치. CS_PARENTDC이 도움이 될 수 있습니다.
이러한 자식의 위치를 변경해야 할 때마다 DeferWindowPos 계열의 함수를 사용해야합니다. 그렇지 않으면 유사한 다시 그리기 문제가 발생합니다.
모든 어린이는 조작하기 위해 별도의 메시지가 필요합니다.
결국이 아이들을 시뮬레이션하는 것이 더 간단 할 수도 있습니다. 10000 개의 버튼을 목록보기 위에 놓으려고 시도하면 구현하기가 훨씬 어려워지고 위의 시각적 문제로 어려움을 겪을 것입니다. 소유자 그리기 목록보기 항목이있는 DrawFrameControl을 사용하면 시각적 결과가 더 좋고 구현이 더 쉬워집니다.
@arx가 지적한 것처럼, 만들 수있는 창 수에는 제한이 있습니다.