BlackTomcat : 물론, 나는 많이 이해하지 못하지만, 어떤 이유에서인지 다른 "소유자"가 만든 표시기의 복사본은 동일한 매개 변수를 사용하고 동일한 차트에 겹쳐 있어도 다른 핸들을 가질 것이라고 생각합니다. 그리고 그들은 원칙적으로 지표의 이미 존재하는 사본에 대해 알지 못할 수도 있고 알 수도 없습니다. 그려지면 단순히 서로 겹칩니다. 나는 내가 틀렸다는 것을 완전히 인정합니다. 그러나 논리는 이전 단락에서 작성된 것과 같아야 한다고 제안합니다.
물론 저는 MQ의 개발자는 아니지만 이 프로세스가 설명된 한 칠면조의 효과적인 캐싱은 상위 5위 안에 들었으므로 항상 "동일한" 칠면조가 하나만 있고 여러 " 소유자"에 대한 링크를 받게 됩니다. 핸들이 다를 수도 있습니다. 확인하지는 않았지만 내부에는 동일한 엔티티가 있을 것입니다. 아무도 "이미 존재하는 사본에 대해 알아야 한다"고 말하지 않았습니다. 추측하지 마십시오. 절대적으로 "소유자"를 제외하고는 아무도 지표를 알지 못하며 지표는 다른 "소유자"의 참조 카운터를 유지하지만 소유자를 모릅니다.
실습에서 알 수 있듯이 다른 사람들의 논리는 다릅니다. 예를 들어, 내 논리가 MQ의 논리와 일치하지 않는 경우가 종종 있지만 여기서는 내가 그들에게서 들은 것을 말하겠습니다.
물론 저는 MQ의 개발자는 아니지만 이 프로세스가 설명된 한 칠면조의 효과적인 캐싱은 상위 5위 안에 들었으므로 항상 "동일한" 칠면조가 하나만 있고 여러 " 소유자"에 대한 링크를 받게 됩니다. 핸들이 다를 수도 있습니다. 확인하지는 않았지만 내부에는 동일한 엔티티가 있을 것입니다. 아무도 "이미 존재하는 사본에 대해 알아야 한다"고 말하지 않았습니다. 추측하지 마십시오. 절대적으로 "소유자"를 제외하고는 아무도 지표를 알지 못하며 지표는 다른 "소유자"의 참조 카운터를 유지하지만 소유자를 모릅니다.
실습에서 알 수 있듯이 다른 사람들의 논리는 다릅니다. 예를 들어, 내 논리가 MQ의 논리와 일치하지 않는 경우가 종종 있지만 여기서는 내가 그들에게서 들은 것을 말하겠습니다.
실제로, 당신이 쓴 내용은 문서에 바로 기록되어 있습니다.
iMA, iAC, iMACD, iIchimoku 등과 같은 모든 기능은 클라이언트 터미널의 글로벌 캐시에 해당 기술 지표의 복사본을 생성합니다. 이러한 매개변수가 있는 표시기의 복사본이 이미 있는 경우 새 복사본이 생성되지 않지만 이 복사본에 대한 참조 카운터가 증가합니다.
여기에서만 흥미롭습니다. "클라이언트 터미널의 전역 캐시"에 예를 들어 테스터가 포함됩니까? 그렇지 않으면 터미널(계정)과 테스터(이력) 모두에서 동일한 표시기로 동일한 Expert Advisor를 실행할 수 있지만 계산된 버퍼가 일치하는지 확신할 수 없습니다. 그러나 클라이언트 터미널에 저장된 기록의 전체 깊이까지 계산하면 할 수 있습니다.
지표 생성은 매우 심층적인 계산 메커니즘을 유발하는 가장 비용이 많이 드는 작업 중 하나입니다. 표시기 핸들을 닫는 것도 구현의 실제 깊은 프로세스를 생각하면 매우 비용이 많이 드는 작업입니다. 표시기의 빈번한 생성 및 닫기는 개발자가 작업의 본질을 전혀 이해하지 못한다는 것을 나타냅니다.
이것은 매우 이해하기 쉽습니다.
IndicatorCreate 대신 iCustom을 사용할 때 사용자가 IndicatorRelease에 대한 책임을 개발자의 보편적인(따라서 최적이 아닌) 솔루션으로 옮기는 것을 올바르게 이해하고 있습니까?
생성된 지표는 일정 시간 동안 저장되고 특정 빈도로 액세스됩니다. 일정 시간 동안 호출이 없으면 강제 IndicatorRelease가 있습니다. 권리?
저것들. iCustom은 구현 복잡성과 성능 사이의 황금 평균이라는 측면에서 사용하기에 최적입니다. 그러나 최대 속도를 원하면 IndicatorCreate를 통해 모든 것을 시도하고 지표 사용의 특성을 알고 더 빠른(보편적이지 않은) 지표 저장 알고리즘을 만드는 것이 좋습니다.
IndicatorCreate 대신 iCustom을 사용할 때 사용자가 IndicatorRelease에 대한 책임을 개발자의 보편적인(따라서 최적이 아닌) 솔루션으로 옮기는 것을 올바르게 이해하고 있습니까?
생성된 지표는 일정 시간 동안 저장되고 특정 빈도로 액세스됩니다. 일정 시간 동안 호출이 없으면 강제 IndicatorRelease가 있습니다. 권리?
저것들. iCustom은 구현 복잡성과 성능 사이의 황금 평균이라는 측면에서 사용하기에 최적입니다. 그러나 최대 속도를 원하면 IndicatorCreate를 통해 모든 것을 시도하고 지표 사용의 특성을 알고 더 빠른(보편적이지 않은) 지표 저장 알고리즘을 만드는 것이 좋습니다.
원칙적으로 MT5에서 MT4 Expert Advisors를 실행하는 것이 가능하다는 것이 밝혀졌습니다. 내부적으로 다른 지표를 사용하지 않는 사람들에게는 매우 간단합니다. 용도 - MT4-iCustom 스토리지의 아날로그를 만드는 데 사용합니다. 데이터가 준비되지 않은 문제를 해결하는 것도 가능합니다.
이러한 어댑터를 작성하면 MT4 표시기가 MT5에서 성공적으로 시작됩니다. 그러나 Nikolai Kositsyn 은 직장을 잃을 것입니다 ... 아니요, 차라리 안하겠습니다.
원칙적으로 MT5에서 MT4 Expert Advisors를 실행하는 것이 가능하다는 것이 밝혀졌습니다. 내부적으로 다른 지표를 사용하지 않는 사람들에게는 매우 간단합니다. 용도 - MT4-iCustom 스토리지의 아날로그를 만드는 땜질. 데이터가 준비되지 않은 문제를 해결하는 것도 가능합니다.
이러한 어댑터를 작성하면 MT4 표시기가 MT5에서 성공적으로 시작됩니다. 그러나 Nikolai Kositsyn 은 직장을 잃을 것입니다 ... 아니요, 차라리 안하겠습니다.
EMNIP, Documentation에서는 OnInit 함수에서 표시기 핸들을 초기화(생성)하고 OnDeinit 함수에서 IndicatorRelease를 실행하는 것이 가장 정확하다고 말합니다. 저것들. 어드바이저가 작업하는 동안 항상 표시기 핸들이 관련성을 유지합니다.
물론, 나는 많이 이해하지 못하지만, 어떤 이유에서인지 다른 "소유자"가 만든 표시기의 복사본은 동일한 매개 변수를 사용하고 동일한 차트에 겹쳐 있어도 다른 핸들을 가질 것이라고 생각합니다. 그리고 그들은 원칙적으로 지표의 이미 존재하는 사본에 대해 알지 못할 수도 있고 알 수도 없습니다. 그려지면 단순히 서로 겹칩니다.
나는 내가 틀렸다는 것을 완전히 인정합니다. 그러나 논리는 이전 단락에서 작성된 것과 같아야 한다고 제안합니다.
물론 저는 MQ의 개발자는 아니지만 이 프로세스가 설명된 한 칠면조의 효과적인 캐싱은 상위 5위 안에 들었으므로 항상 "동일한" 칠면조가 하나만 있고 여러 " 소유자"에 대한 링크를 받게 됩니다. 핸들이 다를 수도 있습니다. 확인하지는 않았지만 내부에는 동일한 엔티티가 있을 것입니다. 아무도 "이미 존재하는 사본에 대해 알아야 한다"고 말하지 않았습니다. 추측하지 마십시오. 절대적으로 "소유자"를 제외하고는 아무도 지표를 알지 못하며 지표는 다른 "소유자"의 참조 카운터를 유지하지만 소유자를 모릅니다.
실습에서 알 수 있듯이 다른 사람들의 논리는 다릅니다. 예를 들어, 내 논리가 MQ의 논리와 일치하지 않는 경우가 종종 있지만 여기서는 내가 그들에게서 들은 것을 말하겠습니다.
물론 저는 MQ의 개발자는 아니지만 이 프로세스가 설명된 한 칠면조의 효과적인 캐싱은 상위 5위 안에 들었으므로 항상 "동일한" 칠면조가 하나만 있고 여러 " 소유자"에 대한 링크를 받게 됩니다. 핸들이 다를 수도 있습니다. 확인하지는 않았지만 내부에는 동일한 엔티티가 있을 것입니다. 아무도 "이미 존재하는 사본에 대해 알아야 한다"고 말하지 않았습니다. 추측하지 마십시오. 절대적으로 "소유자"를 제외하고는 아무도 지표를 알지 못하며 지표는 다른 "소유자"의 참조 카운터를 유지하지만 소유자를 모릅니다.
실습에서 알 수 있듯이 다른 사람들의 논리는 다릅니다. 예를 들어, 내 논리가 MQ의 논리와 일치하지 않는 경우가 종종 있지만 여기서는 내가 그들에게서 들은 것을 말하겠습니다.
iMA, iAC, iMACD, iIchimoku 등과 같은 모든 기능은 클라이언트 터미널의 글로벌 캐시에 해당 기술 지표의 복사본을 생성합니다. 이러한 매개변수가 있는 표시기의 복사본이 이미 있는 경우 새 복사본이 생성되지 않지만 이 복사본에 대한 참조 카운터가 증가합니다.
실행 중 오류가 발생하여 원래 프로그램에 가까운 테스트 스크립트를 생성할 수 있었습니다.
결과: 'Script2.mq5'에서 잘못된 함수 포인터 호출
빌드 1405. 자체적으로 이 오류가 남아 있습니다 - 프로그램의 다른 부분으로 이동 - 나중에 알아내겠습니다
그러나 이전에는 없었던 새로운 것이 있습니다.
결과: 잘못된 EX5 파일(8)Shift + F9 디버깅에서 배열 요소 를 표시하는 방법은 무엇입니까?
사실 99%의 경우 IndicatorRelease에 대한 호출 은 프로그래머의 논리적 오류입니다.
지표 생성은 매우 심층적인 계산 메커니즘을 유발하는 가장 비용이 많이 드는 작업 중 하나입니다. 표시기 핸들을 닫는 것도 구현의 실제 깊은 프로세스를 생각하면 매우 비용이 많이 드는 작업입니다. 표시기의 빈번한 생성 및 닫기는 개발자가 작업의 본질을 전혀 이해하지 못한다는 것을 나타냅니다.
이것은 매우 이해하기 쉽습니다.
IndicatorCreate 대신 iCustom을 사용할 때 사용자가 IndicatorRelease에 대한 책임을 개발자의 보편적인(따라서 최적이 아닌) 솔루션으로 옮기는 것을 올바르게 이해하고 있습니까?
생성된 지표는 일정 시간 동안 저장되고 특정 빈도로 액세스됩니다. 일정 시간 동안 호출이 없으면 강제 IndicatorRelease가 있습니다. 권리?
저것들. iCustom은 구현 복잡성과 성능 사이의 황금 평균이라는 측면에서 사용하기에 최적입니다. 그러나 최대 속도를 원하면 IndicatorCreate를 통해 모든 것을 시도하고 지표 사용의 특성을 알고 더 빠른(보편적이지 않은) 지표 저장 알고리즘을 만드는 것이 좋습니다.
제가 제대로 이해한건가요?
IndicatorCreate 대신 iCustom을 사용할 때 사용자가 IndicatorRelease에 대한 책임을 개발자의 보편적인(따라서 최적이 아닌) 솔루션으로 옮기는 것을 올바르게 이해하고 있습니까?
생성된 지표는 일정 시간 동안 저장되고 특정 빈도로 액세스됩니다. 일정 시간 동안 호출이 없으면 강제 IndicatorRelease가 있습니다. 권리?
저것들. iCustom은 구현 복잡성과 성능 사이의 황금 평균이라는 측면에서 사용하기에 최적입니다. 그러나 최대 속도를 원하면 IndicatorCreate를 통해 모든 것을 시도하고 지표 사용의 특성을 알고 더 빠른(보편적이지 않은) 지표 저장 알고리즘을 만드는 것이 좋습니다.
제가 제대로 이해한건가요?
아니, 틀렸어.
두 기능은 완전히 동일합니다. 두 함수 모두 표시기 핸들을 반환합니다.
아니, 틀렸어.
두 기능은 완전히 동일합니다. 두 함수 모두 표시기 핸들을 반환합니다.
iCustom 후에 IndicatorRelease를 수행해야 합니까?
원칙적으로 MT5에서 MT4 Expert Advisors를 실행하는 것이 가능하다는 것이 밝혀졌습니다. 내부적으로 다른 지표를 사용하지 않는 사람들에게는 매우 간단합니다. 용도 - MT4-iCustom 스토리지의 아날로그를 만드는 데 사용합니다. 데이터가 준비되지 않은 문제를 해결하는 것도 가능합니다.
이러한 어댑터를 작성하면 MT4 표시기가 MT5에서 성공적으로 시작됩니다. 그러나 Nikolai Kositsyn 은 직장을 잃을 것입니다 ... 아니요, 차라리 안하겠습니다.
iCustom 후에 IndicatorRelease를 수행해야 합니까?
원칙적으로 MT5에서 MT4 Expert Advisors를 실행하는 것이 가능하다는 것이 밝혀졌습니다. 내부적으로 다른 지표를 사용하지 않는 사람들에게는 매우 간단합니다. 용도 - MT4-iCustom 스토리지의 아날로그를 만드는 땜질. 데이터가 준비되지 않은 문제를 해결하는 것도 가능합니다.
이러한 어댑터를 작성하면 MT4 표시기가 MT5에서 성공적으로 시작됩니다. 그러나 Nikolai Kositsyn 은 직장을 잃을 것입니다 ... 아니요, 차라리 안하겠습니다.