Реter Konow : 바꾸어 말하면, 내가 한 부분을 수행하고 두 번째 부분이 있다는 사실에도 불구하고 결국 인터페이스가 있는 한 명의 고문이 있게 될 것입니다. 두 부분을 하나의 Expert Advisor로 결합하는 것은 나쁘지 않습니다.
하지만, 당신은 다른 방법으로 갈 수 있습니다. 생성자를 게시하고 내 도움으로 필요한 GUI를 디자인할 것입니다. 그런 다음 코어를 인쇄하여 인에이블러를 통해 어드바이저에 연결된 엔진에 삽입합니다. 이것은 마크업 언어로 그래픽을 작성하는 방법을 즉시 배우고 직접 수정할 수 있기 때문에 더욱 좋습니다.
음, 캔버스 자체는 이벤트에 반응하지 않습니다. 그리고 각 픽셀을 변경할 수 있다는 사실은 이미 명확합니다.
나는 조각난 캔버스 다시 그리기의 구현에 관심이 있었습니다.
그러나 분명히 많은 사람들이 캔버스에 작은 부분, 즉 하나의 컨트롤만 다시 그려야 하는 경우에도 캔버스를 완전히 다시 그리기로 결정했습니다.
캔버스 자체는 이벤트에 반응하지 않지만 자체적으로 존재하지 않습니다.
단편적인 다시 그리기 - 시작할 가치가 있으며 그러한 목표가 있는지 명확해질 것입니다. 컨트롤 의 배열이 있어야 한다고 생각합니다. 각 컨트롤에는 테두리가 정의되어 있습니다. 일부 컨트롤을 다시 그릴 필요가 있을 때 모든 컨트롤을 살펴보고 여전히 이 영역에 속하는 컨트롤을 확인하고 다시 그려야 합니다. 비록 그렇다 하더라도.
단편적인 다시 그리기 - 시작할 가치가 있으며 그러한 목표가 있는지 명확해질 것입니다. 컨트롤의 배열이 있어야 한다고 생각합니다. 각 컨트롤에는 테두리가 정의되어 있습니다. 일부 컨트롤을 다시 그릴 필요가 있을 때 모든 컨트롤을 살펴보고 여전히 이 영역에 속하는 컨트롤을 확인하고 다시 그려야 합니다. 비록 그렇다 하더라도.
그것이 바로 내가 만든 방법입니다. 원칙적으로 나는 이벤트 전송의 순간과 다른 몇 가지 포인트가 잘 작동하기 때문에 표준 라이브러리 를 기본으로 사용했습니다. Anatoly는 요소의 서로 다른 각 클래스에 대한 그룹화를 생성하지만 표준 요소에서는 모든 것이 단일 기본 개체로 축소됩니다.
결과적으로 WndObject에는 모든 컨트롤의 가장 일반적인 속성(크기, 위치, 배경색, 테두리 색상, 테두리 두께, 텍스트, 그림 등)에 대한 완전한 설명이 포함되어 있습니다. 또한 동일한 클래스에 부모 컨트롤에 대한 참조가 포함되어 있습니다. 즉, 요소에 대해 부모가 지정되지 않은 경우 차트에 자체 캔버스 개체를 만들고 그렇지 않으면 부모 캔버스에 그려집니다. 위치(독립, 종속)에 따라 요소 위치의 좌표도 계산됩니다. 또한 동일한 개체에는 이 요소가 차지하는 상위 영역에 대한 초기 설명이 포함된 배열이 있습니다. 아이디어 자체는 다음과 같습니다. 요소 자체만 변경되면 그리기 전에 픽셀 영역이 부모의 픽셀 매트릭스로 채워지고 컨트롤의 새 상태가 적용됩니다. 이 접근 방식을 사용하면 다시 그리기가 배열의 모든 요소를 순회하고 중첩 요소를 사용하여 재귀적으로 수행되기 때문에 매번 전체 캔버스를 다시 그릴 필요가 없습니다. 특정 컨트롤을 그리고 업데이트하기 위해 두 가지 기능이 가정됩니다. 하나는 전체 컨트롤을 생성할 때 부모(또는 빈 캔버스) 위에 요소를 그리고, 두 번째는 지정된 컨트롤의 표시만 업데이트합니다. 글쎄, 이런 것.
이벤트 모델에서 "잃어버린" 동안: 변경 후 어떤 레이어를 다시 그려야 하는지.
Nikolai는 그의 예에서 원칙적으로 로컬 영역 데이터를 저장하는 데 신경쓰지 않아야 함을 보여줍니다. 전체 캔버스를 다시 그리는 작업이 너무 빨라서 아래로 내려갈 필요가 없고 세부 사항이 필요하지 않기 때문에 항상 모든 것을 한 번에 다시 그리는 것으로 충분하기 때문입니다.
Стандартная библиотека MQL5 написана на языке MQL5 и предназначена для облегчения написания программ (индикаторов, скриптов, экспертов) конечным пользователям. Библиотека обеспечивает удобный доступ к большинству внутренних функций MQL5.
바꾸어 말하면, 내가 한 부분을 수행하고 두 번째 부분이 있다는 사실에도 불구하고 결국 인터페이스가 있는 한 명의 고문이 있게 될 것입니다. 두 부분을 하나의 Expert Advisor로 결합하는 것은 나쁘지 않습니다.
일반적으로 그렇게 할 것입니다. 나는 생성자를 게시하고 그것에 GUI를 디자인하는 방법을 가르칠 것입니다. 아직 문서가 없으므로 관심이 있는 경우 자습서를 따르십시오.
수락!
영상은 안찍었지만 예시를 올려봅니다. 빠르게 스케치했다.
600개의 드롭다운 목록이 있습니다.
마우스 이동 - 각 이벤트 및 색상 변경과 함께 일반 CCanvas가 다시 그려집니다. 그 상호 작용을 얻으십시오.
비트맵 속성에서 최종 크기(1500x600픽셀)를 볼 수 있습니다(800x500 및 250ms 지연과 비교). 이는 900,000포인트와 동일하며 모든 것이 즉시 다시 그려집니다. 몇 초의 이야기가 있을 수 없습니다.
각 목록은 먼저 자체 캔버스에 고유한 크기로 그려지고(경계를 넘지 않도록) 그런 다음 일반 목록에만 적용됩니다. 즉, 각 마우스 이벤트에 대해 600개의 ResourceCreate 호출 이 있습니다.
즉, 반응 속도에서 알 수 있듯이 표시할 프레임과 만화가 충분합니다.
MT 개발자는 브레이크 없이 만족스러운 도구를 제공했습니다(ResourceCreate 비트맵을 말하는 것입니다)
오픈 소스에서 이 예를 볼 수 있습니까?
프로젝트가 폐쇄 모드(
예, 그는 아무데도 가지 않았습니다.
오픈 소스에서 이 예를 볼 수 있습니까?
캔버스 작업에 대해 이해하지 못하는 것은 무엇입니까?
1. 다른 모든 그래픽 개체와 마찬가지로 이벤트에 응답합니다. 즉, 마우스가 움직일 때 마우스의 좌표를 추적하고 마우스 및 키보드 이벤트 에 응답할 수 있습니다.
2. 각 픽셀의 색상을 독립적으로 변경할 수 있습니다.
다른 무엇을합니까? 그리고 당신은 약간의 두뇌와 무의미하게 많은 시간을 낭비하려는 욕망이 필요합니다.
캔버스 작업에 대해 이해하지 못하는 것은 무엇입니까?
1. 다른 모든 그래픽 개체와 마찬가지로 이벤트에 응답합니다. 즉, 마우스가 움직일 때 마우스의 좌표를 추적하고 마우스 및 키보드 이벤트 에 응답할 수 있습니다.
2. 각 픽셀의 색상을 독립적으로 변경할 수 있습니다.
다른 무엇을합니까? 그리고 당신은 약간의 두뇌와 무의미하게 많은 시간을 낭비하려는 욕망이 필요합니다.
음, 캔버스 자체는 이벤트에 반응하지 않습니다. 그리고 각 픽셀을 변경할 수 있다는 사실은 이미 명확합니다.
나는 조각난 캔버스 다시 그리기의 구현에 관심이 있었습니다.
그러나 분명히 많은 사람들이 캔버스에 작은 부분, 즉 하나의 컨트롤만 다시 그려야 하는 경우에도 캔버스를 완전히 다시 그리기로 결정했습니다.
음, 캔버스 자체는 이벤트에 반응하지 않습니다. 그리고 각 픽셀을 변경할 수 있다는 사실은 이미 명확합니다.
나는 조각난 캔버스 다시 그리기의 구현에 관심이 있었습니다.
그러나 분명히 많은 사람들이 캔버스에 작은 부분, 즉 하나의 컨트롤만 다시 그려야 하는 경우에도 캔버스를 완전히 다시 그리기로 결정했습니다.
캔버스 자체는 이벤트에 반응하지 않지만 자체적으로 존재하지 않습니다.
단편적인 다시 그리기 - 시작할 가치가 있으며 그러한 목표가 있는지 명확해질 것입니다. 컨트롤 의 배열이 있어야 한다고 생각합니다. 각 컨트롤에는 테두리가 정의되어 있습니다. 일부 컨트롤을 다시 그릴 필요가 있을 때 모든 컨트롤을 살펴보고 여전히 이 영역에 속하는 컨트롤을 확인하고 다시 그려야 합니다. 비록 그렇다 하더라도.
캔버스 자체는 이벤트에 반응하지 않지만 자체적으로 존재하지 않습니다.
단편적인 다시 그리기 - 시작할 가치가 있으며 그러한 목표가 있는지 명확해질 것입니다. 컨트롤의 배열이 있어야 한다고 생각합니다. 각 컨트롤에는 테두리가 정의되어 있습니다. 일부 컨트롤을 다시 그릴 필요가 있을 때 모든 컨트롤을 살펴보고 여전히 이 영역에 속하는 컨트롤을 확인하고 다시 그려야 합니다. 비록 그렇다 하더라도.
그것이 바로 내가 만든 방법입니다. 원칙적으로 나는 이벤트 전송의 순간과 다른 몇 가지 포인트가 잘 작동하기 때문에 표준 라이브러리 를 기본으로 사용했습니다. Anatoly는 요소의 서로 다른 각 클래스에 대한 그룹화를 생성하지만 표준 요소에서는 모든 것이 단일 기본 개체로 축소됩니다.
결과적으로 WndObject에는 모든 컨트롤의 가장 일반적인 속성(크기, 위치, 배경색, 테두리 색상, 테두리 두께, 텍스트, 그림 등)에 대한 완전한 설명이 포함되어 있습니다. 또한 동일한 클래스에 부모 컨트롤에 대한 참조가 포함되어 있습니다. 즉, 요소에 대해 부모가 지정되지 않은 경우 차트에 자체 캔버스 개체를 만들고 그렇지 않으면 부모 캔버스에 그려집니다. 위치(독립, 종속)에 따라 요소 위치의 좌표도 계산됩니다. 또한 동일한 개체에는 이 요소가 차지하는 상위 영역에 대한 초기 설명이 포함된 배열이 있습니다. 아이디어 자체는 다음과 같습니다. 요소 자체만 변경되면 그리기 전에 픽셀 영역이 부모의 픽셀 매트릭스로 채워지고 컨트롤의 새 상태가 적용됩니다. 이 접근 방식을 사용하면 다시 그리기가 배열의 모든 요소를 순회하고 중첩 요소를 사용하여 재귀적으로 수행되기 때문에 매번 전체 캔버스를 다시 그릴 필요가 없습니다. 특정 컨트롤을 그리고 업데이트하기 위해 두 가지 기능이 가정됩니다. 하나는 전체 컨트롤을 생성할 때 부모(또는 빈 캔버스) 위에 요소를 그리고, 두 번째는 지정된 컨트롤의 표시만 업데이트합니다. 글쎄, 이런 것.
이벤트 모델에서 "잃어버린" 동안: 변경 후 어떤 레이어를 다시 그려야 하는지.
Nikolai는 그의 예에서 원칙적으로 로컬 영역 데이터를 저장하는 데 신경쓰지 않아야 함을 보여줍니다. 전체 캔버스를 다시 그리는 작업이 너무 빨라서 아래로 내려갈 필요가 없고 세부 사항이 필요하지 않기 때문에 항상 모든 것을 한 번에 다시 그리는 것으로 충분하기 때문입니다.