아니, 그렇게 간단하지 않습니다. 지표는 다른 엔터티(차트/차트) 내부에 있으며 이에 종속됩니다(복잡한 일대다 관계를 알고 있지만 이것이 본질을 변경하지는 않습니다). 차트에는 표시기 수명 주기의 경계인 일부 내부 이벤트 init 및 deinit를 포함하여 자체 수명 주기가 있습니다. 즉, 지표는 차트에서 살아남을 수 없습니다. 차트 deinit는 모든 표시기의 deinit 또는 deinit 타임아웃을 기다려야 합니다. 그래야만 새 시간 프레임에 대한 차트 초기화가 시작될 수 있으며 여기에서 중첩 표시기의 초기화를 호출할 수 있습니다.
표시기/EA의 OnInit 전에 전역 개체의 생성자가 실행됩니다. OnDeinit 이후 - 소멸자. 따라서 OnInit 및 OnDeinit는 모든 표시기에서 생략할 수 있습니다.
유일한 문제는 지표에 대한 아이디어가 현실과 일치하지 않는다는 것입니다. 아마도 이 동작은 솔루션을 작성할 수 없는 일부 프리랜서에게 중요합니다.
개발자들이 이 주제에 대해 한 걸음 더 나아간 것을 환영합니다. 그러나 여기에서 서로 완전히 이해되는 두 가지 관점이 당연히 있어야 할 자신의 논리와 충돌했습니다. 그들 중 누구도 다른 것보다 나쁘지 않습니다. 어떤 사람들은 이것이 옳다고 생각하고 다른 사람들은 그렇게 생각합니다.
나는 다시 반복한다. 기간 또는 기호를 변경할 때 차트에 대한 지표의 새 복사본이 생성됩니다. 새로운 .
지표의 계산된 부분이 히스토리 캐시에 있는 바로 그 이유입니다. 각 시간대에는 자체 막대 캐시가 있습니다. 시간 프레임을 변경할 때 EURUSD,M1을 EURUSD,H1로 가정하면 이유 3(차트 변경)이 있는 Deinit 이벤트가 M1 캐시의 표시기로 전송되고 잠시 후 이 표시기가 언로드됩니다. 갑자기 이 표시기가 이유 3으로 Deinit를 처리할 시간이 없다면 언로드할 때 이미 이유 1(차트 닫기)로 초기화 해제됩니다. 지금까지 H1 캐시가 없으면 생성됩니다. 그런 다음 표시기의 새 복사본이 H1 캐시에 로드되어 Init 이벤트가 전송됩니다. 표시기의 새 복사본은 곧 죽게 될 이전 복사본에 대해 아무것도 모릅니다. 지표의 새 복사본에서 모든 변수는 깨끗하고 방금 태어난 것입니다.
하나의 심볼 내에서 기간 변경이 있는 경우 초기화-비초기화 순서는 기본적으로 예측 가능합니다. 최신 빌드 1580 다운로드 - 거기에서 수정했습니다. 이제 표시기가 마지막으로 제거되었으므로 조기 초기화가 없어야 합니다. 그러나 기호를 변경하면 스레드 간 경쟁이 순수한 형태로 얻어지며 더 이상 초기화-비초기화 순서를 명확하게 예측할 수 없습니다. 서로 다른 문자가 서로 다른 스레드에서 처리되기 때문에
따라서 토픽 스타터를 위한 조언. 초기화 해제 이유에 초점을 맞춥니다. 3과 같으면 색 구성표를 그래픽으로 되돌릴 필요가 없습니다.
TF를 변경 하기 전에 터미널이 이전 TF에서 모든 표시기가 언로드될 때까지 기다렸다가 새 TF를 빌드하고 초기화하면 차트 속도가 얼마나 느려질지 상상해 보십시오.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
속도가 느려지는 이유는 무엇입니까? 표시가 비스듬하게 쓰여지지 않는 한. 일반적으로 작성된 표시기의 경우 DeInit는 상당한 시간이 걸립니다. 게다가, 스위칭 TF는 그렇게 빈번한 작업이 아니다. 일부 특히 심각한 경우(이것은 "잘못된" 표시기에 해당) TF를 변경할 때 1~2초 정도 기다릴 수 있습니다.
따라서 TF를 전환할 때 제동에 대한 논쟁은 의심의 여지가 없습니다. 또한 아직 구축되지 않은 TF로 전환할 때 다소 눈에 띄는 시간 지연도 감지됩니다. 그리고 아무도 터미널의 브레이크에 대해 울지 않습니다.
예, 모든 것이 명확합니다. 실행 순서 로직에 대해 질문했습니다. 그녀는 존재하지 않는다는 것입니다. 때로는 첫 번째 OnDeinit(일반인의 논리에 따라야 함)에 의해 실행되고 때로는 첫 번째 OnInit에 의해 실행됩니다.
나는 그 답이 " 얼마 동안(매우 짧은 시간 동안) 지표의 두 복사본이 병렬로 존재한다"는 말에 있다는 것을 이해합니다. 그러나 이 깨달음으로부터 이 질문은 명확하지 않다.
OnInit 함수 는 프로그램에서 가장 먼저 실행된다고 가정합니다.
OnInit -> OnDeinit 시퀀스가 항상 실행되지 않는 경우를 예로 들 수 있습니까?
OnInit 함수 는 프로그램에서 가장 먼저 실행된다고 가정합니다.
OnInit -> OnDeinit 시퀀스가 항상 실행되지 않는 경우를 예로 들 수 있습니까?
처음에 제공한 ERROR.mq5 테마 작성자의 예제를 사용할 수 있습니다 . 스위치 TF. 전문가 탭에서 무슨 일이 일어나고 있는지 확인하십시오.
처음에 제공 한 ERROR.mq5 테마 작성자의 예를 사용할 수 있습니다.
나는 낮에 노래를 부른다. 그리고 당신은 개인적으로 이미 poyuzali?
물론 9개월 전에도 사용했습니다. 이 스레드에서 내 의견 #8 을 읽을 수 있습니다.
아니, 그렇게 간단하지 않습니다. 지표는 다른 엔터티(차트/차트) 내부에 있으며 이에 종속됩니다(복잡한 일대다 관계를 알고 있지만 이것이 본질을 변경하지는 않습니다). 차트에는 표시기 수명 주기의 경계인 일부 내부 이벤트 init 및 deinit를 포함하여 자체 수명 주기가 있습니다. 즉, 지표는 차트에서 살아남을 수 없습니다. 차트 deinit는 모든 표시기의 deinit 또는 deinit 타임아웃을 기다려야 합니다. 그래야만 새 시간 프레임에 대한 차트 초기화가 시작될 수 있으며 여기에서 중첩 표시기의 초기화를 호출할 수 있습니다.
차트는 동일한 지표 입니다. 지표는 차트를 "오래 지속"할 수 있습니다.
표시기/EA의 OnInit 전에 전역 개체의 생성자가 실행됩니다. OnDeinit 이후 - 소멸자. 따라서 OnInit 및 OnDeinit는 모든 표시기에서 생략할 수 있습니다.
유일한 문제는 지표에 대한 아이디어가 현실과 일치하지 않는다는 것입니다. 아마도 이 동작은 솔루션을 작성할 수 없는 일부 프리랜서에게 중요합니다.
개발자들이 이 주제에 대해 한 걸음 더 나아간 것을 환영합니다. 그러나 여기에서 서로 완전히 이해되는 두 가지 관점이 당연히 있어야 할 자신의 논리와 충돌했습니다. 그들 중 누구도 다른 것보다 나쁘지 않습니다. 어떤 사람들은 이것이 옳다고 생각하고 다른 사람들은 그렇게 생각합니다.
TF를 변경 하기 전에 터미널이 이전 TF에서 모든 표시기가 언로드될 때까지 기다렸다가 새 TF를 빌드하고 초기화하면 차트 속도가 얼마나 느려질지 상상해 보십시오.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(제목에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
TF를 변경 하기 전에 터미널이 이전 TF에서 모든 표시기가 언로드될 때까지 기다렸다가 새 TF를 빌드하고 초기화하면 차트 속도가 얼마나 느려질지 상상해 보십시오.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
+
나는 다시 반복한다. 기간 또는 기호를 변경할 때 차트에 대한 지표의 새 복사본이 생성됩니다. 새로운 .
지표의 계산된 부분이 히스토리 캐시에 있는 바로 그 이유입니다. 각 시간대에는 자체 막대 캐시가 있습니다. 시간 프레임을 변경할 때 EURUSD,M1을 EURUSD,H1로 가정하면 이유 3(차트 변경)이 있는 Deinit 이벤트가 M1 캐시의 표시기로 전송되고 잠시 후 이 표시기가 언로드됩니다. 갑자기 이 표시기가 이유 3으로 Deinit를 처리할 시간이 없다면 언로드할 때 이미 이유 1(차트 닫기)로 초기화 해제됩니다. 지금까지 H1 캐시가 없으면 생성됩니다. 그런 다음 표시기의 새 복사본이 H1 캐시에 로드되어 Init 이벤트가 전송됩니다. 표시기의 새 복사본은 곧 죽게 될 이전 복사본에 대해 아무것도 모릅니다. 지표의 새 복사본에서 모든 변수는 깨끗하고 방금 태어난 것입니다.
하나의 심볼 내에서 기간 변경이 있는 경우 초기화-비초기화 순서는 기본적으로 예측 가능합니다. 최신 빌드 1580 다운로드 - 거기에서 수정했습니다. 이제 표시기가 마지막으로 제거되었으므로 조기 초기화가 없어야 합니다. 그러나 기호를 변경하면 스레드 간 경쟁이 순수한 형태로 얻어지며 더 이상 초기화-비초기화 순서를 명확하게 예측할 수 없습니다. 서로 다른 문자가 서로 다른 스레드에서 처리되기 때문에
따라서 토픽 스타터를 위한 조언. 초기화 해제 이유에 초점을 맞춥니다. 3과 같으면 색 구성표를 그래픽으로 되돌릴 필요가 없습니다.
TF를 변경 하기 전에 터미널이 이전 TF에서 모든 표시기가 언로드될 때까지 기다렸다가 새 TF를 빌드하고 초기화하면 차트 속도가 얼마나 느려질지 상상해 보십시오.
어떤 상황에서 그래프로 직접 작업하는 것을 제외하고. 개체(이름에 TF 이름 없음), DeInit - Init 시퀀스가 중요합니까?
속도가 느려지는 이유는 무엇입니까? 표시가 비스듬하게 쓰여지지 않는 한. 일반적으로 작성된 표시기의 경우 DeInit는 상당한 시간이 걸립니다. 게다가, 스위칭 TF는 그렇게 빈번한 작업이 아니다. 일부 특히 심각한 경우(이것은 "잘못된" 표시기에 해당) TF를 변경할 때 1~2초 정도 기다릴 수 있습니다.
따라서 TF를 전환할 때 제동에 대한 논쟁은 의심의 여지가 없습니다. 또한 아직 구축되지 않은 TF로 전환할 때 다소 눈에 띄는 시간 지연도 감지됩니다. 그리고 아무도 터미널의 브레이크에 대해 울지 않습니다.