기고글 토론 "사용자 정의 그래픽 컨트롤. 파트 3. 양식"

[MetaQuotes]

새로운 기고글 사용자 정의 그래픽 컨트롤. 파트 3. 양식 가 게재되었습니다:

이것은 그래픽 컨트롤에 관한 세 가지 글 중 마지막입니다. 주요 그래픽 인터페이스 구성 요소 (양식)의 생성과 다른 컨트롤과 함께 사용하는 방법을 다룹니다. 양식 클래스 외에도 CFrame, CButton, CLabel 클래스가 컨트롤 라이브러리에 추가되었습니다.

이 양식은 여러 버튼 OBJ_BUTTON을 사용하는 그래픽 개체 "Rectangle Label" OBJ_RECTANGLE_LABEL을 기반으로 합니다. 시각적으로 양식은 양식 이름과 컨트롤 단추가 표시되는 양식의 상단 부분에 바가있는 사각형 (그림 1) 을 나타냅니다.

양식을 이동하는 버튼 (손 이미지 포함)이 왼쪽에 있으며 최소화 버튼 (사각형 이미지 포함)과 닫기 버튼 (십자 이미지 포함)이 오른쪽에 있습니다.

그림 1. 형태

양식을 이동하려면 이동 버튼 (버튼이 눌린 위치로 이동)을 누르고 양식을 이동할 차트의 아무 곳이나 클릭합니다. 결과적으로 이동 버튼이 해제되고 양식이 표시된 위치로 이동합니다 (왼쪽 상단 모서리가 클릭 한 지점에 위치합니다).

작성자: Dmitry Fedoseev

[Konstantin Gruzdev]

훌륭하고 유용한 작품입니다, 디미트리. 네 번째 부분에 대한 제안이 있습니다: "양식 마법사" 또는 "시각적 양식 편집기"에 대해 어떻게 생각하시나요?

[---]

존경합니다, 디미트리. 정말 수고 많으셨습니다.

다음 버전의 v4 클래스에 대한 몇 가지 비판을 받아들여주세요.

1. 기본 프로젝트에 추상화가 충분하지 않습니다. 각 컨트롤이 독립적인 단위로 작동한다는 것이 밝혀졌습니다. 따라서 예를 들어 배열로 결합할 수 없습니다.

2. 이제 요소의 각 클래스에는 대체로 고유한 함수 집합이 있습니다. 이것은 좋은 일이 아닙니다. 자손에서 함수가 간단히 재정의되는 공통 조상이 하나 있어야 합니다. 특히 현재 클래스에는 같은 이름을 가진 함수가 너무 많기 때문에 공통 조상을 만들지 못하는 이유는 무엇일까요?

3. 기본 클래스가 나타나면 이벤트 처리를 모두 외부에 두지 않고 자손 내부에 숨길 수 있습니다. 웹의 CSS와 유사하게 객체 내부에 이벤트의 캐스케이드를 만들 수 있습니다.

그러나 일반적으로 기사의 세 부분 모두 수상할 가치가 있으며 특히 버튼을 누를 때의 "넛지"와 요소의 상태에 따라 누름에 대한 대화 형 반응이 마음에 들었습니다.

추신.
그리고 여전히 완료 한 다단계 메뉴는 별도의 기사가 필요하지 않으며 새 기사를 작성하는 작은 작업에는 너무 뚱뚱합니다. v4 버전에서 업그레이드 만하자.
CTreeCtrl 트리 클래스는 MT 키트에서 제공되는 https://www.mql5.com/ko/articles/272 또는 CTreeNode 기사에서 가져올 수 있습니다.

[---]

Lizar:

훌륭하고 유용한 작품입니다, 디미트리. 네 번째 부분에 대한 제안이 있습니다: "양식 마법사" 또는 "시각적 양식 편집기"에 대해 어떻게 생각하시나요?

개인적으로 긍정적으로 생각합니다. 하지만 꼭 필요한 기능일까요? 비주얼은 객체 배치를 단순화할 뿐입니다. 제대로 한다면 생성된 객체에 대한 코드 생성, 변수 또는 클래스를 객체에 바인딩해야 합니다. 그리고 가장 중요한 것은 이벤트 처리입니다.

