Stanislav Korotky : 공통 문제를 해결하는 소규모 사람들의 수를 곱하면(한계에서 무한한 횟수 ;-)) 터미널 자체의 편집 옵션에 필요한 시간. 가상의 라이브러리가 있다고 해서 모든 사람이 라이브러리의 존재와 사용 필요성을 인식하게 되는 것은 아닙니다. 일반적으로 그러한 "갈퀴"를 만들고 떠나는 이유가 명확하지 않습니까?
따라서 이것은 갈퀴가 아니라 지표의 새 복사본이 이전 복사본에 대해 알지 못하는 경우의 논리적 동작입니다. 이것은 논리적입니다!
그러나 UNITS의 사람들은 추가 비용을 원합니다. 복사본이 여전히 알 수 있도록 기능! 그렇다면 이러한 단위가 솔루션을 한 번 작성하고 사용하지 못하게 하는 것은 무엇입니까?
남을 배려하는 척하는 이유. 정말 필요한 사람은 먼저 솔루션을 찾습니다. 그리고 그렇지 않다면 쓰기를 시도하십시오. 중앙 집중식 코드베이스는 정확히 이러한 목적을 수행합니다.
따라서 이것은 갈퀴가 아니라 지표의 새 복사본이 이전 복사본에 대해 알지 못하는 경우의 논리적 동작입니다. 이것은 논리적입니다!
그러나 UNITS의 사람들은 추가 비용을 원합니다. 복사본이 여전히 알 수 있도록 기능! 그렇다면 이러한 단위가 솔루션을 한 번 작성하고 사용하지 못하게 하는 것은 무엇입니까?
남을 배려하는 척하는 이유. 그것을 정말로 필요로 하는 사람들은 먼저 해결책을 찾을 것입니다. 그리고 그렇지 않다면 쓰기를 시도하십시오. 중앙 집중식 코드베이스는 정확히 이러한 목적을 수행합니다.
아니, 그렇게 간단하지 않습니다. 지표는 다른 엔터티(차트/차트) 내부에 있으며 이에 종속됩니다(복잡한 일대다 관계를 알고 있지만 이것이 본질을 변경하지는 않습니다). 차트에는 표시기 수명 주기의 경계인 일부 내부 이벤트 init 및 deinit를 포함하여 자체 수명 주기가 있습니다. 즉, 지표는 차트에서 살아남을 수 없습니다. 차트 deinit는 모든 표시기의 deinit 또는 deinit 타임아웃을 기다려야 합니다. 그래야만 새 시간 프레임에 대한 차트 초기화가 시작될 수 있으며 여기에서 중첩 표시기의 초기화를 호출할 수 있습니다.
갈퀴는 정의상 밟을 수 있는 것입니다. 이미 도착했습니다. 좋은 소프트웨어는 원칙적으로 갈퀴를 허용하지 않습니다.
그러면 Deinit는 작업을 완료하고 모든 것을 망칠 것입니다. 일반 Init 및 Deinit에서 사용자 정의 init 및 deinit를 만드는 것은 의미가 없습니다.
또한이 문제에 직면했습니다. (
fxsaber 는 이미 모든 것을 그렸지만 나 자신에게서 더 많은 것을 추가할 것입니다.
모든 MT 프로그램의 특징은 이벤트 기반 운영입니다. 여기에서 OnInit 및 OnDeinit는 이벤트 모델에 따라 상당히 논리적이고 적절하게 작동합니다.
그러나 입력 변수의 동작에는 이해할 수 없는 뉘앙스가 있습니다. 내부 터미널 표시기와 표준 제공과 함께 제공되는 표시기를 포함한 모든 표준 표시기는 마지막 실행 이후에 업로드된 동일한 입력 매개변수로 매번 실행됩니다. 그것은 매우 편안합니다. 그러나 이것은 사용자 지정 표시기 및 모든 Expert Advisors 및 스크립트(표준 표시기 포함)의 경우가 아니므로 차트에 약간의 불편이 있습니다( MQ: 표준 표시기의 경우와 동일한 입력 변수 동작 추가 ).
그러나 init 및 deinit 작업과 관련하여 개인적으로 프로그램의 전역 변수로 작업할 때 프로그램의 초기화 해제 이유에 의존하지 않으며 항상 프로그램의 특정 아이디어에 따라 논리를 구축합니다. 예를 들어 Expert Advisor의 초기화 해제 후 전역 프로그램 변수를 저장해야 하는 경우가 매우 많습니다(이유는 다를 수 있고, 동일한 연결 끊김은 OnDeinit 및 후속 OnInit의 원인이 됨). 그래서 왜 모든 것을 다시 계산하고 새 지표를 생성합니까? 손잡이 등?
따라서 앞에서 작성한 fxsaber 와 같이 특정 경우에 프로그램의 전역 변수를 저장해야 하는 경우 적절한 플래그를 사용하여 터미널의 전역 변수에서 이를 수행할 수 있습니다.
MQL에서는 불행히도 모든 것이 순조롭게 진행되는 것은 아니지만 OnInit과 Ondeinit의 작업은 논리적이고 이해하기 쉬우므로 헛되이 울타리 너머로 그림자를 드리우고 있습니다.)
Deinit 에서 모든 데이터의 기록을 globals에 등록합니다. 동시에 GlobalVariableSetOnCondition을 통해 하나의 전역을 세마포어로 설정합니다.
Init에서 세마포어가 "데이터 재설정" 상태에 있으면 세마포어를 "모두 읽기" 상태로 설정하여 읽고 작업한다고 작성합니다.
세마포어가 "이해할 수 없음" 상태에 있으면 세마포어를 기다립니다(루핑된 Sleep 또는 OnTimer를 통해).
물론 세마포어가 완전히 없으면 이는 우리가 처음으로 시작했고 미래의 TF 변경 사항이 아닌 세마포어를 동시에 생성하여 모든 것을 고려한다는 것을 의미합니다.
그러한 구현에서 어려운 점은 무엇입니까? 한 번 라이브러리는 처방하고 그게 다야.
수면이 지표에서 작동했다면 더 쉬웠을 것입니다. 수면 표시기가 작동하지 않습니다.
공통 문제를 해결하는 소규모 사람들의 수를 곱하면(한계에서 무한한 횟수 ;-)) 터미널 자체의 편집 옵션에 필요한 시간. 가상의 라이브러리가 있다고 해서 모든 사람이 라이브러리의 존재와 사용 필요성을 인식하게 되는 것은 아닙니다. 일반적으로 그러한 "갈퀴"를 만들고 떠나는 이유가 명확하지 않습니까?
따라서 이것은 갈퀴가 아니라 지표의 새 복사본이 이전 복사본에 대해 알지 못하는 경우의 논리적 동작입니다. 이것은 논리적입니다!
그러나 UNITS의 사람들은 추가 비용을 원합니다. 복사본이 여전히 알 수 있도록 기능! 그렇다면 이러한 단위가 솔루션을 한 번 작성하고 사용하지 못하게 하는 것은 무엇입니까?
남을 배려하는 척하는 이유. 정말 필요한 사람은 먼저 솔루션을 찾습니다. 그리고 그렇지 않다면 쓰기를 시도하십시오. 중앙 집중식 코드베이스는 정확히 이러한 목적을 수행합니다.
수면이 지표에서 작동했다면 더 쉬웠을 것입니다. 수면 표시기가 작동하지 않습니다.
따라서 이것은 갈퀴가 아니라 지표의 새 복사본이 이전 복사본에 대해 알지 못하는 경우의 논리적 동작입니다. 이것은 논리적입니다!
그러나 UNITS의 사람들은 추가 비용을 원합니다. 복사본이 여전히 알 수 있도록 기능! 그렇다면 이러한 단위가 솔루션을 한 번 작성하고 사용하지 못하게 하는 것은 무엇입니까?
남을 배려하는 척하는 이유. 그것을 정말로 필요로 하는 사람들은 먼저 해결책을 찾을 것입니다. 그리고 그렇지 않다면 쓰기를 시도하십시오. 중앙 집중식 코드베이스는 정확히 이러한 목적을 수행합니다.
아니, 그렇게 간단하지 않습니다. 지표는 다른 엔터티(차트/차트) 내부에 있으며 이에 종속됩니다(복잡한 일대다 관계를 알고 있지만 이것이 본질을 변경하지는 않습니다). 차트에는 표시기 수명 주기의 경계인 일부 내부 이벤트 init 및 deinit를 포함하여 자체 수명 주기가 있습니다. 즉, 지표는 차트에서 살아남을 수 없습니다. 차트 deinit는 모든 표시기의 deinit 또는 deinit 타임아웃을 기다려야 합니다. 그래야만 새 시간 프레임에 대한 차트 초기화가 시작될 수 있으며 여기에서 중첩 표시기의 초기화를 호출할 수 있습니다.
갈퀴는 정의상 밟을 수 있는 것입니다. 이미 도착했습니다. 좋은 소프트웨어는 원칙적으로 갈퀴를 허용하지 않습니다.
따라서 이것은 갈퀴가 아니라 지표의 새 복사본이 이전 지표에 대해 알지 못하는 경우의 논리적 동작입니다. 이것은 논리적입니다!
그러나 UNITS의 사람들은 추가 비용을 원합니다. 복사본이 여전히 알 수 있도록 기능! 그렇다면 이러한 단위가 솔루션을 한 번 작성하고 사용하지 못하게 하는 것은 무엇입니까?
남을 배려하는 척하는 이유. 정말 필요한 사람은 먼저 솔루션을 찾습니다. 그리고 그렇지 않다면 쓰기를 시도하십시오. 중앙 집중식 코드베이스는 정확히 이러한 목적을 수행합니다.
시간대를 전환할 때 새 매개변수에 입력 매개변수를 입력할 때 어떻게 알 수 없습니까?
그러면 Deinit는 작업을 완료하고 모든 것을 망칠 것입니다. 일반 Init 및 Deinit에서 사용자 정의 init 및 deinit를 만드는 것은 의미가 없습니다.
또한이 문제에 직면했습니다. (
fxsaber 는 이미 모든 것을 그렸지만 나 자신에게서 더 많은 것을 추가할 것입니다.
모든 MT 프로그램의 특징은 이벤트 기반 운영입니다. 여기에서 OnInit 및 OnDeinit는 이벤트 모델에 따라 상당히 논리적이고 적절하게 작동합니다.
그러나 입력 변수의 동작에는 이해할 수 없는 뉘앙스가 있습니다. 내부 터미널 표시기와 표준 제공과 함께 제공되는 표시기를 포함한 모든 표준 표시기는 마지막 실행 이후에 업로드된 동일한 입력 매개변수로 매번 실행됩니다. 그것은 매우 편안합니다. 그러나 이것은 사용자 지정 표시기 및 모든 Expert Advisors 및 스크립트(표준 표시기 포함)의 경우가 아니므로 차트에 약간의 불편이 있습니다( MQ: 표준 표시기의 경우와 동일한 입력 변수 동작 추가 ).
그러나 init 및 deinit 작업과 관련하여 개인적으로 프로그램의 전역 변수로 작업할 때 프로그램의 초기화 해제 이유에 의존하지 않으며 항상 프로그램의 특정 아이디어에 따라 논리를 구축합니다. 예를 들어 Expert Advisor의 초기화 해제 후 전역 프로그램 변수를 저장해야 하는 경우가 매우 많습니다(이유는 다를 수 있고, 동일한 연결 끊김은 OnDeinit 및 후속 OnInit의 원인이 됨). 그래서 왜 모든 것을 다시 계산하고 새 지표를 생성합니까? 손잡이 등?
따라서 앞에서 작성한 fxsaber 와 같이 특정 경우에 프로그램의 전역 변수를 저장해야 하는 경우 적절한 플래그를 사용하여 터미널의 전역 변수에서 이를 수행할 수 있습니다.
MQL에서는 불행히도 모든 것이 순조롭게 진행되는 것은 아니지만 OnInit과 Ondeinit의 작업은 논리적이고 이해하기 쉬우므로 헛되이 울타리 너머로 그림자를 드리우고 있습니다.)
시간대를 전환할 때 새 매개변수에 입력 매개변수를 입력할 때 어떻게 알 수 없습니까?
그러나 OnInit 및 Ondeinit의 작업은 논리적이고 이해할 수 있으므로 헛되이 여기 울타리에 그림자를 둡니다.)
타임프레임 전환 시 인디케이터에서 OnInit, OnDeinit 실행 순서 로직을 설명해주세요. 나는 매우 감사하게 될 것입니다. 그리고 저 뿐만이 아니라고 생각합니다.
타임프레임 전환 시 인디케이터에서 OnInit, OnDeinit 실행 순서 로직을 설명해주세요. 나는 매우 감사하게 될 것입니다. 그리고 저 뿐만이 아니라고 생각합니다.
남. 영광은 모든 것을 분명히 말했습니다.
표시기의 사본이 생성되고 잠시 후 이전 표시기가 언로드됩니다.
프로그램의 전역 변수를 저장해야 하는 경우 OnInit를 호출할 때 미리 이를 처리해야 합니다(전역 터미널 변수는 이 목적에 매우 적합합니다).
그리고 표시기 버퍼는 막대(촛대)가 변경되었기 때문에 어떤 경우에도 다시 계산됩니다. 분명히 이것이 발생하는 이유입니다(복사본 시작 및 터미널에 의한 표시기의 이전 인스턴스 완료).
표시기 개발자가 그래픽 개체로 작업하는 데 문제가 있는 경우 표시기를 시작할 때 그래픽 개체의 이름을 TF의 이름에 연결해야 합니다. 그러면 표시기의 새 복사본이 새 개체를 만들고 이전 표시기의 복사본은 이전 표시기를 정리합니다.
전혀 문제가 없습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
Init() 및 DeInit() 실행 순서
슬라바 , 2017.04.07 15:31
어떤 논리가 망쳐 놓았습니까?
기간을 변경할 때 표시기의 새 복사본이 생성되며 이전 복사본에 대해서는 전혀 알지 못합니다. 얼마 동안(매우 짧은 시간) 표시기의 두 복사본이 병렬로 존재합니다. 그런 다음 이전 복사본이 언로드됩니다.
문서 읽기 https://www.mql5.com/ru/docs/runtime/running
남. 영광은 모든 것을 분명히 말했습니다.
표시기의 사본이 생성되고 잠시 후 이전 표시기가 언로드됩니다.
프로그램의 전역 변수를 저장해야 하는 경우 OnInit를 호출할 때 미리 이를 처리해야 합니다(전역 터미널 변수는 이 목적에 매우 적합합니다).
그리고 표시기 버퍼는 막대(촛대)가 변경되었기 때문에 어떤 경우에도 다시 계산됩니다. 분명히 이것이 발생하는 이유입니다(복사본 시작 및 터미널에 의한 표시기의 이전 인스턴스 완료).
표시기 개발자가 그래픽 개체로 작업하는 데 문제가 있는 경우 표시기를 시작할 때 그래픽 개체의 이름을 TF의 이름에 연결해야 합니다. 그러면 표시기의 새 복사본이 새 개체를 만들고 이전 표시기의 복사본은 이전 표시기를 정리합니다.
전혀 문제가 없습니다.
예, 모든 것이 명확합니다. 실행 순서 로직에 대해 질문했습니다. 그녀는 존재하지 않는다는 것입니다. 때로는 첫 번째 OnDeinit(일반인의 논리에 따라야 함)에 의해 실행되고 때로는 첫 번째 OnInit에 의해 실행됩니다.
나는 그 답이 " 얼마 동안(매우 짧은 시간 동안) 지표의 두 복사본이 병렬로 존재한다"는 말에 있다는 것을 이해합니다. 그러나 이 깨달음으로부터 이 질문은 명확하지 않다.