OrderSendAsync에 대한 TRADE_RETCODE_PLACED는 터미널 응답입니다.
코드는 같더라도 완전히 다른 의미를 갖습니다. 대부분의 경우 개발자는 이 모호성을 수정할 것입니다.
따라서 이것을 이해하십시오.
적절한 맥락에서 필요합니다.
그렇다면 어떤 조건에서 OrderSend 기능을 사용하여 거래 요청을 보낼 때 서버가 TRADE_RETCODE_PLACED 코드를 반환해야 하는지 설명해주세요. 실제로 OrderSendAsync 함수에 대한 메모와 Roche의 답변으로 판단하면 이 동일한 TRADE_RETCODE_PLACED 코드는 터미널에서 서버로 요청을 성공적으로 전송했음을 나타냅니다. 즉, 요청이 서버로 크롤링되고 처리/검증이 시작되자마자 서버는 "처리 결과를 기반으로" 다른 "실제" 서버 코드를 생성해야 한다는 것이 밝혀졌습니다. 따라서 이 코드가 서버의 요청보다 앞선 요청 수명 단계에 속한다면 왜 서버(특히 서버)가 TRADE_RETCODE_PLACED 코드를 반환해야 하는지 아직 잘 모르겠습니다. 아니면 OrderSend 함수와 관련된 TRADE_RETCODE_PLACED 코드의 의미가 다른가요?
OrderSend는 서버와 터미널 모두에서 응답을 받을 수 있습니다(터미널 필터 통과에 실패한 경우).
다음을 올바르게 이해하고 있습니까?
터미널은 OrderSend의 요청을 확인하고 성공적으로 서버로 보냈고 retcode는 중간 값인 TRADE_RETCODE_PLACED를 받았습니다. 이 순간 연결이 중단 되고 OrderSend 함수가 반환할 수 있는 모든 것은 retcode 필드에 "고정"된 TRADE_RETCODE_PLACED 코드뿐입니까? 이것은 OrderSend가 TRADE_RETCODE_PLACED를 반환하는 경우의 예가 될 것입니까?
터미널은 OrderSend의 요청을 확인하고 성공적으로 서버로 보냈고 retcode는 중간 값인 TRADE_RETCODE_PLACED를 받았습니다. 이 순간 연결이 중단 되고 OrderSend 함수가 반환할 수 있는 모든 것은 retcode 필드에 "고정"된 TRADE_RETCODE_PLACED 코드뿐입니까? 이것은 OrderSend가 TRADE_RETCODE_PLACED를 반환하는 경우의 예가 될 것입니까?
그럴 수도 있겠지만, 나는 그것을 의심한다. 이러한 연결이 끊어지면 TimeOut-time 이후에 TRADE_RETCODE_TIMEOUT이 발생할 가능성이 큽니다.
솔직히 OrderSend의 경우에 이러한 지루함이 필요한 이유를 이해하지 못합니다. 아마도 개발자가 도움말에서 더 자세히 설명할 것입니다.
추신: MQL5에서 한 줄도 쓰지 않았습니다. 따라서 주제에 대한 모든 생각은 무시할 수 있습니다.
일반적으로 OrderSendAsync 입력은 Metatrader에 대한 기록 이벤트입니다. 거래 API가 존재하는 동안(Metatrader3(이전 API는 본 적이 없음)) Metatrader는 자체 언어로 구현하더라도 본질적으로 변경되지 않았습니다. OrderSendAsync는 Metaquotes의 거래 API에 대한 첫 번째 주요 변경 사항입니다.
이 이벤트에 대해 개발 회사를 진심으로 축하하며 비동기 모델을 적절한 유용성으로 가져오고 싶습니다!
한 계정 의 실행 대기열에 있는 동시 요청 수에는 제한이 있으며 앞으로도 계속될 것임을 유의하십시오. 틀리지 않았다면 지금은 16개 신청입니다.
비동기 작업은 다음 일괄 처리를 보내기 전에 이전 일괄 처리의 일부가 실행되기를 기다리는 "유효한 요청 수의 창"으로 주의 깊게 작동합니다. 또한 어리석은 / 테스트 플러딩에 대한 보호 기능이 있습니다. 지금까지 허용된 응용 프로그램의 수가 오버플로되면 오류가 발생합니다.
OrderSendAsync를 통한 새로운 비동기 작업 방법은 주요 문제를 해결합니다. 이를 통해 수십 가지 작업을 즉시 수행할 수 있습니다. 이것은 매우 강력한 도구이며 항상 서버와 브로커의 금지 가능성을 염두에 두고 신중하게 사용해야 합니다.
다음과 같이 설명해야 합니다.
OrderSend의 TRADE_RETCODE_PLACED는 서버 응답입니다.
OrderSendAsync에 대한 TRADE_RETCODE_PLACED는 터미널 응답입니다.
코드는 같더라도 완전히 다른 의미를 갖습니다. 대부분의 경우 개발자는 이 모호성을 수정할 것입니다.
따라서 이것을 이해하십시오.
적절한 맥락에서 필요합니다.
OrderSend는 서버와 터미널 모두에서 응답을 받을 수 있습니다(터미널 필터 통과에 실패한 경우).
OrderSendAsync 는 항상 터미널에서만 응답을 받습니다. 서버로부터 응답을 받으려면 onTrade에서 해당 이벤트를 잡아야 합니다.
OrderSend는 서버와 터미널 모두에서 응답을 받을 수 있습니다(터미널 필터 통과에 실패한 경우).
다음을 올바르게 이해하고 있습니까?
터미널은 OrderSend의 요청을 확인하고 성공적으로 서버로 보냈고 retcode는 중간 값인 TRADE_RETCODE_PLACED를 받았습니다. 이 순간 연결이 중단 되고 OrderSend 함수가 반환할 수 있는 모든 것은 retcode 필드에 "고정"된 TRADE_RETCODE_PLACED 코드뿐입니까? 이것은 OrderSend가 TRADE_RETCODE_PLACED를 반환하는 경우의 예가 될 것입니까?
다음을 올바르게 이해하고 있습니까?
터미널은 OrderSend의 요청을 확인하고 성공적으로 서버로 보냈고 retcode는 중간 값인 TRADE_RETCODE_PLACED를 받았습니다. 이 순간 연결이 중단 되고 OrderSend 함수가 반환할 수 있는 모든 것은 retcode 필드에 "고정"된 TRADE_RETCODE_PLACED 코드뿐입니까? 이것은 OrderSend가 TRADE_RETCODE_PLACED를 반환하는 경우의 예가 될 것입니까?
그럴 수도 있겠지만, 나는 그것을 의심한다. 이러한 연결이 끊어지면 TimeOut-time 이후에 TRADE_RETCODE_TIMEOUT이 발생할 가능성이 큽니다.
솔직히 OrderSend의 경우에 이러한 지루함이 필요한 이유를 이해하지 못합니다. 아마도 개발자가 도움말에서 더 자세히 설명할 것입니다.
추신: MQL5에서 한 줄도 쓰지 않았습니다. 따라서 주제에 대한 모든 생각은 무시할 수 있습니다.
... 모두 같은, 어떤 종류의 넌센스. 클라이언트 터미널 사용자 가이드(2012년 1월)에는 주문 단계 중 하나가 "배치" 단계이며 딜러가 주문을 수락했다고 명시되어 있습니다.
저것들. 그것은 이미 안전하게 서버에 도달했을 때 거래 요청의 수명 단계에 신호를 보낸 가이드에서 따릅니다. 그리고 OrderSendAsync() 함수에 대한 설명은 정반대로 TRADE_RETCODE_PLACED 코드가 서버 도착에 의존하지 않는다고 말합니다.
솔직히 OrderSend의 경우에 이러한 지루함이 필요한 이유를 이해하지 못합니다.
일반적으로 누구나 OrderSendAsync를 통해 순차적인 MyOrderSend를 작성할 수 있습니다.
이러한 구현을 통해 MyOrderSend는 표준 OrderSend와 완전히 일치합니다(표준 라이브러리의 OrderSendAsync를 통해 구현하여 API에서 간단히 폐지할 수 있음).
이러한 구현을 통해 MyOrderSend는 표준 OrderSend와 완전히 일치합니다(표준 라이브러리의 OrderSendAsync를 통해 구현하여 API에서 간단히 폐지할 수 있음).
일반적으로 OrderSendAsync 입력은 Metatrader에 대한 기록 이벤트입니다. 거래 API가 존재하는 동안(Metatrader3(이전 API는 본 적이 없음)) Metatrader는 자체 언어로 구현하더라도 본질적으로 변경되지 않았습니다. OrderSendAsync는 Metaquotes의 거래 API에 대한 첫 번째 주요 변경 사항입니다.
이 이벤트에 대해 개발 회사를 진심으로 축하하며 비동기 모델을 적절한 유용성으로 가져오고 싶습니다!
기술 메시지. 우리는 하나의 주제에서 흥미로운 진술을 수집합니다.
한 계정 의 실행 대기열에 있는 동시 요청 수에는 제한이 있으며 앞으로도 계속될 것임을 유의하십시오. 틀리지 않았다면 지금은 16개 신청입니다.
비동기 작업은 다음 일괄 처리를 보내기 전에 이전 일괄 처리의 일부가 실행되기를 기다리는 "유효한 요청 수의 창"으로 주의 깊게 작동합니다. 또한 어리석은 / 테스트 플러딩에 대한 보호 기능이 있습니다. 지금까지 허용된 응용 프로그램의 수가 오버플로되면 오류가 발생합니다.
OrderSendAsync를 통한 새로운 비동기 작업 방법은 주요 문제를 해결합니다. 이를 통해 수십 가지 작업을 즉시 수행할 수 있습니다. 이것은 매우 강력한 도구이며 항상 서버와 브로커의 금지 가능성을 염두에 두고 신중하게 사용해야 합니다.