버퍼는 작업하기 더 쉽지만 무엇이든 Canvas로 출력할 수 있습니다. 반면 MQL5의 사용자 지정 표시기에는 다양한 유형의 표시기 버퍼 도 있습니다. 일반적으로 이러한 방법 중 하나를 선택하면 프로그래머는 실수를 하지 않습니다. 그러나 선택은 항상 당면한 작업에 따라 달라야 합니다...
Mihail Matkovskij # : 버퍼는 작업하기 더 쉽지만 무엇이든 Canvas로 출력할 수 있습니다. 반면 MQL5의 사용자 지정 표시기에는 다양한 유형의 표시기 버퍼 도 있습니다. 일반적으로 이러한 방법 중 하나를 선택하면 프로그래머는 실수를 하지 않습니다. 그러나 선택은 항상 당면한 작업에 따라 달라야 합니다...
물론 버퍼는 작업하기가 더 어렵습니다. 캔버스로 더 쉽게. 함수에 #property를 넣을 수 없습니다.
그리고 함수에 배열을 전달하여 캔버스 라인을 한 줄에 추가할 수 있습니다. 개인적으로 개발 프로세스의 일부 프로세스와 중간 데이터를 시각화하기 위해 캔버스를 더 많이 사용합니다. 이렇게 하면 문제를 보다 쉽게 확인하고 최적의 솔루션을 찾을 수 있습니다. 물론 교차점을 기반으로 하는 기본 알고리즘에 대해 이야기하고 있지 않는 한. 예를 들어, 여기 내 현재 직업이 있습니다. 이 모든 vinigret은 공식적이며 최상의 솔루션을 찾는 데 많은 도움이 됩니다. 물론 버퍼를 사용하면 이것이 불가능합니다. 또한 이러한 솔루션은 Expert Advisors 및 지표에서 동일하게 작동합니다. 또한 코드는 MT4에서 작동합니다.
물론 버퍼는 작업하기가 더 어렵습니다. 캔버스로 더 쉽게. 함수에 #property를 넣을 수 없습니다.
에 배열을 전달하여 캔버스 라인을 한 줄에 추가할 수 있습니다 . 개인적으로 개발 프로세스의 일부 프로세스와 중간 데이터를 시각화하기 위해 캔버스를 더 많이 사용합니다. 이를 통해 문제를 보다 쉽게 확인하고 최적의 솔루션을 찾을 수 있습니다. 물론 교차점을 기반으로 하는 기본 알고리즘에 대해 이야기하고 있지 않는 한. 예를 들어, 여기 내 현재 직업이 있습니다. 이 모든 vinigret은 공식적이며 최상의 솔루션을 찾는 데 많은 도움이 됩니다. 물론 버퍼를 사용하면 이것이 불가능합니다. 또한 이러한 솔루션은 Expert Advisors 및 지표에서 동일하게 작동합니다. 또한 코드는 MT4에서 작동합니다.
그리고 그것은 매우 쉽고 빠르게 구현됩니다. 말 그대로 즉석에서.
이러한 작업은 Canvas를 사용하기만 하면 됩니다. 그리고 물론 옵션이 없습니다. 하나의 옵션이 있지만 DirectX입니다. 근데 MQL 애플리케이션에서 누가 사용하는지 모르겠는데... 그런 예는 본 적이 없어요. Canvas는 추세 표시기와 함께 차트에 오실레이터를 가져와야 할 때 많은 도움이 되었습니다. 당연히 이것은 맞춤형 지표 메커니즘의 도움으로 달성할 수 없습니다. CCanvas를 기반으로 2개의 클래스를 만들었습니다. 하나는 오실레이터를 출력하고 두 번째는 방법을 사용하여 추세 표시기를 표시합니다. 여기에서 표시기 값 배열, 색상 배열 및 색상 인덱스 배열이 전달됩니다. 그러나 하나의 지표를 표시해야 할 때 사용자 지정 지표 방법을 사용합니다. 이유를 모르겠습니다. 습관이든, 나는 코드를 불필요하게 복잡하게 만들고 싶지 않습니다. 본질과 복잡성이 값의 계산에 있고 값이 출력되는 방식이 아닌 경우입니다.
Mihail Matkovskij # : 그러나 선택은 항상 당면한 작업에 따라 달라야 합니다...
할 말을 잊었다. Canvas를 사용하는 것은 계산된 값을 차트에 표시해야 하는 로봇에서도 매우 편리하며, 아시다시피 수중에 표시기 버퍼가 없습니다. 그런 다음 값이나 신호가 충분하다면 Canvas의 도움으로만 값이나 신호를 표시할 수 있습니다(그래픽 개체를 사용하여 표시할 수 있는 2-3개의 신호가 아님).
그리고 무슨 문제가 있니, 안드레이? Expert Advisor 또는 지표에서 데이터 구조 또는 구조 배열을 형성하고 이를 리소스로 보냅니다. 그리고 받는 쪽에서는 이 구조나 구조의 배열을 읽습니다. 전체 따옴표 길이에 대해 번호가 매겨진 이중 배열이 아니라 필요한 크기의 이름과 다양한 데이터 유형을 다루기 때문에 훨씬 더 편리합니다. 이것이 시장에 대한 지표이지만 리소스에서 데이터를 읽는 클래스를 고객에게 제공해야 하는 경우. 클라이언트는 클래스의 인스턴스를 포함하고 선언하기만 하면 됩니다. OnTimer 및 OnTick에서 메서드를 호출할 수도 있습니다. 그리고 이 클래스의 인스턴스는 항상 읽기 쉬운 구조 또는 구조의 배열 형태로 읽기 표시기의 실제 데이터를 갖습니다.
맙소사, 이 버퍼 인디케이터는 뭐가 불편해요. 공포.
캔버스 드로잉을 사용하면 모든 것이 훨씬 간단하고 코드가 적으며 더 명확하고 더 다양하고 완전한 행동의 자유가 있습니다.
예, 모두가 캔버스에 대한 당신의 열정을 오랫동안 이해했습니다. 그러나 모든 사람이 그것에 익숙하지는 않습니다 ...)))
헛되이.
그래... 내가 먼저 죽지 않는다면...
아마도 목발은 아니지만 지금까지 무슨 일이 일어나고 있는지에 대한 설명이 없습니다. 감사해요…
아마도 빌드에서 더 높은 버퍼에 따라 다릅니다. +를 -로 변경하면 충분합니다.
그리고 그것은 너무 작동합니다. 그러나 나는 막대 내부의 두께를 지시해야했습니다.
채우기 버퍼에는 두 가지 색상이 있습니다. 둘 다 쉼표로 구분해야 합니다. 화면에서 어느 것이 더 높은가에 따라 채우기 색상이 결정됩니다. 색상 중 하나를 지정하지 않았습니다. clrNONE으로 대체됩니다.
버퍼는 작업하기 더 쉽지만 무엇이든 Canvas로 출력할 수 있습니다. 반면 MQL5의 사용자 지정 표시기에는 다양한 유형의 표시기 버퍼 도 있습니다. 일반적으로 이러한 방법 중 하나를 선택하면 프로그래머는 실수를 하지 않습니다. 그러나 선택은 항상 당면한 작업에 따라 달라야 합니다...
물론 버퍼는 작업하기가 더 어렵습니다. 캔버스로 더 쉽게.
함수에 #property를 넣을 수 없습니다.
그리고 함수에 배열을 전달하여 캔버스 라인을 한 줄에 추가할 수 있습니다.
개인적으로 개발 프로세스의 일부 프로세스와 중간 데이터를 시각화하기 위해 캔버스를 더 많이 사용합니다. 이렇게 하면 문제를 보다 쉽게 확인하고 최적의 솔루션을 찾을 수 있습니다.
물론 교차점을 기반으로 하는 기본 알고리즘에 대해 이야기하고 있지 않는 한.
예를 들어, 여기 내 현재 직업이 있습니다.
이 모든 vinigret은 공식적이며 최상의 솔루션을 찾는 데 많은 도움이 됩니다.
물론 버퍼를 사용하면 이것이 불가능합니다. 또한 이러한 솔루션은 Expert Advisors 및 지표에서 동일하게 작동합니다. 또한 코드는 MT4에서 작동합니다.
물론 버퍼는 작업하기가 더 어렵습니다. 캔버스로 더 쉽게.
함수에 #property를 넣을 수 없습니다.
에 배열을 전달하여 캔버스 라인을 한 줄에 추가할 수 있습니다 .
그리고 그것은 매우 쉽고 빠르게 구현됩니다. 말 그대로 즉석에서.개인적으로 개발 프로세스의 일부 프로세스와 중간 데이터를 시각화하기 위해 캔버스를 더 많이 사용합니다. 이를 통해 문제를 보다 쉽게 확인하고 최적의 솔루션을 찾을 수 있습니다.
물론 교차점을 기반으로 하는 기본 알고리즘에 대해 이야기하고 있지 않는 한.
예를 들어, 여기 내 현재 직업이 있습니다.
이 모든 vinigret은 공식적이며 최상의 솔루션을 찾는 데 많은 도움이 됩니다.
물론 버퍼를 사용하면 이것이 불가능합니다. 또한 이러한 솔루션은 Expert Advisors 및 지표에서 동일하게 작동합니다. 또한 코드는 MT4에서 작동합니다.
이러한 작업은 Canvas를 사용하기만 하면 됩니다. 그리고 물론 옵션이 없습니다. 하나의 옵션이 있지만 DirectX입니다. 근데 MQL 애플리케이션에서 누가 사용하는지 모르겠는데... 그런 예는 본 적이 없어요. Canvas는 추세 표시기와 함께 차트에 오실레이터를 가져와야 할 때 많은 도움이 되었습니다. 당연히 이것은 맞춤형 지표 메커니즘의 도움으로 달성할 수 없습니다. CCanvas를 기반으로 2개의 클래스를 만들었습니다. 하나는 오실레이터를 출력하고 두 번째는 방법을 사용하여 추세 표시기를 표시합니다. 여기에서 표시기 값 배열, 색상 배열 및 색상 인덱스 배열이 전달됩니다. 그러나 하나의 지표를 표시해야 할 때 사용자 지정 지표 방법을 사용합니다. 이유를 모르겠습니다. 습관이든, 나는 코드를 불필요하게 복잡하게 만들고 싶지 않습니다. 본질과 복잡성이 값의 계산에 있고 값이 출력되는 방식이 아닌 경우입니다.
그러나 선택은 항상 당면한 작업에 따라 달라야 합니다...
할 말을 잊었다. Canvas를 사용하는 것은 계산된 값을 차트에 표시해야 하는 로봇에서도 매우 편리하며, 아시다시피 수중에 표시기 버퍼가 없습니다. 그런 다음 값이나 신호가 충분하다면 Canvas의 도움으로만 값이나 신호를 표시할 수 있습니다(그래픽 개체를 사용하여 표시할 수 있는 2-3개의 신호가 아님).
맙소사, 이 버퍼 인디케이터는 뭐가 불편해요. 공포.
캔버스 드로잉을 사용하면 모든 것이 훨씬 간단하고 코드가 적으며 더 명확하고 더 다양하고 완전한 행동의 자유가 있습니다.
캔버스의 다양성은 값을 다른 EA/지표에서 가져와야 할 때 끝납니다.
아니면 이미 이에 대한 해결책을 찾았습니까? )
캔버스의 다양성은 값을 다른 EA/지표에서 가져와야 할 때 끝납니다.
아니면 이미 이에 대한 해결책을 찾았습니까? )
그리고 무슨 문제가 있니, 안드레이?
Expert Advisor 또는 지표에서 데이터 구조 또는 구조 배열을 형성하고 이를 리소스로 보냅니다.
그리고 받는 쪽에서는 이 구조나 구조의 배열을 읽습니다.
전체 따옴표 길이에 대해 번호가 매겨진 이중 배열이 아니라 필요한 크기의 이름과 다양한 데이터 유형을 다루기 때문에 훨씬 더 편리합니다.
이것이 시장에 대한 지표이지만 리소스에서 데이터를 읽는 클래스를 고객에게 제공해야 하는 경우.
클라이언트는 클래스의 인스턴스를 포함하고 선언하기만 하면 됩니다. OnTimer 및 OnTick에서 메서드를 호출할 수도 있습니다. 그리고 이 클래스의 인스턴스는 항상 읽기 쉬운 구조 또는 구조의 배열 형태로 읽기 표시기의 실제 데이터를 갖습니다.