하지만 이러한 비추상 클래스에서는 이러한 작업을 수행할 수 없습니다. 매우 수동적입니다. 많은 곳에서 새로 생성된 객체와 그 처리를 직접 작성해야 합니다.
예를 들어 이벤트의 경우 Draw(기본 시스템) 및 OnDraw와 같이 시스템과 사용자로 구분되지 않고 사용자가 자체 드로잉으로 추가합니다.

다른 구조 (예 : Joomla!)에는 사용자 정의 함수 OnDraw가 하나만있는 것이 아닙니다. 그리고 그것은 두 가지로 나뉩니다 - BeforDraw와 AfterDraw. 즉, 프로그래머는 시스템 그리기 시작 전과 종료 후 모두 시스템 이벤트 EVENT_DRAW를 처리 할 수 있습니다.

[Dmitry Fedoseev]

sergeev:

존경합니다, 디미트리. 정말 수고 많으셨습니다.

다음 버전의 v4 클래스에 대한 몇 가지 비판을 받아들여주세요.

1. 기본 프로젝트에 추상화가 충분하지 않습니다. 각 컨트롤이 독립적인 단위로 작동한다는 것이 밝혀졌습니다. 따라서 예를 들어 배열로 결합할 수 없습니다.

2. 이제 요소의 각 클래스에는 대체로 고유한 함수 집합이 있습니다. 이것은 좋은 일이 아닙니다. 자손에서 함수가 간단히 재정의되는 공통 조상이 하나 있어야 합니다. 특히 현재 클래스에는 같은 이름을 가진 함수가 너무 많기 때문에 공통 조상을 만들지 못하는 이유는 무엇일까요?

3. 기본 클래스가 나타나면 이벤트 처리를 모두 외부에 두지 않고 자손 내부에 숨길 수 있습니다. 웹의 CSS와 유사하게 객체 내부에 이벤트의 캐스케이드를 만들 수 있습니다.

그러나 일반적으로 기사의 세 부분 모두 상을받을 가치가 있으며 특히 버튼을 누를 때의 "넛지"와 요소의 상태에 따라 누름에 대한 대화 형 반응이 마음에 들었습니다.

추신.
4. 여전히 완료 한 다단계 메뉴는 새 기사를 작성하기에는 너무 뚱뚱한 작은 작업에 대해 별도의 기사가 필요하지 않습니다.
CTreeCtrl 트리 클래스는 MT 키트에서 제공되는 https://www.mql5.com/ko/articles/272 또는 CTreeNode 기사에서 가져올 수 있습니다.

1- 단일 타입 컨트롤을 배열로 조립할 수 있습니다. 서로 다른 컨트롤을 하나의 배열로 모으는 이유는 무엇일까요?

2. 기본 클래스(모든 컨트롤에 하나씩)를 사용하는 경우 하위 클래스가 가질 수 있는 모든 메서드를 가져야 합니다. 독립 클래스를 사용하면 (개발 중) 메소드 드롭다운 목록에 실제로 클래스에 존재하는 메소드만 있습니다. 제 생각에는 이것이 매우 중요한 포인트입니다. 누군가 앉아서 세로 스크롤바에 대한 SetWidth() 메서드를 호출하려고 하는 모습을 상상할 수 있습니다.

두 번째 인수 - 기본 클래스와 하위 클래스가 있으면 모든 클래스에 주석이 달리고 문서에 구조화가 명확하지 않습니다.

저는 "눈을 감고" 사용할 수 있도록 기성 솔루션을 만들려고 노력합니다. 새 컨트롤을 만드는 프로세스의 속도를 높이려면 모든 필수 메서드가 포함된 템플릿을 사용할 수 있습니다.

3. 잘 이해가 되지 않습니다. 컨트롤에 다른 컨트롤이 있는 경우 해당 이벤트 처리가 숨겨집니다. 어쨌든 각 컨트롤에 대해 Event()를 호출해야 합니다.

