일반적으로 PropGet/Set은 상속된 인터페이스를 처음에 알 수 없는 경우 템플릿 클래스로 작업하기 위한 좋은 메커니즘입니다.
그러나 토론을 원래 질문으로 돌아가고 싶습니다. 컨트롤의 색 구성표에 따라 프로그래머를 위한 "빠른 시작"을 만드는 방법은 무엇입니까?
그리고 기능적인 것(SetBgColor 또는 SetProp(Enum_Color, ) 등)이 아니라 보다 보편적인 속성 클래스를 구현할 수 있습니까? 모든 컨트롤이 하나의 범용 속성 클래스를 참조하지만 동시에 코더는 어떤 컨트롤이 어떤 색상을 사용하는지 쉽게 이해할 수 있습니다.
그러나 이 모든 것은 내 계획에 대한 내 추론입니다. 새로운 단계로의 전환을 시작하면 여전히 많이 바뀔 것이라는 점을 배제하지 않는다. 따라서 위에서 작성한 모든 내용은 여기서 논의된 주제의 틀 내에서 더 이상 관련이 없을 수 있습니다. )
여전히 만족스러운 결과로 개발해야 함) 더 많은 코더가 명확해지면 요소 클래스를 입력하기 위한 임계값이 낮아집니다.
예, 모든 옵션에 대해 중복됩니다. 그러나 이전 테마의 값을 다시 칠하고 변경하여 새 테마를 만드는 것이 편리합니다. Windows의 테마처럼.
추신
그리고 현재 주제에서 사용된 것과 다른 일부 값의 인코더에 의한 질량 변화에 대해서는 회의적입니다. Delphi 의 프로젝트 에서 그들이 가장 먼저 하려고 하는 것은 인터페이스를 고유한 색상으로 채색하고, 시스템 테마가 변경될 때 이후에 변경되지 않는 프로젝트를 상기시킵니다.
그리고 왜 어딘가에 스타일이 번져 있습니까? 기존 클래스 중 하나에서 테마 클래스를 상속하고 변경해야 하는 값만 재정의합니다.
친애하는 포럼 사용자 여러분, 저는 누군가의 의욕을 꺾고 싶지 않지만 제 생각에는 논의 중인 기술이 너무 복잡해서 공동의 이질적인 노력으로 구현할 수 없습니다. 우리 모두는 이해 수준, 전문성 및 접근 방식이 다르기 때문에 이러한 노력을 효과적으로 결합할 수 없을 것입니다. 우리는 또한 거리와 국가로 구분됩니다.
내 결론은 이 기술은 오랫동안 열심히 일한 고독한 개발자가 구현할 수 있다는 것입니다. 1년이 아닐 수도 있습니다. 하지만 이 사람은 이 기술을 크라우드소싱으로 만들지 않을 것입니다. 너무 많은 노력을 쏟고, 혼을 쏟고, 그저 이 일에 지쳐버렸기 때문입니다... 이것은 그의 프로젝트 이고 그는 그것을 무료로 배포하지 않을 권리가 있습니다. (처음에는 그럴 수도 있지만 항상 그런 것은 아닙니다).
1. 비트맵의 인터페이스가 빠릅니다. 너무 빨라서 시스템과 거의 구별할 수 없습니다. 예를 들어, 그라디언트를 사용하여 반투명 요소를 구현 했으며 이동하는 경우에도 색상 혼합을 고려하고 반투명 그라디언트가 있는 다른 개체의 알파 채널을 계산하여 눈에 보이는 지연 없이 부드럽게 렌더링됩니다.
2. 인터페이스는 확장 가능합니다. 응용 프로그램을 복잡하게 만들 수 있으며 많은 수의 그래프를 제거하고 생성하기 때문에 속도가 느려지지 않습니다. 사물. 다시 그리는 비용은 최소이며, 수천분의 1초에 그림을 교체하는 것입니다.
3. 기성 컨트롤을 생성하고 새로운 컨트롤을 생성할 수 있는 기능을 제공할 수 있습니다. 다음과 같이 고유한 이벤트 풀을 제공할 수 있습니다.
OnMouseDown - 누름 LMB
OnMouseUp - 누름 LMB
OnMouseHoverOn - 개체 위로 마우스를 가져갔습니다.
OnMouseHoverOut - 마우스 커서를 개체에서 멀리 이동했습니다.
OnMouseClick - 영향을 받는 개체의 경계 내에서 LMB를 눌렀다 뗍니다.
영향을 받는 개체 내에서 OnMouseDblClick 두 번 클릭 LMB
OnDragStart - LMB를 누른 상태에서 이동 시작 시 1회 발생하는 이벤트
OnDragMove - LMB로 이동하는 과정에서 발생하는 이벤트
OnDragEnd - LMB로 이동 후 발생하는 이벤트
OnPut - 객체가 다른 객체에 던져졌습니다.
OnGet - 다른 개체가 개체에 던져졌습니다.
OnFocus - 개체가 포커스를 받았습니다.
OnBlur - 개체가 초점을 잃었습니다.
OnResize - 개체의 크기가 변경되었습니다.
OnParentResize - 개체의 부모 크기가 변경되었습니다.
OnKeyPress - 키를 눌렀습니다.
OnChange - 필드 값이 변경됨
등.
당신은 다음에 대해 약간 과장하고 있습니다.
비트맵 그리기 속도는 크기에 따라 다릅니다. 부분을 다시 그릴 때 창을 나타내는 전체 비트맵을 다시 그리면 반응이 느려집니다(선택됨). 명백한 해결책은 부품 영역만 다시 그리는 것입니다.
그러나 창을 나타내는 비트맵의 일부만 다시 그리려면 비트맵의 디지털 마스크를 메모리(배열)에 저장해야 합니다. 다음으로 이 마스크를 탐색하고 원하는 세부 정보를 찾아야 합니다 . 그러나 많은 창이 있을 수 있습니다. 이제 모든 창의 마스크를 저장하는 데 필요한 메모리 양을 추정합니다... 기억할 창과 "잊을" 창, 그리고 시기를 선택하는 우선 순위 시스템을 생각해낼 수 있습니다. 그러나, 그것은 쉬운 문제가 아닙니다.
다시 그리기는 배열의 값을 다시 쓰는 것이며 1000000개의 값(창 이미지와 비트맵의 대략적인 픽셀 수)을 다시 써야 하는 경우 "1000분의 1초"가 아닙니다. 하지만 초. 따라서 - 창을 한 번만 완전히 그려서 메모리에 저장한 다음 이벤트에 저장해야 합니다. - 각 개체를 개별적으로 다시 그립니다. 그러면 속도가 매우 빨라집니다.
분명히 개별 개체만 구현했지만 창을 만들고 요소의 상호 작용을 구현해 보십시오. 당신은 내가 말하는 것을 이해할 것입니다.
언급한 이벤트의 경우 프로그램에서의 구현은 제어 그리기 기술과 관련이 없으며 모든 인터페이스에 있어야 합니다.
비트맵 그리기 속도는 크기에 따라 다릅니다. 부분을 다시 그릴 때 창을 나타내는 전체 비트맵을 다시 그리면 반응이 느려집니다(선택됨). 명백한 해결책은 부품 영역만 다시 그리는 것입니다.
그러나 창을 나타내는 비트맵의 일부만 다시 그리려면 비트맵의 디지털 마스크를 메모리(배열)에 저장해야 합니다. 다음으로 이 마스크를 탐색하고 원하는 세부 정보를 찾아야 합니다 . 그러나 많은 창이 있을 수 있습니다. 이제 모든 창의 마스크를 저장하는 데 필요한 메모리 양을 추정합니다... 기억할 창과 "잊을" 창, 그리고 시기를 선택하는 우선 순위 시스템을 생각해낼 수 있습니다. 그러나, 그것은 쉬운 문제가 아닙니다.
다시 그리기는 배열의 값을 다시 쓰는 것이며 1000000개의 값(창 이미지와 비트맵의 대략적인 픽셀 수)을 다시 써야 하는 경우 "1000분의 1초"가 아닙니다. 하지만 초. 따라서 - 창을 한 번만 완전히 그려서 메모리에 저장한 다음 이벤트에 저장해야 합니다. - 각 개체를 개별적으로 다시 그립니다. 그러면 속도가 매우 빨라집니다.
분명히 개별 개체만 구현했지만 창을 만들고 요소의 상호 작용을 구현해 보십시오. 당신은 내가 말하는 것을 이해하게 될 것입니다.
언급한 이벤트의 경우 프로그램에서의 구현은 제어 그리기 기술과 관련이 없으며 모든 인터페이스에 있어야 합니다.
약간의 설명을 드리고 싶습니다.
먼저 모든 요소가 포함된 디지털 창 마스크를 만듭니다. 그런 다음 ResourceCreate()를 사용하여 비트맵을 만듭니다. 차트에 창이 있습니다.
다음으로 이 창의 인터페이스 위로 마우스를 이동 하고 요소(_Object_Pointed)에 대한 hover 이벤트를 포착합니다 .
나는 객체 상호 작용을 구현하기 위한 2가지 접근 방식을 설명할 것입니다. 하나는 나쁘고 다른 하나는 더 좋습니다.
1. 창의 디지털 마스크가 첫 번째 생성 후 배열에 저장 되지 않은 경우 이 창 그림의 일부 세부 사항을 변경하려면 완전히 다시 만들어야 합니다. 즉, 건설을 다시 디지털화하는 것입니다. ResourceCreate()에 전달하려면 모든 창 세부 정보의 픽셀 색상 값으로 배열을 초기화 해야 하기 때문에 이 작업 자체에 시간이 걸립니다. 창이 크고 세부 사항이 많을수록 시간이 더 오래 걸립니다(약 250밀리초에서 2초). 그리고 각 요소의 각 이벤트에 대해. 이 변형은 결함이 너무 많습니다.
2. 디지털 마스크가 배열에 저장된 경우 이 창의 특정 세부 사항과 관련된 값만 다시 초기화해야 합니다. 배열에서 이 부분을 찾아 값을 덮어씁니다. 다음으로 배열을 ResourceCreate()에 보내고 즉시 결과를 얻습니다.
(1) 속성 및 값 또는 (2) 속성, 수정자 및 값을 설정하려는 ElementSet .
예, 컨트롤의 속성에 액세스하는 프레임워크 내에서 보편적입니다.
일반적으로 PropGet/Set은 상속된 인터페이스를 처음에 알 수 없는 경우 템플릿 클래스로 작업하기 위한 좋은 메커니즘입니다.
그러나 토론을 원래 질문으로 돌아가고 싶습니다. 컨트롤의 색 구성표에 따라 프로그래머를 위한 "빠른 시작"을 만드는 방법은 무엇입니까?
그리고 기능적인 것(SetBgColor 또는 SetProp(Enum_Color, ) 등)이 아니라 보다 보편적인 속성 클래스를 구현할 수 있습니까?
모든 컨트롤이 하나의 범용 속성 클래스를 참조하지만 동시에 코더는 어떤 컨트롤이 어떤 색상을 사용하는지 쉽게 이해할 수 있습니다.
그러나 이 모든 것은 내 계획에 대한 내 추론입니다. 새로운 단계로의 전환을 시작하면 여전히 많이 바뀔 것이라는 점을 배제하지 않는다. 따라서 위에서 작성한 모든 내용은 여기서 논의된 주제의 틀 내에서 더 이상 관련이 없을 수 있습니다. )
원칙적으로 어떤 색상이 있고 무엇을 변경할 수 있는지 명확하다는 데 동의합니다.
그런 질문 - 테마는 사용하지 않는 매개변수의 중복성을 의미합니까?
예, 모든 옵션에 대해 중복됩니다. 그러나 이전 테마의 값을 다시 칠하고 변경하여 새 테마를 만드는 것이 편리합니다. Windows의 테마처럼.
추신
그리고 현재 주제에서 사용된 것과 다른 일부 값의 인코더에 의한 질량 변화에 대해서는 회의적입니다. Delphi 의 프로젝트 에서 그들이 가장 먼저 하려고 하는 것은 인터페이스를 고유한 색상으로 채색하고, 시스템 테마가 변경될 때 이후에 변경되지 않는 프로젝트를 상기시킵니다.
그리고 왜 어딘가에 스타일이 번져 있습니까? 기존 클래스 중 하나에서 테마 클래스를 상속하고 변경해야 하는 값만 재정의합니다.
그런 CSS 기술이 있습니다
1) 알려지고 잘 문서화됨
2) 친숙하고 보편적인
3) 원칙적으로 태그 == 제어하므로 작업에 적합합니다.
시도하면 의도한 대로 작동해야 합니다.
그런 CSS 기술이 있습니다
그럼 바로 LESS/SCSS(SASS)를 살펴보세요.
그럼 바로 LESS/SCSS(SASS)를 살펴보세요.
휴, 황토는 겉보기에는 좋은데 그 기능은 필요하지 않습니다. 통역사를 만들지 마십시오.
우리는 순전히 계단식으로 스타일을 구축하고 재정의한다는 원칙을 선택적으로 ^ 포인트별로 적용합니다.
그리고 반응형 디자인(해상도가 다른 디자인)의 가능성을 반드시 놓으십시오. CSS의 미디어 쿼리 보기
또한 일부 부품은 고정된 치수를 가질 수 있지만 다른 부품은 사용 가능한 거리만큼 늘어납니다.
친애하는 포럼 사용자 여러분, 저는 누군가의 의욕을 꺾고 싶지 않지만 제 생각에는 논의 중인 기술이 너무 복잡해서 공동의 이질적인 노력으로 구현할 수 없습니다. 우리 모두는 이해 수준, 전문성 및 접근 방식이 다르기 때문에 이러한 노력을 효과적으로 결합할 수 없을 것입니다. 우리는 또한 거리와 국가로 구분됩니다.
내 결론은 이 기술은 오랫동안 열심히 일한 고독한 개발자가 구현할 수 있다는 것입니다. 1년이 아닐 수도 있습니다. 하지만 이 사람은 이 기술을 크라우드소싱으로 만들지 않을 것입니다. 너무 많은 노력을 쏟고, 혼을 쏟고, 그저 이 일에 지쳐버렸기 때문입니다... 이것은 그의 프로젝트 이고 그는 그것을 무료로 배포하지 않을 권리가 있습니다. (처음에는 그럴 수도 있지만 항상 그런 것은 아닙니다).
이 기술은 이미 MQL에 구현되어 있다고 생각합니다.
추신 그렇더라도 다시 구현하려고 하지 않는 이유는 무엇입니까? ))
이것이 유용한 이유:
1. 비트맵의 인터페이스가 빠릅니다. 너무 빨라서 시스템과 거의 구별할 수 없습니다. 예를 들어, 그라디언트를 사용하여 반투명 요소를 구현 했으며 이동하는 경우에도 색상 혼합을 고려하고 반투명 그라디언트가 있는 다른 개체의 알파 채널을 계산하여 눈에 보이는 지연 없이 부드럽게 렌더링됩니다.
2. 인터페이스는 확장 가능합니다. 응용 프로그램을 복잡하게 만들 수 있으며 많은 수의 그래프를 제거하고 생성하기 때문에 속도가 느려지지 않습니다. 사물. 다시 그리는 비용은 최소이며, 수천분의 1초에 그림을 교체하는 것입니다.
3. 기성 컨트롤을 생성하고 새로운 컨트롤을 생성할 수 있는 기능을 제공할 수 있습니다. 다음과 같이 고유한 이벤트 풀을 제공할 수 있습니다.
OnMouseDown - 누름 LMB
OnMouseUp - 누름 LMB
OnMouseHoverOn - 개체 위로 마우스를 가져갔습니다.
OnMouseHoverOut - 마우스 커서를 개체에서 멀리 이동했습니다.
OnMouseClick - 영향을 받는 개체의 경계 내에서 LMB를 눌렀다 뗍니다.
영향을 받는 개체 내에서 OnMouseDblClick 두 번 클릭 LMB
OnDragStart - LMB를 누른 상태에서 이동 시작 시 1회 발생하는 이벤트
OnDragMove - LMB로 이동하는 과정에서 발생하는 이벤트
OnDragEnd - LMB로 이동 후 발생하는 이벤트
OnPut - 객체가 다른 객체에 던져졌습니다.
OnGet - 다른 개체가 개체에 던져졌습니다.
OnFocus - 개체가 포커스를 받았습니다.
OnBlur - 개체가 초점을 잃었습니다.
OnResize - 개체의 크기가 변경되었습니다.
OnParentResize - 개체의 부모 크기가 변경되었습니다.
OnKeyPress - 키를 눌렀습니다.
OnChange - 필드 값이 변경됨
등.
당신은 다음에 대해 약간 과장하고 있습니다.
비트맵 그리기 속도는 크기에 따라 다릅니다. 부분을 다시 그릴 때 창을 나타내는 전체 비트맵을 다시 그리면 반응이 느려집니다(선택됨). 명백한 해결책은 부품 영역만 다시 그리는 것입니다.
그러나 창을 나타내는 비트맵의 일부만 다시 그리려면 비트맵의 디지털 마스크를 메모리(배열)에 저장해야 합니다. 다음으로 이 마스크를 탐색하고 원하는 세부 정보를 찾아야 합니다 . 그러나 많은 창이 있을 수 있습니다. 이제 모든 창의 마스크를 저장하는 데 필요한 메모리 양을 추정합니다... 기억할 창과 "잊을" 창, 그리고 시기를 선택하는 우선 순위 시스템을 생각해낼 수 있습니다. 그러나, 그것은 쉬운 문제가 아닙니다.
다시 그리기는 배열의 값을 다시 쓰는 것이며 1000000개의 값(창 이미지와 비트맵의 대략적인 픽셀 수)을 다시 써야 하는 경우 "1000분의 1초"가 아닙니다. 하지만 초. 따라서 - 창을 한 번만 완전히 그려서 메모리에 저장한 다음 이벤트에 저장해야 합니다. - 각 개체를 개별적으로 다시 그립니다. 그러면 속도가 매우 빨라집니다.
분명히 개별 개체만 구현했지만 창을 만들고 요소의 상호 작용을 구현해 보십시오. 당신은 내가 말하는 것을 이해할 것입니다.
언급한 이벤트의 경우 프로그램에서의 구현은 제어 그리기 기술과 관련이 없으며 모든 인터페이스에 있어야 합니다.
...
분명히 개별 개체만 구현했지만 창을 만들고 요소의 상호 작용을 구현해 보십시오. 당신은 내가 말하는 것을 이해하게 될 것입니다.
...
당신은 다음에 대해 약간 과장하고 있습니다.
비트맵 그리기 속도는 크기에 따라 다릅니다. 부분을 다시 그릴 때 창을 나타내는 전체 비트맵을 다시 그리면 반응이 느려집니다(선택됨). 명백한 해결책은 부품 영역만 다시 그리는 것입니다.
그러나 창을 나타내는 비트맵의 일부만 다시 그리려면 비트맵의 디지털 마스크를 메모리(배열)에 저장해야 합니다. 다음으로 이 마스크를 탐색하고 원하는 세부 정보를 찾아야 합니다 . 그러나 많은 창이 있을 수 있습니다. 이제 모든 창의 마스크를 저장하는 데 필요한 메모리 양을 추정합니다... 기억할 창과 "잊을" 창, 그리고 시기를 선택하는 우선 순위 시스템을 생각해낼 수 있습니다. 그러나, 그것은 쉬운 문제가 아닙니다.
다시 그리기는 배열의 값을 다시 쓰는 것이며 1000000개의 값(창 이미지와 비트맵의 대략적인 픽셀 수)을 다시 써야 하는 경우 "1000분의 1초"가 아닙니다. 하지만 초. 따라서 - 창을 한 번만 완전히 그려서 메모리에 저장한 다음 이벤트에 저장해야 합니다. - 각 개체를 개별적으로 다시 그립니다. 그러면 속도가 매우 빨라집니다.
분명히 개별 개체만 구현했지만 창을 만들고 요소의 상호 작용을 구현해 보십시오. 당신은 내가 말하는 것을 이해하게 될 것입니다.
언급한 이벤트의 경우 프로그램에서의 구현은 제어 그리기 기술과 관련이 없으며 모든 인터페이스에 있어야 합니다.
약간의 설명을 드리고 싶습니다.
먼저 모든 요소가 포함된 디지털 창 마스크를 만듭니다. 그런 다음 ResourceCreate()를 사용하여 비트맵을 만듭니다. 차트에 창이 있습니다.
다음으로 이 창의 인터페이스 위로 마우스를 이동 하고 요소(_Object_Pointed)에 대한 hover 이벤트를 포착합니다 .
나는 객체 상호 작용을 구현하기 위한 2가지 접근 방식을 설명할 것입니다. 하나는 나쁘고 다른 하나는 더 좋습니다.
1. 창의 디지털 마스크가 첫 번째 생성 후 배열에 저장 되지 않은 경우 이 창 그림의 일부 세부 사항을 변경하려면 완전히 다시 만들어야 합니다. 즉, 건설을 다시 디지털화하는 것입니다. ResourceCreate()에 전달하려면 모든 창 세부 정보의 픽셀 색상 값으로 배열을 초기화 해야 하기 때문에 이 작업 자체에 시간이 걸립니다. 창이 크고 세부 사항이 많을수록 시간이 더 오래 걸립니다(약 250밀리초에서 2초). 그리고 각 요소의 각 이벤트에 대해. 이 변형은 결함이 너무 많습니다.
2. 디지털 마스크가 배열에 저장된 경우 이 창의 특정 세부 사항과 관련된 값만 다시 초기화해야 합니다. 배열에서 이 부분을 찾아 값을 덮어씁니다. 다음으로 배열을 ResourceCreate()에 보내고 즉시 결과를 얻습니다.
그것이 실제로 전체 기술입니다. 거의))