EA는 표시기에 대한 액세스가 필요합니다. IndicatorCreate(...) 또는 iCustome(...) 또는 iMA(...)와 같은 표준 표시기인 경우 최소한 세 가지 방법으로 얻을 수 있습니다.
내가 알기로는 어떤 옵션을 사용할 때 받은 핸들(IndicatorRelease)을 명시적으로 해제해야 합니다.
문제는 지표를 호출하는 방법을 선택하는 것입니다. 각 방법의 장단점은 무엇입니까? 처리 속도에 대한 우선 순위 관심.
IndicatorCreate - 표준 표시기의 경우 손 제스처의 경우 iMA 호출과 유사합니다. iCustom - "커스텀" 커스텀 인디케이터용. 저것들. 본질적으로 다른 것들.
iMA와 IndicatorCreate(IND_MA)를 호출하는 속도는 비슷해야 하지만 테스트하지 않았습니다.
IndicatorRelease와 관련하여 - 계산 후 더 이상 이 칠면조로 돌아갈 필요가 없는 경우 전화하는 것이 좋습니다. 나는 그런 상황이 없습니다. 어떤 종류의 칠면조가 필요한 경우(주어진 매개변수 세트 사용), 재계산/재계산에 필요하며 스크립트 입력 매개변수가 변경되면 모든 것이 다시 초기화되고 새 핸들이 됩니다. 생성됩니다.
지표 생성은 매우 심층적인 계산 메커니즘을 유발하는 가장 비용이 많이 드는 작업 중 하나입니다. 표시기 핸들을 닫는 것도 구현의 실제 깊은 프로세스를 생각하면 매우 비용이 많이 드는 작업입니다. 표시기의 빈번한 생성 및 닫기는 개발자가 작업의 본질을 전혀 이해하지 못한다는 것을 나타냅니다.
지표 생성은 매우 심층적인 계산 메커니즘을 유발하는 가장 비용이 많이 드는 작업 중 하나입니다. 표시기 핸들을 닫는 것도 구현의 실제 깊은 프로세스를 생각하면 매우 비용이 많이 드는 작업입니다. 표시기의 빈번한 생성 및 닫기는 개발자가 작업의 본질을 전혀 이해하지 못한다는 것을 나타냅니다.
이것은 매우 이해하기 쉽습니다.
대화에 개입하여 다음과 같이 말하겠습니다. 프로그램의 메커니즘, 터미널, 외환(사실, 우리가 여기에 있는 이유)
단순한 진실이기 때문에 우리가 그것들을 이해하고 루블을 깎는 것을 방해합니다. 또는 우리가 판매할 프로그램,
'GetLastError' - ambiguous call to overloaded function with the same parameters SymbolInfo.mqh 718 10
'GetLastError' - ambiguous call to overloaded function with the same parameters SymbolInfo.mqh 725 57
EA는 표시기에 대한 액세스가 필요합니다. IndicatorCreate(...) 또는 iCustome(...) 또는 iMA(...)와 같은 표준 표시기인 경우 최소한 세 가지 방법으로 얻을 수 있습니다.
내가 알기로는 어떤 옵션을 사용할 때 받은 핸들(IndicatorRelease)을 명시적으로 해제해야 합니다.
문제는 지표를 호출하는 방법을 선택하는 것입니다. 각 방법의 장단점은 무엇입니까? 처리 속도에 대한 우선 순위 관심.
IndicatorCreate - 표준 표시기의 경우 손 제스처의 경우 iMA 호출과 유사합니다. iCustom - "커스텀" 커스텀 인디케이터용. 저것들. 본질적으로 다른 것들.
iMA와 IndicatorCreate(IND_MA)를 호출하는 속도는 비슷해야 하지만 테스트하지 않았습니다.
IndicatorRelease와 관련하여 - 계산 후 더 이상 이 칠면조로 돌아갈 필요가 없는 경우 전화하는 것이 좋습니다. 나는 그런 상황이 없습니다. 어떤 종류의 칠면조가 필요한 경우(주어진 매개변수 세트 사용), 재계산/재계산에 필요하며 스크립트 입력 매개변수가 변경되면 모든 것이 다시 초기화되고 새 핸들이 됩니다. 생성됩니다.
사실 99%의 경우 IndicatorRelease에 대한 호출 은 프로그래머의 논리적 오류입니다.
지표 생성은 매우 심층적인 계산 메커니즘을 유발하는 가장 비용이 많이 드는 작업 중 하나입니다. 표시기 핸들을 닫는 것도 구현의 실제 깊은 프로세스를 생각하면 매우 비용이 많이 드는 작업입니다. 표시기의 빈번한 생성 및 닫기는 개발자가 작업의 본질을 전혀 이해하지 못한다는 것을 나타냅니다.
이것은 매우 이해하기 쉽습니다.
사실 99%의 경우 IndicatorRelease에 대한 호출 은 프로그래머의 논리적 오류입니다.
지표 생성은 매우 심층적인 계산 메커니즘을 유발하는 가장 비용이 많이 드는 작업 중 하나입니다. 표시기 핸들을 닫는 것도 구현의 실제 깊은 프로세스를 생각하면 매우 비용이 많이 드는 작업입니다. 표시기의 빈번한 생성 및 닫기는 개발자가 작업의 본질을 전혀 이해하지 못한다는 것을 나타냅니다.
이것은 매우 이해하기 쉽습니다.
대화에 개입하여 다음과 같이 말하겠습니다. 프로그램의 메커니즘, 터미널, 외환(사실, 우리가 여기에 있는 이유)
단순한 진실이기 때문에 우리가 그것들을 이해하고 루블을 깎는 것을 방해합니다. 또는 우리가 판매할 프로그램,
그리고 이것을 할 방법이 없다면 "기적"이 일어날 때까지 침묵해야 합니다!
대화에 개입하여 다음과 같이 말하겠습니다. 프로그램의 메커니즘, 터미널, 외환(사실, 우리가 여기에 있는 이유)
단순한 진실이기 때문에 우리가 그것들을 이해하고 루블을 깎는 것을 방해합니다. 또는 우리가 판매할 프로그램,
그리고 이것을 할 방법이 없다면 "기적"이 일어날 때까지 침묵해야 합니다!
이해할 수 없는 생각의 흐름을 보여주는 아름다운 예입니다. 이미 부러움은 그러한 능력을 앗아갑니다.
아마 80레벨 제다이, 마스터 요다는 옆에서 조용히 명상을 하고 있을 겁니다 :)
그리고 당신은 "그들은 노숙자 아이들을 도왔습니다"(c) 12개의 의자를 파낼 수 없습니다.
얼마 전, 내 작업 코드가 컴파일을 멈췄습니다.
표준 라이브러리의 코드에 맹세합니다.
아마도 내 코드에서 다음과 같은 사실 때문일 것입니다.내 프로그램이 다시 작동하도록 어떻게 이것을 "소화"할 수 있습니까? 새 MQL 빌드에서 변경된 사항을 잘 이해하지 못합니다.
가져온 함수는 내장 함수와 같은 이름을 가질 수 없습니까? 그럼 어떻게 살아야 할까요?
내 프로그램이 다시 작동하도록 어떻게 이것을 "소화"할 수 있습니까? 새 MQL 빌드에서 변경된 사항을 잘 이해하지 못합니다.
내부에 매개변수를 추가하기만 하면 됩니다.
내부에 매개변수를 추가하기만 하면 됩니다.
기능이나 자동 버그라고 생각합시다.
이름을 변경하여 꺼내서 별도의 라이브러리에 포장할 수 있습니다.
명명된 공백을 요청할 수도 있지만 아마도 쓸모가 없을 것입니다.