Nikolai, 단지 재미를 위한 것입니다. 그러한 지표의 요점은 무엇입니까? 나는 이것이 예라는 것을 이해하고 거래를위한 것이 아니라는 것을 이해하지만 ... 좋은 방법으로 지표는 외부에서 데이터를 수신 할 수 있도록해야합니다. 그렇지 않으면 그냥 예쁜 그림일 뿐입니다. 그리고 데이터를 반환하지 않는 지표의 범위는 크게 좁혀집니다.
이러한 표시기에서 데이터를 반환하는 방법을 만드는 방법에 대한 힌트 - 이것은 더 흥미로울 것입니다.
Nikolai, 단지 재미를 위한 것입니다. 그러한 지표의 요점은 무엇입니까? 나는 이것이 예라는 것을 이해하고 거래를위한 것이 아니라는 것을 이해하지만 ... 좋은 방법으로 지표는 외부에서 데이터를 수신 할 수 있도록해야합니다. 그렇지 않으면 그냥 예쁜 그림일 뿐입니다. 그리고 데이터를 반환하지 않는 지표의 범위는 크게 좁혀집니다.
이러한 표시기에서 데이터를 반환하는 방법을 만드는 방법에 대한 힌트 - 이것은 더 흥미로울 것입니다.
"캔버스" 표시기에서 데이터를 반환하는 방법을 설정하는 것은 큰 문제가 아닙니다. 많은 옵션이 보입니다.
또한 99.9%의 경우 실제 거래를 위해서는 0과 첫 번째 막대의 값만 필요합니다. 정말 이러한 값을 전송하는 것이 문제입니까? 표시기 데이터를 배열이나 버퍼에 넣는 문제는 무엇입니까? 자원도 거기에 있다.
저는 이 예제를 단 하나의 목적으로 시연했습니다. - 캔버스를 통해 표시기를 구현하는 것이 빠르고 고전적인 방법보다 훨씬 빠릅니다. 그리고 이것은 절대적인 유연성입니다.
또한 "지표에서 데이터를 가져올 필요가 있습니까?"라는 큰 질문이 있습니다.
나만의 고유한 지표가 있다면 시각화용 지표만 있으면 됩니다. 그리고 창 밖의 막대에 대한 지표 값을 계산하는 요점은 무엇입니까? 나는 이것을 완전히 중복된 것으로 본다. 알고리즘 거래에 지표 값이 필요한 경우 클래스 인스턴스를 통해 지표 계산을 올빼미의 몸에 삽입하는 것이 더 쉽지 않을까요?
"캔버스" 표시기에서 데이터를 반환하는 방법을 설정하는 것은 큰 문제가 아닙니다. 많은 옵션이 보입니다.
또한 99.9%의 경우 실제 거래를 위해서는 0과 첫 번째 막대의 값만 필요합니다. 정말 이러한 값을 전송하는 것이 문제입니까? 표시기 데이터를 배열이나 버퍼에 넣는 문제는 무엇입니까? 자원도 거기에 있다.
저는 이 예제를 단 하나의 목적으로 시연했습니다. - 캔버스를 통해 표시기를 구현하는 것이 빠르고 고전적인 방법보다 훨씬 빠릅니다. 그리고 이것은 절대적인 유연성입니다.
또한 "지표에서 데이터를 가져올 필요가 있습니까?"라는 큰 질문이 있습니다.
나만의 고유한 지표가 있다면 시각화용 지표만 있으면 됩니다. 그리고 창 밖의 막대에 대한 지표 값을 계산하는 요점은 무엇입니까? 나는 이것을 완전히 중복된 것으로 본다. 알고 거래에 지표 값이 필요한 경우 지표 계산을 올빼미의 몸에 삽입하는 것이 더 쉽지 않을까요?
동의한다. 그러나 달리 필요한 사용자 범주가 있습니다.
그리고 캔버스 인디케이터의 반환 데이터가 512보다 크면? 버퍼는 여기서 도움이 되지 않습니다. 그리고 사용자는 단순히 프로그램의 지표에서 데이터를 수신하기를 원합니다. 그리고 그들은 고문의 몸에 그들을 만들고 싶지 않습니다 (나는 올빼미를 후회할 것입니다 - 딸랑이없이 날게하십시오 ...). 그리고 그들은 보이는 바뿐만 아니라 요청된 바에 대한 데이터를 받기를 원합니다. 그리고 그것은 정당합니다. 그리고 그것은 게으름과 모든 것을 쉽고 간단하게 얻으려는 욕구뿐만 아니라 차량의 요구 사항에 의해 정당화됩니다.
그리고 캔버스 인디케이터의 반환 데이터가 512보다 크면? 버퍼는 여기서 도움이 되지 않습니다. 그리고 사용자는 단순히 프로그램의 지표에서 데이터를 받기를 원합니다. 그리고 그들은 고문의 몸에 그들을 만들고 싶지 않습니다 (나는 올빼미를 후회할 것입니다 - 딸랑이없이 날게하십시오 ...). 그리고 그들은 보이는 바뿐만 아니라 요청된 바에 대한 데이터를 받기를 원합니다. 그리고 그것은 정당합니다. 그리고 그것은 게으름과 모든 것을 쉽고 간단하게 얻으려는 욕구뿐만 아니라 차량의 요구 사항에 의해 정당화됩니다.
프로그래머가 아닌 대다수의 사용자에 대해 이야기하고 있다면 사용자는 올빼미나 지표가 필요합니다. 그들은 올빼미에 대한 지표가 필요하지 않습니다.
나는 반성하기 위한 정보를 제공했을 뿐 아무 것도 부과하지 않았습니다. 무엇이 comme il faut이고 무엇이 comme il faut가 아닌지는 프로그래머가 스스로 결정하게 하십시오. 그러나 개인적으로 몇 가지 점을 깨닫고 나면 Expert Advisors에서 iCustom 기능을 거의 사용하지 않을 것입니다.
예, 작은 관절이 있었습니다. 수정했습니다.
고맙습니다.
마지막 파일을 다시 업로드하셨나요?
예, 이제 모든 것이 정상입니다!속도를 보여주기 위해...
마우스 포인터를 통해 두 매개변수 변경
X - MA 변경의 최대 기간
Y - MA 기간 변경 단계
Nikolai, 단지 재미를 위한 것입니다. 그러한 지표의 요점은 무엇입니까? 나는 이것이 예라는 것을 이해하고 거래를위한 것이 아니라는 것을 이해하지만 ... 좋은 방법으로 지표는 외부에서 데이터를 수신 할 수 있도록해야합니다. 그렇지 않으면 그냥 예쁜 그림일 뿐입니다. 그리고 데이터를 반환하지 않는 지표의 범위는 크게 좁혀집니다.
이러한 표시기에서 데이터를 반환하는 방법을 만드는 방법에 대한 힌트 - 이것은 더 흥미로울 것입니다.
Nikolai, 단지 재미를 위한 것입니다. 그러한 지표의 요점은 무엇입니까? 나는 이것이 예라는 것을 이해하고 거래를위한 것이 아니라는 것을 이해하지만 ... 좋은 방법으로 지표는 외부에서 데이터를 수신 할 수 있도록해야합니다. 그렇지 않으면 그냥 예쁜 그림일 뿐입니다. 그리고 데이터를 반환하지 않는 지표의 범위는 크게 좁혀집니다.
이러한 표시기에서 데이터를 반환하는 방법을 만드는 방법에 대한 힌트 - 이것은 더 흥미로울 것입니다.
"캔버스" 표시기에서 데이터를 반환하는 방법을 설정하는 것은 큰 문제가 아닙니다. 많은 옵션이 보입니다.
또한 99.9%의 경우 실제 거래를 위해서는 0과 첫 번째 막대의 값만 필요합니다. 정말 이러한 값을 전송하는 것이 문제입니까? 표시기 데이터를 배열이나 버퍼에 넣는 문제는 무엇입니까? 자원도 거기에 있다.
저는 이 예제를 단 하나의 목적으로 시연했습니다. - 캔버스를 통해 표시기를 구현하는 것이 빠르고 고전적인 방법보다 훨씬 빠릅니다. 그리고 이것은 절대적인 유연성입니다.
또한 "지표에서 데이터를 가져올 필요가 있습니까?"라는 큰 질문이 있습니다.
나만의 고유한 지표가 있다면 시각화용 지표만 있으면 됩니다. 그리고 창 밖의 막대에 대한 지표 값을 계산하는 요점은 무엇입니까? 나는 이것을 완전히 중복된 것으로 본다. 알고리즘 거래에 지표 값이 필요한 경우 클래스 인스턴스를 통해 지표 계산을 올빼미의 몸에 삽입하는 것이 더 쉽지 않을까요?
"캔버스" 표시기에서 데이터를 반환하는 방법을 설정하는 것은 큰 문제가 아닙니다. 많은 옵션이 보입니다.
또한 99.9%의 경우 실제 거래를 위해서는 0과 첫 번째 막대의 값만 필요합니다. 정말 이러한 값을 전송하는 것이 문제입니까? 표시기 데이터를 배열이나 버퍼에 넣는 문제는 무엇입니까? 자원도 거기에 있다.
저는 이 예제를 단 하나의 목적으로 시연했습니다. - 캔버스를 통해 표시기를 구현하는 것이 빠르고 고전적인 방법보다 훨씬 빠릅니다. 그리고 이것은 절대적인 유연성입니다.
또한 "지표에서 데이터를 가져올 필요가 있습니까?"라는 큰 질문이 있습니다.
나만의 고유한 지표가 있다면 시각화용 지표만 있으면 됩니다. 그리고 창 밖의 막대에 대한 지표 값을 계산하는 요점은 무엇입니까? 나는 이것을 완전히 중복된 것으로 본다. 알고 거래에 지표 값이 필요한 경우 지표 계산을 올빼미의 몸에 삽입하는 것이 더 쉽지 않을까요?
동의한다. 그러나 달리 필요한 사용자 범주가 있습니다.
그리고 캔버스 인디케이터의 반환 데이터가 512보다 크면? 버퍼는 여기서 도움이 되지 않습니다. 그리고 사용자는 단순히 프로그램의 지표에서 데이터를 수신하기를 원합니다. 그리고 그들은 고문의 몸에 그들을 만들고 싶지 않습니다 (나는 올빼미를 후회할 것입니다 - 딸랑이없이 날게하십시오 ...). 그리고 그들은 보이는 바뿐만 아니라 요청된 바에 대한 데이터를 받기를 원합니다. 그리고 그것은 정당합니다. 그리고 그것은 게으름과 모든 것을 쉽고 간단하게 얻으려는 욕구뿐만 아니라 차량의 요구 사항에 의해 정당화됩니다.
동의한다. 그러나 달리 필요한 사용자 범주가 있습니다.
그리고 캔버스 인디케이터의 반환 데이터가 512보다 크면? 버퍼는 여기서 도움이 되지 않습니다. 그리고 사용자는 단순히 프로그램의 지표에서 데이터를 받기를 원합니다. 그리고 그들은 고문의 몸에 그들을 만들고 싶지 않습니다 (나는 올빼미를 후회할 것입니다 - 딸랑이없이 날게하십시오 ...). 그리고 그들은 보이는 바뿐만 아니라 요청된 바에 대한 데이터를 받기를 원합니다. 그리고 그것은 정당합니다. 그리고 그것은 게으름과 모든 것을 쉽고 간단하게 얻으려는 욕구뿐만 아니라 차량의 요구 사항에 의해 정당화됩니다.
프로그래머가 아닌 대다수의 사용자에 대해 이야기하고 있다면 사용자는 올빼미나 지표가 필요합니다. 그들은 올빼미에 대한 지표가 필요하지 않습니다.
나는 반성하기 위한 정보를 제공했을 뿐 아무 것도 부과하지 않았습니다. 무엇이 comme il faut이고 무엇이 comme il faut가 아닌지는 프로그래머가 스스로 결정하게 하십시오. 그러나 개인적으로 몇 가지 점을 깨닫고 나면 Expert Advisors에서 iCustom 기능을 거의 사용하지 않을 것입니다.
"캔버스" 표시기에서 데이터를 반환하는 방법을 설정하는 것은 큰 문제가 아닙니다. 많은 옵션이 보입니다.
또한 99.9%의 경우 실제 거래를 위해서는 0과 첫 번째 막대의 값만 필요합니다. 정말 이러한 값을 전송하는 것이 문제입니까? 표시기 데이터를 배열이나 버퍼에 넣는 문제는 무엇입니까? 자원도 거기에 있다.
저는 이 예제를 단 하나의 목적으로 시연했습니다. - 캔버스를 통해 표시기를 구현하는 것이 빠르고 고전적인 방법보다 훨씬 빠릅니다. 그리고 이것은 절대적인 유연성입니다.
또한 "지표에서 데이터를 가져올 필요가 있습니까?"라는 큰 질문이 있습니다.
나만의 고유한 지표가 있다면 시각화용 지표만 있으면 됩니다. 그리고 창 밖의 막대에 대한 지표 값을 계산하는 요점은 무엇입니까? 나는 그것을 완전히 중복으로 본다. 알고 거래를 위한 지표 값이 필요하다면 .
내 생각에는 지표도 클래스 인스턴스를 통해 작성되어야 합니다. 그러면 이 클래스를 참고하여 최소한의 지표, 최소한의 고문을 만드는 것이 가능할 것입니다. 내 컬렉션에 이 중 하나가 있습니다. 정말 좋아.
속도를 보여주기 위해...
마우스 포인터를 통해 두 매개변수 변경
X - MA 변경의 최대 기간
Y - MA 기간 변경 단계
잘했어, 니콜라이. 계속 유지하십시오.
내 생각에는 지표도 클래스 인스턴스를 통해 작성되어야 합니다. 그러면 이 클래스를 참고하여 최소한의 지표, 최소한의 고문을 만드는 것이 가능할 것입니다. 내 컬렉션에 이 중 하나가 있습니다. 정말 좋아.
잘했어 니콜라이. 계속 유지하십시오.
Peter, 내가 어떻게 6색의 다중 그라디언트를 구현했는지 주목하십시오.
여기서 p는 0에서 1로 변경됩니다.
극단적 인 색상에는 아직 수정 할 손이 닿지 않은 한 가지 결함이 있지만 위협적입니다.