서비스 또는 하나의 차트에서 여러 Expert Advisors를 실행하는 기능이 논의된 문제를 완전히 커버할 수 없는 이유는 무엇입니까?
글쎄, 문제는 남아있을 것입니다. 이것은 새로운 유형의 MQL 프로그램이 다른 유형의 MQL 프로그램의 문제를 수정하지 않는다는 것을 의미합니다. 좋은 소프트웨어는 사용자에게 실수할 기회를 주지 않습니다. 물론 도움말에서 행동의 불확실성에 대한 문구를 작성하는 것이 더 쉽습니다. 익사한 자의 구원은 익사한 자의 일이다.
No Decision은 "해결 방법이 아직 알려져 있지 않다"가 아니라 "그렇지 않을 것이다"를 의미한다.
그리고 커스텀 이벤트로 전혀 문제 없습니다
서비스 또는 하나의 차트에서 여러 Expert Advisors를 실행하는 기능이 논의된 문제를 완전히 커버할 수 없는 이유는 무엇입니까?
익사한 자의 구원은 익사한 자의 일이다.
TF를 변경할 때 deinit 및 init 실행 순서 문제에 대한 건설적인 논의와 관련이 없기 때문에 메시지 125부터 시작하는 모든 것을 삭제할 것을 제안합니다.
실제로 한 표시기의 경우 init가 먼저 수행된 다음 deinit가 수행됩니다. 그러나 시간대가 전환되면 표시기의 두 번째 인스턴스가 생성되고 해당 init는 이전(차트에서 제거된) 인스턴스의 deinit보다 먼저 실행할 수 있습니다.
가장 확실한 예는 시간 프레임을 전환할 때 사용자 매개변수 를 저장하는 것입니다. 매개변수를 deinit에 저장하고 init에서 읽습니다. 새 인스턴스의 초기화가 이전 인스턴스의 초기화보다 먼저 작동했다면 매개변수가 저장되지 않습니다.
실제로 제거된 인스턴스의 초기화 해제는 기본적으로 새 인스턴스의 초기화 이전에 작동하지만 시간 프레임이 매우 빠르게 전환되거나 데이터가 로드되면 실패가 발생합니다.
드미트리, 그리고 당신이 차를 운전할 때 이미 도착했을 때 백미러도 볼 필요가 있습니까? 또는 표시기에 필요한 매개변수를 주기적으로 저장하십시오. 백미러를 보는 것과 같습니다.
물론 물에 빠진 사람이 구명 부표를 던졌을 때 돌이 구조에 계속 기여하지 못한다고 계속해서 불평할 수 있습니다.
갈퀴가 남아 있습니다. 이것이 핵심입니다. (이 비유에서 요구에 따라 보트 정류장에서 원이 발행되고 사람들은 임의의 장소에서 예기치 않게 자신을 위해 익사합니다).
이전 기능에서 모든 것이 순서대로 되어 있지 않다면 새 기능에서도 비슷할 것입니다. 접근 방식은 변경되지 않습니다.
일반적으로 나는 합리적이고 논리적으로 모든 것을 IMHO로 진술했습니다. 누군가 탱크에 있으면 내가 도울 수 있는 것이 없습니다.
이전 기능에서 모든 것이 순서대로 되어 있지 않다면 새 기능에서도 비슷할 것입니다. 접근 방식은 변경되지 않습니다.
즉, 차트 의 기호 -주기를 변경할 때 표시기의 OnInit 및 OnDeinit 실행 순서는 누구도 걱정하지 않아도 됩니다.
init에서 타이머를 시작하고 deinite에서 삭제합니다. 잘못된 주문의 결과로 무엇을 이해하지 못합니다.
개발자가 솔직히 무시하는 불쾌한 버그
init에서 타이머를 시작하고 deinite에서 삭제합니다. 잘못된 주문의 결과로 무엇을 이해하지 못합니다.
개발자가 솔직히 무시하는 불쾌한 버그
순서는 동일합니다.
변경할 때 tf.
표시기가 이전 TF의 버퍼에 남아 있으면 타이머에도 영향을 줄 수 있습니다. 글쎄요, 금요일 정신 착란과 같은 것입니다.