Renat : 비정상 종료는 Expert Advisor가 루프되고 IsStopped를 확인하지 않고 터미널에 의해 강제로 중지됨을 의미합니다.
비정상 종료는 MQL 코드뿐만 아니라 런타임 자체의 내부 정지 때문에 발생하는 것을 볼 수 있습니다. 따라서 MQL 비정상 종료에서 제어되지 않는다고 가정해 보겠습니다.
예를 들어 MQL 코드가 ObjectDelete 명령을 보내 더 이상 존재하지 않는 차트(객체도 차트도 아님)에서 객체를 삭제하는 경우입니다. 그러나 명령을 보낼 당시 그는 있었다. 그리고 MQL 실행 내에서 코드는 단순히 명령의 응답을 기다리지 않습니다. 끊기가 MQL 코드가 아니라 실행의 창자에서 발생했기 때문입니다. 즉, ObjectDelete 자체에서. 결과적으로 우리는 비정상적인 종료를 얻습니다. 두 번째 일반적인 경우는 ObjectsDeleteAll 함수의 작업입니다 . 동기식이므로 이미 삭제된 개체를 삭제할 때도 중단되지만 호출 후에만 중단됩니다. 세 번째 경우는 EA가 차트에서 제거되고 차트가 닫히기 때문에 런타임이 Deinit EA의 명령을 완료할 수 없는 가장 해로운 경우입니다. 우리는 또한 환경의 중단과 통제되지 않은 비정상 종료를 얻을 것입니다.
일반적으로 내가 설명한 모든 것은 특히 OnDeinit 함수에서 exp 작업의 완료에 관한 것입니다. 첫 번째 차트의 존재와 두 번째로 Expert Advisor의 Deinit 동안 환경의 행동과 같이 깊이 어딘가에 최종 조치와 불일치가 있습니다. 누군가는 비정상 종료 이전과 그 결과로 무언가를 합니다.
물론 가용성에 대한 추가 검사를 삽입하여 일부 경우를 해결할 수 있습니다. 그러나 드물게 설명된 동기화 문제 중 하나가 발생합니다. 닫으려는 차트의 지표를 삭제/설치하거나 개체를 삭제합니다.
Absolute Drawdown이 어떻게 초기 잔액보다 많을 수 있는지에 대한 답변을 얻고 싶습니다.
비록 정의상
Absolute Drawdown Просадка от начального баланса показывает, насколько уменьшался баланс относительно первоначального значения. Максимально может быть равно начальному балансу, если потеряны все деньги.
비정상 종료는 MQL 코드뿐만 아니라 런타임 자체의 내부 정지 때문에 발생하는 것을 볼 수 있습니다. 따라서 MQL 비정상 종료에서 제어되지 않는다고 가정해 보겠습니다.
예를 들어 MQL 코드가 ObjectDelete 명령을 보내 더 이상 존재하지 않는 차트(객체도 차트도 아님)에서 객체를 삭제하는 경우입니다. 그러나 명령을 보낼 당시 그는 있었다. 그리고 MQL 실행 내에서 코드는 단순히 명령의 응답을 기다리지 않습니다. 끊기가 MQL 코드가 아니라 실행의 창자에서 발생했기 때문입니다. 즉, ObjectDelete 자체에서. 결과적으로 우리는 비정상적인 종료를 얻습니다. 두 번째 일반적인 경우는 ObjectsDeleteAll 함수의 작업입니다 . 동기식이므로 이미 삭제된 개체를 삭제할 때도 중단되지만 호출 후에만 중단됩니다. 세 번째 경우는 EA가 차트에서 제거되고 차트가 닫히기 때문에 런타임이 Deinit EA의 명령을 완료할 수 없는 가장 해로운 경우입니다. 우리는 또한 환경의 중단과 통제되지 않은 비정상 종료를 얻을 것입니다.
일반적으로 내가 설명한 모든 것은 특히 OnDeinit 함수에서 exp 작업의 완료에 관한 것입니다. 첫 번째 차트의 존재와 두 번째로 Expert Advisor의 Deinit 동안 환경의 행동과 같이 깊이 어딘가에 최종 조치와 불일치가 있습니다. 누군가는 비정상 종료 이전과 그 결과로 무언가를 합니다.
물론 가용성에 대한 추가 검사를 삽입하여 일부 경우를 해결할 수 있습니다. 그러나 드물게 설명된 동기화 문제 중 하나가 발생합니다. 닫으려는 차트의 지표를 삭제/설치하거나 개체를 삭제합니다.
마술로 거래를 정렬하여 위치의 이익을 찾는 방법은 무엇입니까? 마법사가 없기 때문에 클로징 딜은 거기에 떨어지지 않습니다.
POSITION_IDENTIFIER
Position ID는 새로 개설된 각 Position에 할당되는 고유 번호로 평생 동안 변경되지 않습니다. 위치를 반대로 해도 위치 식별자는 변경되지 않습니다.
긴
DEAL_POSITION_ID
이 거래에 의해 개설, 수정 또는 마감된 직위 ID 입니다. 각 포지션에는 포지션의 전체 수명 동안 금융 상품에서 이루어진 모든 거래에 할당되는 고유 식별자가 있습니다.
긴
비정상 종료는 Expert Advisor가 루프되고 IsStopped를 확인하지 않고 터미널에 의해 강제로 중지됨을 의미합니다.
비정상 종료는 MQL 코드뿐만 아니라 런타임 자체의 내부 정지 때문에 발생하는 것을 볼 수 있습니다. 따라서 MQL 비정상 종료에서 제어되지 않는다고 가정해 보겠습니다.
예를 들어 MQL 코드가 ObjectDelete 명령을 보내 더 이상 존재하지 않는 차트(객체도 차트도 아님)에서 객체를 삭제하는 경우입니다. 그러나 명령을 보낼 당시 그는 있었다.
그리고 MQL 실행 내에서 코드는 단순히 명령의 응답을 기다리지 않습니다. 끊기가 MQL 코드가 아니라 실행의 창자에서 발생했기 때문입니다. 즉, ObjectDelete 자체에서. 결과적으로 우리는 비정상적인 종료를 얻습니다.
두 번째 일반적인 경우는 ObjectsDeleteAll 함수의 작업입니다 . 동기식이므로 이미 삭제된 개체를 삭제할 때도 중단되지만 호출 후에만 중단됩니다.
세 번째 경우는 EA가 차트에서 제거되고 차트가 닫히기 때문에 런타임이 Deinit EA의 명령을 완료할 수 없는 가장 해로운 경우입니다. 우리는 또한 환경의 중단과 통제되지 않은 비정상 종료를 얻을 것입니다.
일반적으로 내가 설명한 모든 것은 특히 OnDeinit 함수에서 exp 작업의 완료에 관한 것입니다. 첫 번째 차트의 존재와 두 번째로 Expert Advisor의 Deinit 동안 환경의 행동과 같이 깊이 어딘가에 최종 조치와 불일치가 있습니다.
누군가는 비정상 종료 이전과 그 결과로 무언가를 합니다.
물론 가용성에 대한 추가 검사를 삽입하여 일부 경우를 해결할 수 있습니다. 그러나 드물게 설명된 동기화 문제 중 하나가 발생합니다. 닫으려는 차트의 지표를 삭제/설치하거나 개체를 삭제합니다.
Absolute Drawdown이 어떻게 초기 잔액보다 많을 수 있는지에 대한 답변을 얻고 싶습니다.
비록 정의상
Absolute Drawdown
Просадка от начального баланса показывает, насколько уменьшался баланс относительно первоначального значения. Максимально может быть равно начальному балансу, если потеряны все деньги.
https://www.mql5.com/ru/forum/8996 주제에 자세히 설명되어 있습니다.
비정상 종료는 Expert Advisor가 루프되고 IsStopped를 확인하지 않고 터미널에 의해 강제로 중지됨을 의미합니다.
추측하지 않았다.
비정상 종료는 MQL 코드뿐만 아니라 런타임 자체의 내부 정지 때문에 발생하는 것을 볼 수 있습니다.
예, 놀라움이 많이 있습니다.
터미널이 멈추고 메모리 부족 으로 인해 어드바이저를 삭제할 수 없는 문제가 발생했습니다. 이 경우 로그의 항목조차도 항상 떨어지는 것은 아닙니다.
추측하지 않았다.
예, 놀라움이 많이 있습니다.
터미널이 멈추고 메모리 부족으로 인해 어드바이저를 삭제할 수 없는 문제가 발생했습니다. 이 경우 로그의 항목조차도 항상 떨어지는 것은 아닙니다.
POSITION_IDENTIFIER
Position ID는 새로 개설된 각 Position에 할당되는 고유 번호로 평생 동안 변경되지 않습니다. 위치를 반대로 해도 위치 식별자는 변경되지 않습니다.
긴
DEAL_POSITION_ID
이 거래에 의해 개설, 수정 또는 마감된 위치 ID 입니다. 각 포지션에는 포지션의 전체 수명 동안 금융 상품에서 이루어진 모든 거래에 할당되는 고유 식별자가 있습니다.
긴
내가 이해하는 한 이 주제 https://www.mql5.com/en/forum/8278 은 정확히 이 문제에 관한 것입니다.
아니요, 지표에 관한 것이었습니다.
그리고 어드바이저는 메모리 한도 초과로 이어지더니 그냥 조용히 단말기를 끊는다. 예를 들어, 지표가 있는 다양한 기호/기간의 차트가 많이 로드될 때 발생합니다.
비정상 종료는 MQL 코드뿐만 아니라 런타임 자체의 내부 정지 때문에 발생하는 것을 볼 수 있습니다. 따라서 MQL 비정상 종료에서 제어되지 않는다고 가정해 보겠습니다.
예를 들어 MQL 코드가 ObjectDelete 명령을 보내 더 이상 존재하지 않는 차트(객체도 차트도 아님)에서 객체를 삭제하는 경우입니다. 그러나 명령을 보낼 당시 그는 있었다.
그리고 MQL 실행 내에서 코드는 단순히 명령의 응답을 기다리지 않습니다. 끊기가 MQL 코드가 아니라 실행의 창자에서 발생했기 때문입니다. 즉, ObjectDelete 자체에서. 결과적으로 우리는 비정상적인 종료를 얻습니다.
두 번째 일반적인 경우는 ObjectsDeleteAll 함수의 작업입니다 . 동기식이므로 이미 삭제된 개체를 삭제할 때도 중단되지만 호출 후에만 중단됩니다.
세 번째 경우는 EA가 차트에서 제거되고 차트가 닫히기 때문에 런타임이 Deinit EA의 명령을 완료할 수 없는 가장 해로운 경우입니다. 우리는 또한 환경의 중단과 통제되지 않은 비정상 종료를 얻을 것입니다.
일반적으로 내가 설명한 모든 것은 특히 OnDeinit 함수에서 exp 작업의 완료에 관한 것입니다. 첫 번째 차트의 존재와 두 번째로 Expert Advisor의 Deinit 동안 환경의 행동과 같이 깊이 어딘가에 최종 조치와 불일치가 있습니다.
누군가는 비정상 종료 이전과 그 결과로 무언가를 합니다.
물론 가용성에 대한 추가 검사를 삽입하여 일부 경우를 해결할 수 있습니다. 그러나 드물게 설명된 동기화 문제 중 하나가 발생합니다. 닫으려는 차트의 지표를 삭제/설치하거나 개체를 삭제합니다.
아니요, 지표에 관한 것이었습니다.
그리고 어드바이저는 메모리 한도 초과로 이어지더니 그냥 조용히 단말기를 끊는다. 예를 들어, 지표가 있는 다양한 기호/기간의 차트가 많이 로드될 때 발생합니다.