4. 모르겠어요, 아마도... 메뉴 생성을 위해 특별히 설계된 나만의 클래스가 있는데, AddNode()를 호출 할 필요가없고 AddItem()이 호출되며 레벨은 항목 이름이 시작되는 공백 수에 따라 결정됩니다. 트리를 만드는 과정은 매우 명확합니다. 지금까지는 주석 및 키 컨트롤의 표시와 함께 작동합니다. 일반적으로 여러 개의 트리 메뉴를 만들 수 있습니다: 1) 드롭다운 탭이 있는 일반 메인 메뉴처럼, 2) 한 탭의 항목과 상단의 경로를 표시하거나, 3) 트리 표시(윈도 탐색기처럼)를 사용할 수 있습니다.

[Dmitry Fedoseev]

sergeev:

1. 개인적으로 긍정적으로 생각합니다. 하지만 꼭 필요할까요? 시각화는 객체 배치를 단순화할 뿐입니다. 제대로 한다면 생성된 객체에 대한 코드 생성, 변수 또는 클래스를 객체에 바인딩해야 합니다. 그리고 가장 중요한 것은 이벤트 처리입니다.

2. 그러나 이러한 비추상 클래스에서는 이 작업을 수행할 수 없습니다. 매우 수동적입니다. 예를 들어 이벤트의 경우 Draw (기본 시스템) 및 OnDraw (자체 그림이있는 사용자의 추가)와 같이 시스템과 사용자로 구분되지 않습니다.
.

다른 구조(예: Joomla!)에는 사용자 정의 함수 OnDraw가 하나만 있는 것이 아닙니다. 그리고 그것은 두 가지로 나뉩니다 - BeforDraw와 AfterDraw. 즉, 프로그래머는 시스템 그리기 시작 전과 종료 후 모두 시스템 이벤트 EVENT_DRAW를 처리 할 수 있습니다.

1. 컨트롤의 이벤트 처리를 위한 코드를 자동으로 생성하고 HScrollBar1_OnChange()와 같은 모든 컨트롤에 대한 이벤트 함수를 가져올 수 있습니다(....).

2. 아직 이벤트가 없는 경우, 예를 들어 값을 프로그래밍 방식으로 설정하면 사용자가 값을 입력할 때만 이벤트가 생성됩니다. 이 정도면 충분하며 추가 기능은 필요하지 않습니다. 그렇지 않으면 혼자서 프로그래밍을 배우는 사람에게는 이벤트가 넘쳐날 것입니다.

[Dmitry Fedoseev]

Lizar:

훌륭하고 유용한 작품입니다, 디미트리. 네 번째 부분에 대한 제안이 있습니다: "양식 마법사" 또는 "시각적 양식 편집기". 어떻게 생각하시나요?

긍정적입니다. 나는 이미 땀을 거의 흘리지 않고 무거운 포병없이 그것을하는 방법을 알아 냈습니다. 가까운 장래에 나는 휴가 중이고, 휴가가 끝나면 Rosh가 괜찮다면 가능할 것입니다.

[Sergey Pavlov]

Lizar:

... 4부에 대한 제안이 있습니다: "양식 마법사" 또는 "시각적 양식 편집기"에 대해 어떻게 생각하시나요?

"모든 것이 이미 우리 앞에 도난당했다"(작전 Y).

[---]

Integer:

1. 단일 유형의 컨트롤을 배열로 모을 수 있습니다. 여러 유형의 컨트롤을 하나의 배열로 모으는 이유는 무엇인가요?

모든 것을 하나의 루프로 가져와 이벤트 서비스에서 특정 유형을 제거하기 위해서입니다.

2. 기본 클래스(모든 컨트롤에 하나씩)를 사용하는 경우 모든 하위 클래스가 가질 수 있는 모든 메서드를 가져야 한다는 의미입니다. 독립 클래스를 사용하면 (개발 중) 메소드 드롭다운 목록에 실제로 클래스에 존재하는 메소드만 있습니다. 제 생각에는 이것이 매우 중요한 포인트입니다. 누군가 앉아서 세로 스크롤바에 대한 SetWidth() 메서드를 호출하려고 한다고 상상해 보세요.

기본 클래스의 모든 함수는 최소한의 일반적인 기능만 있는 빈 마개입니다. 누군가 무의식적으로 요소와 관련이 없는 함수를 호출하더라도 나쁜 일은 전혀 일어나지 않습니다. 이것이 바로 OOP의 힘입니다. 다형성.

