하나의 거래 주문이 시장에서 포지션을 여는 경우(시장 주문) 3개의 OnTrade 트리거 또는 4개의 OnTradeTransaction 트리거가 발생합니다. 그리고 하나의 OnPositionOpened 처리기의 작업이 필요합니다.
손절매/이익 실현으로 포지션을 청산하려면 OnPositionClosed 1개 대신 3개의 OnTrade 트리거 또는 3개의 OnTradeTransaction 트리거가 발생합니다. 중복이 있습니다!
기존 이벤트 처리기(OnTrade/OnTradeTransaction)의 이러한 다중 실행은 "어떤 거래 이벤트가 발생 했으며 거래 작업의 결과는 무엇입니까?"라는 질문에 대한 명확한 대답을 제공하지 않습니다. 즉, 사용자가 이러한 이벤트를 추가로 처리한다는 의미입니다. 조직되어야 합니다. 질문은 "이 모든 정원이 왜?"입니다.
이러한 거래 이벤트의 과도한 작업으로 인해 다양한 종류의 충돌이 쉽게 발생할 수 있으며, 이는 특히 클라이언트로부터 거래 주문을 대량 전송하는 동안 오류로 이어질 수 있습니다.
따라서 귀하의 경우 또는 komposter(시간 초과)의 경우에 발생한 일은 개인적으로 놀랍지 않습니다.
OnTrade 및 OnTradeTransaction 이벤트가 무의식적으로 구현되는 방식은 20년 전 에피소드를 생각나게 했습니다... Spectrum의 새 게임에 대한 리뷰를 읽은 것을 기억합니다. 특히 한 게임에 대한 리뷰가 다음과 같이 언급된 것을 기억합니다. " ...게임내의 소리는 끌 수 있는 기회가 있어서 좋은데...". 나는 OnTrade 및 OnTradeTransaction 이벤트에 대해 거의 같은 태도를 가지고 있습니다. 그것들은 단지 당신이 그것들을 사용할 수 없기 때문에 좋은 것입니다.
SWA : OnTrade 및 OnTradeTransaction 이벤트가 무의식적으로 구현되는 방식은 20년 전 에피소드를 생각나게 했습니다... Spectrum의 새 게임에 대한 리뷰를 읽은 것을 기억합니다. 특히 한 게임에 대한 리뷰가 다음과 같이 언급된 것을 기억합니다. " ...게임내의 소리는 끌 수 있는 기회가 있어서 좋은데...". 나는 OnTrade 및 OnTradeTransaction 이벤트에 대해 거의 같은 태도를 가지고 있지만 사용할 수 없기 때문에 좋은 것뿐입니다.
OnTrade에서 - OnTradeTransaction이 먼저 실행되기 때문에 매우 편리합니다.
그리고 OnTrade.
개인적으로 이 편리함은 의심스럽습니다. 서버에서 발생한 일에 대한 정확한 정보를 얻기 위해 시간 손실과 클라이언트-서버 호출로 채널을 로드하는 것입니다. 그러한 어려움으로 서버에서 추출한 정보가 수신될 때 관련성이 없고 신뢰할 수 없게 되는 상황이 발생할 수 있습니다. 거래 알고리즘 에 필요한 빈도를 가진 EA가 다음과 같은 형식으로 서버에 요청을 생성했다면 이러한 이벤트를 사용하는 것이 정말 편리할 것입니다(적어도 저에게는 편리합니다).
bool TradeTransaction(TIME_REQUEST);
bool Trade(TIME_REQUEST);
// где временная метка может принимать значение к примеру TIME_REQUEST=TimeTradeServer или TIME_REQUEST=TimeGMT
그리고 서버는 그러한 요청에 대한 포괄적 인 정보와 함께 즉시 답변을 제공합니다 ...
하지만 그런 편리함을 구현하지 못하게 하는 '극복할 수 없는 객관적인 이유'가 있다고 가정하고, 나는 내가 가진 것을 할 것입니다 :)
파파클라스, c-4
OnTradeTransaction을 통한 기존 서버 응답 모델
나에게 적합하고 내 EA에서 작동하지만
내 첫 번째 메시지는 서버가 메시지를 (전혀) 반환하지 않았기 때문입니다.
거래가 완료되었고(주문은 1로 채워짐) 두 번째 오류는
주문이 접수되었다는 답변 대신 주문이 부분적으로 실행(중복)되었다는 답변이 왔습니다.
핸들러에 대한 것이 아니라(나는 그것에 대해 불만이 없습니다), 서버의 응답에 관한 것입니다( 하나는 전혀 오지 않았고 두 번째는 올바르지 않았습니다 ).
내 EA에서 서버 응답으로 작업하는 모델은 서버 응답의 순서를 기반으로 하지 않지만 응답은 정확해야 합니다.
무슨 일이 일어났는지 확인하세요(첫 번째 게시물의 사진):
EA는 3권을 주문했습니다.
주문이 1로 채워졌습니다. 서버의 응답이 정확합니다.
또한, 고문이 주문을 수정했습니다. 서버의 응답은 ORDER_STATE_PARTIAL 이었지만 ORDER_STATE_PLACED여야 했습니다.
그런 다음 주문이 1 더 채워졌고 서버에서 메시지가 오지 않았습니다.
며칠 후(아래 그림) 이 시퀀스를 반복했습니다. 결과가 변경되었습니다(개발자가 무언가를 수정했을 수 있음).
트랜잭션이 발생했다는 메시지가 수신되었지만(두 번째 21:15:02.232) 수정 메시지가 잘못된 상태로 유지되었습니다.
서버에서 세 개의 응답이 동시에 왔다는 것도 매우 놀라운 일입니다(21:14:53.049)!
모든 것이 하나의 스레드에서 작동하고 메시지가 누적되는 것이 분명하지만 여전히 .... 고문을 중지하고,
메시지를 수신합니다.
파파클라스!
사실은 *.ex5 프로그램이 다음과 같은 경우 하나의 스레드에서 작동한다는 것입니다.
많은 핸들러가 있을 것이고 더 나빠질 것입니다.
이제 전문가가 OnTrade 및 OnTradeTransaction의 작동을 확인했습니다.
하나의 거래 주문이 시장에서 포지션을 여는 경우(시장 주문) 3개의 OnTrade 트리거 또는 4개의 OnTradeTransaction 트리거가 발생합니다. 그리고 하나의 OnPositionOpened 처리기의 작업이 필요합니다.
손절매/이익 실현으로 포지션을 청산하려면 OnPositionClosed 1개 대신 3개의 OnTrade 트리거 또는 3개의 OnTradeTransaction 트리거가 발생합니다. 중복이 있습니다!
기존 이벤트 처리기(OnTrade/OnTradeTransaction)의 이러한 다중 실행은 "어떤 거래 이벤트가 발생 했으며 거래 작업의 결과는 무엇입니까?"라는 질문에 대한 명확한 대답을 제공하지 않습니다. 즉, 사용자가 이러한 이벤트를 추가로 처리한다는 의미입니다. 조직되어야 합니다. 질문은 "이 모든 정원이 왜?"입니다.
이러한 거래 이벤트의 과도한 작업으로 인해 다양한 종류의 충돌이 쉽게 발생할 수 있으며, 이는 특히 클라이언트로부터 거래 주문을 대량 전송하는 동안 오류로 이어질 수 있습니다.
따라서 귀하의 경우 또는 komposter(시간 초과)의 경우에 발생한 일은 개인적으로 놀랍지 않습니다.
OnTrade 및 OnTradeTransaction 이벤트가 무의식적으로 구현되는 방식은 20년 전 에피소드를 생각나게 했습니다... Spectrum의 새 게임에 대한 리뷰를 읽은 것을 기억합니다. 특히 한 게임에 대한 리뷰가 다음과 같이 언급된 것을 기억합니다. " ...게임내의 소리는 끌 수 있는 기회가 있어서 좋은데...". 나는 OnTrade 및 OnTradeTransaction 이벤트에 대해 거의 같은 태도를 가지고 있지만 사용할 수 없기 때문에 좋은 것뿐입니다.
그리고 나는 반대로 이 두 핸들러를 (성공적으로) 사용합니다!
어떤 이유로 OnTradeTransaction 이 작동하지 않으면 다음을 확인합니다.
OnTrade에서 - OnTradeTransaction이 먼저 실행되기 때문에 매우 편리합니다.
그리고 OnTrade.
그리고 나는 반대로 이 두 핸들러를 (성공적으로) 사용합니다!
어떤 이유로 OnTradeTransaction이 작동하지 않으면 다음을 확인합니다.
OnTrade에서 - OnTradeTransaction이 먼저 실행되기 때문에 매우 편리합니다.
그리고 OnTrade.
거래 알고리즘 에 필요한 빈도를 가진 EA가 다음과 같은 형식으로 서버에 요청을 생성했다면 이러한 이벤트를 사용하는 것이 정말 편리할 것입니다(적어도 저에게는 편리합니다).
그리고 서버는 그러한 요청에 대한 포괄적 인 정보와 함께 즉시 답변을 제공합니다 ...
하지만 그런 편리함을 구현하지 못하게 하는 '극복할 수 없는 객관적인 이유'가 있다고 가정하고, 나는 내가 가진 것을 할 것입니다 :)
누가 할 수 있는지... :)
그건 그렇고 Plaza II 교환 서버에서 API를 다운로드하면 "다리가 어디에서 자라는 지"를 알 수 있습니다.
무례하지 마십시오! 그건 그렇고, 이미 10!
그리고 당신은 여기에 쓰여진 것을 읽지 않을 권리가 있습니다!
그렇다면 왜 주제인가? 그냥 소리 질러?
오류가 있다고 생각되면 로그와 코드로 확인하십시오(아무도 사진을 해독하지 않음).
신뢰할 수 있는 솔루션을 찾고 싶다면 그들의 말에 귀를 기울이십시오(이벤트 모델을 버리고 현재 상태를 분석하십시오).
나는 거래 상황의 변화에 대한 즉각적인 반응을 위해서만 OnTradeTransaction 또는 OnTrade를 사용할 것입니다. 그러나 Vasily ( OnRefresh() )가 제안한 대로 모든 처리를 하나의 처리기에 넣을 것 입니다.
행운을 빕니다!
그렇다면 왜 주제인가? 그냥 소리 질러?
오류가 있다고 생각되면 로그와 코드로 확인하십시오(아무도 사진을 해독하지 않음).
신뢰할 수 있는 솔루션을 찾고 싶다면 그들의 말에 귀를 기울이십시오(이벤트 모델을 버리고 현재 상태를 분석하십시오).
나는 거래 상황의 변화에 대한 즉각적인 반응을 위해서만 OnTradeTransaction 또는 OnTrade를 사용할 것입니다. 그러나 Vasily ( OnRefresh() )가 제안한 대로 모든 처리를 하나의 처리기에 넣을 것 입니다.
행운을 빕니다!
퇴비!
1. 쓰여진 모든 것을 읽거나 ...
2. 내가 이 페이지에 쓰는 것은 무엇이든 포럼에 참여할 수 있는 나의 권리입니다.
OPEN RUDENESS는 어디에도 적합하지 않습니다!
3. 오류를 처리하는 곳마다 서버의 응답이 원래와 다른 경우 - 결과는 동일합니다 - ERROR!
4. 당신은 아마도 자신을 거래하지 않을 것입니다.
프로니크와 ....
1. >> OPEN RUDE - 솔직한 충돌에 대한 해답! 질문은 무엇입니까 - 이것이 답입니다. 그리고 영웅이 될 수도...))
당신은 아마도 당신 주변의 세계에 대해 정확히 이러한 인식을 가지고 있을 것입니다 ...
2. 당신은 프로그래머입니까 아니면 "작가"입니까?
3. 누구든지 간단한 질문에 대답할 수 있습니까? 서버는 "주문 수정" 명령에 대해 무엇이라고 말해야 합니까?
4. 그러면 문서는 어떻게 됩니까? 조항? 눈을 감고 원하는 대로 뱉어! 모두 동일하게, 고객은 지불합니다(그리고 그에게도 병합)!