거래 주문 의 비동기 처리는 이벤트를 통해 JForex API에서 오랫동안(처음부터) 완벽하게 구현되었습니다(각 거래 요청에 대해 정확히 무엇과 이유가 발생했는지 알 수 있습니다. 각 거래 요청에도 상태 플래그(생성됨(생성되었지만 아직 전송되지 않음) 서버로(예: 연결 실패)), 전달됨(서버에서 수락함), 진행 중, 완료됨)). MQL5는 바로 지금 이것을 하려고 합니다. 그리고 개발자들의 행동으로 판단할 때, 그들은 얼마나 최선인지 완전히 확신하지 못합니다.
그리고 비동기 자체는 논리적입니다. 왜냐하면 다른 지느러미 거래. 도구는 서로 독립적입니다. 그러나 시장의 정의에 따르면 하나의 거래 상품에 대한 비동기화가 불가능합니다. 물론 MT4 서버에서는 하나의 거래 상품에 비동기가 있을 수 있지만 이것은 시장이 아닙니다.
거래 주문의 비동기 처리는 훌륭하고 이벤트를 통해 JForex API에서 (처음부터) 오랫동안 구현되어 왔습니다(각 거래 요청에 대해 정확히 무엇과 이유가 발생했는지 알 수 있습니다. 각 거래 요청에도 상태 플래그( 서버에 생성(생성되었지만 아직 전송되지 않음)(예: 연결 실패)), 전달됨(서버가 수락함), 진행 중, 완료됨)). MQL5는 바로 지금 이것을 하려고 합니다. 그리고 개발자들의 행동으로 판단할 때, 그들은 얼마나 최선인지 완전히 확신하지 못합니다.
이제 5k에서 구현되는 방식은 비논리적입니다.
깁 :
개발자에게 이것은 살인이 아닙니다. 이것은 응용 프로그램 개체에 대한 매우 일반적인 논리이며 매우 간단하게 설계 및 구현됩니다.
오히려 MT5가 동기 명령 실행에서 멀어진 이유가 궁금합니다.
거래 주문 의 비동기 처리는 이벤트를 통해 JForex API에서 오랫동안(처음부터) 완벽하게 구현되었습니다(각 거래 요청에 대해 정확히 무엇과 이유가 발생했는지 알 수 있습니다. 각 거래 요청에도 상태 플래그(생성됨(생성되었지만 아직 전송되지 않음) 서버로(예: 연결 실패)), 전달됨(서버에서 수락함), 진행 중, 완료됨)). MQL5는 바로 지금 이것을 하려고 합니다. 그리고 개발자들의 행동으로 판단할 때, 그들은 얼마나 최선인지 완전히 확신하지 못합니다.
그리고 비동기 자체는 논리적입니다. 왜냐하면 다른 지느러미 거래. 도구는 서로 독립적입니다. 그러나 시장의 정의에 따르면 하나의 거래 상품에 대한 비동기화가 불가능합니다. 물론 MT4 서버에서는 하나의 거래 상품에 비동기가 있을 수 있지만 이것은 시장이 아닙니다.
글쎄, 글쎄 ... 이것은 5k에서도 일어나지 않을 것입니다. 이것은 개발자와 사용자의 99% 모두에게 치명적입니다.
개발자에게 이것은 살인이 아닙니다. 이것은 응용 프로그램 개체에 대한 매우 일반적인 논리이며 매우 간단하게 설계 및 구현됩니다.
현재 구현된 것과 같은 기능으로 더 복잡하지 않게 응용 프로그램을 설계할 수 있는 가능성도 있습니다. 그러나 누가 그것을 할 것인가? 개발자는 그런 능력이 없습니다.
따라서 문제는 사용자, 즉 대부분이 전문가가 아니며 이러한 기능의 구현이 메타 따옴표를 사용하게 될 것이라는 사소한 복잡성조차 용인하지 않는 사용자, 즉 당신과 나에게 남아 있습니다.
거래 주문의 비동기 처리는 훌륭하고 이벤트를 통해 JForex API에서 (처음부터) 오랫동안 구현되어 왔습니다(각 거래 요청에 대해 정확히 무엇과 이유가 발생했는지 알 수 있습니다. 각 거래 요청에도 상태 플래그( 서버에 생성(생성되었지만 아직 전송되지 않음)(예: 연결 실패)), 전달됨(서버가 수락함), 진행 중, 완료됨)). MQL5는 바로 지금 이것을 하려고 합니다. 그리고 개발자들의 행동으로 판단할 때, 그들은 얼마나 최선인지 완전히 확신하지 못합니다.
이제 5k에서 구현되는 방식은 비논리적입니다.
개발자에게 이것은 살인이 아닙니다. 이것은 응용 프로그램 개체에 대한 매우 일반적인 논리이며 매우 간단하게 설계 및 구현됩니다.