두 번째 인수-모든 클래스는 기본 클래스와 서브 클래스가 있으면 문서에 그렇게 명백한 구조화가 없을 것입니다.

있을 것입니다. 단지 다를 것입니다 ... :)

[Dmitry Fedoseev]

sergeev:

1. 이벤트 서비스에서 모든 것을 하나의 루프로 통합하고 특정 유형을 제거합니다.

2. 요점은 기본 클래스에는 특정 동작의 함수가 구현되어 있지 않다는 것입니다. 기본 클래스의 모든 함수는 최소한의 일반 기능을 가진 빈 스토퍼입니다. 누군가 무의식적으로 요소에 대해 관련 없는 함수를 호출하더라도 전혀 나쁜 일이 일어나지 않습니다. 이것이 바로 OOP의 힘입니다. 하지만 다형성은 다릅니다.

3. 단지 다를 뿐입니다.... :)

1. 그게 다인가요? 포인트 2 - 메서드 덤프를 엉망으로 만들려고요?

대안:

1) 각 클래스에 대해 수동으로 Event () 호출을 추가해야하며 (마우스로 한 줄을 복사하고 포인트 왼쪽에있는 몇 글자를 변경하는 것으로 구성됨) 동시에 각 클래스의 메소드 목록에이 클래스에 해당하는 작업 메소드 만 있고 포인트를 클릭하면 목록이 팝업되고 모든 것이 명확 해집니다.

2) 모든 클래스의 Event() 자동 처리, 반면에 하나의 함수는 여전히 OnChartEvent()에서 호출해야 하고, 다른 한편으로는 목록의 메서드 덤프가 필요합니다. 또한 deinit에서 포인터를 파괴해야 합니다.

좀 더 자세히 살펴보면, 모든 Event()가 하나의 루프에서 처리되어야 하는 이유, 각 컨트롤에는 해당 Event()에 대한 자체 동작이 있어야 하며, 컨트롤은 값을 입력하고 화면에서 모든 것을 움직이고 깜박이게 할 뿐만 아니라 프로그램에서 입력된 값을 사용하기 위한 것이기도 합니다(주로).

3. 한 컨트롤의 메서드 중 절반은 문서의 한 곳에서, 나머지 절반은 다른 곳에서 읽어야 합니다.

[Mykola Demko]

Integer:

1. 그게 다인가요? 이를 위해 메서드 덤핑이라는 포인트 2를 엉망으로 만들려고요?

대안이 있습니다:

1) 각 클래스에 대해 이벤트 () 호출을 수동으로 추가해야하며 (마우스로 한 줄을 복사하고 포인트 왼쪽에있는 몇 글자를 변경하는 것으로 구성됨) 동시에 각 클래스의 메서드 목록에이 클래스에 해당하는 작업 메서드 만 있고 포인트를 클릭하면 목록이 떨어지고 모든 것이 명확 해집니다.

2) 모든 클래스의 Event() 자동 처리, 반면에 하나의 함수는 여전히 OnChartEvent()에서 호출해야하며 다른 한편으로는 목록에있는 메소드의 덤프가 필요합니다. 또한 deinit에서 포인터를 삭제해야 합니다.

좀 더 자세히 살펴보면, 모든 이벤트()가 하나의 루프에서 처리되어야 하는 이유, 각 컨트롤은 해당 이벤트()에 대한 자체 동작을 가져야 하며, 컨트롤은 값을 입력하고 화면에서 모든 것을 움직이고 깜박이게 할 뿐만 아니라 프로그램에서 입력된 값을 사용하기 위한 것이기도 합니다(주로).

3. 한 컨트롤의 메서드 중 절반은 문서의 한 곳에서, 나머지 절반은 다른 곳에서 읽어야 합니다.

당신은 모든 것을 올바르게 수행했습니다.

ME의 가능성을 감안할 때 전체 키치 시대의 일본 미니멀리즘은 매우 편리하며 모든 것이 거기에 있으며 불필요한 것은 없습니다.

객체를 반복하려는 사람들은 원하는 것을 쓸 수 있는 포스트픽스 셸을 구현할 수 있습니다.