mql4 언어의 기능, 미묘함 및 작업 방법 - 페이지 35

새 코멘트
 
fxsaber # :

그래서 지금은 모든 주문을 한 번에 정렬하는 방법을 생각하고 있습니다.

엑스 그러한 분리가 심각한 결과를 초래하지 않는 방식으로 작성하십시오.

옵션으로 - 봇을 다른 계정에 배포합니다. 확률은 감소하지만 계정 관리의 다양화 및 복잡성은 뺍니다.

 
Andrei Trukhanovich # :

옵션으로 - 봇을 다른 계정에 배포합니다.

그런 다음 예를 들어 지연 만료를 금지하십시오. 일반적으로 목발.

그런 슬픈 기능을 가진 근본적인 필요성. 분명히, 스냅샷을 통해 어떻게든 할 수 있습니다.

 
fxsaber # :

자세한 답변 감사합니다! 그래서 지금은 모든 주문을 한 번에 정렬하는 방법을 생각하고 있습니다.

첫 주문과 마지막 주문(티켓)을 기억할 수 있습니까?

주기가 끝난 후 첫 번째 주문과 마지막 주문이 계산 전과 동일한 티켓인지 확인하십시오. 

   int n  = OrdersTotal ();
   
   if (n == 0 ) return ( 0.0 );
   else if (n == 1 && OrderSelect ( 0 , SELECT_BY_POS)) return (OrderLots());
   
   int t_last = OrderSelect (n - 1 , SELECT_BY_POS) ? OrderTicket() : - 1 ;
   int t_first = OrderSelect ( 0 , SELECT_BY_POS) ? OrderTicket() : - 1 ;


추신: 논리적으로, OrderSelect()는 이러한 충돌에 대한 책임이 있어야 합니다. 주문 테이블이 변경된 경우 false를 반환하지만 포럼 어딘가에서 누군가의 OrderSelect()가 false를 반환했다는 내용과 핸들러를 읽은 기억도 없습니다. t OrderSelect() 오류를 충족하거나

 
Igor Makanu # :

첫 주문과 마지막 주문(티켓)을 기억할 수 있습니까?

티켓 시퀀스를 완전히 기억하지 않으면 이러한 솔루션은 실패합니다.

 
fxsaber # :

티켓 시퀀스를 완전히 기억하지 않으면 이러한 솔루션은 실패합니다.

주기를 실행하는 동안 이미 처리된 주문 상태가 변경될 수 있기 때문에 티켓의 전체 기억도 실패합니다.


확실하지 않지만 루프에 있을 때 주문이 닫히면 OrderTotal()이 변경됩니다.

주문이 마감되고 새 주문이 열리면 티켓이 변경되고/또는 OrderSelect(0) 또는 OrderSelect(OrderTotal()-1)


그리고 이전의 "극단적인 주문"과 OrderTotal() 자체가 남아 있도록 어떤 상황이 발생할 수 있다고 생각합니까?

 
Igor Makanu # :

그리고 이전의 "극단적인 주문"과 OrderTotal() 자체가 남아 있도록 어떤 상황이 발생할 수 있다고 생각합니까?

대부분의 경우 OrdersTotal은 주문 테이블을 흔들 때 변경됩니다.

따라서 추가 포지션을 생성하여 지정가 주문을 보충하는 것이 가능합니다.

 
Igor Makanu # :

첫 주문과 마지막 주문(티켓)을 기억할 수 있습니까?

첫 번째 것을 기억하는 것은 아무 것도 하지 않는다

 
fxsaber 함수 호출 이전과 이후에 있었던 어떤 순서를 건너뛸 것이라는 이론적인 가능성이 있습니까? 또는 두 번 계산합니다.

저것들. 주문이 삭제되거나 열거 중에 나타날 때 인덱싱은 어떻게 됩니까?

나는 티켓의 배열을 수집하고 그것으로 작업합니다.
OrdersTotal, Balance 또는 Margin이 변경된 경우 목록을 다시 작성해야 합니다.

즉, EA는 항상 자체적으로 선택한 티켓으로만 작동합니다.

 
Andrei Trukhanovich # :

첫 번째 것을 기억하는 것은 아무 것도 하지 않는다

이것들은 문서화되지 않았고 미래에 누구도 보장하지 않는 아키텍처 구현의 기능입니다 ...

주제별로 OrderTotal() 및 OrdersHistoryTotal() , 극단적 주문 티켓을 기억하십시오.

주기의 계산 후에 이러한 값이 변경된 경우 처리합니다.


그러나 보편적이고 신뢰할 수 있는 솔루션은 없습니다. 여기서 작업은 서버에서 어떤 일이 일어날지, 네트워크를 통해 데이터가 전달되는 방식과 터미널의 인접 차트에서 어떤 일이 일어나는지 추측하는 것입니다))))


바라는 것은 OrderSelect()의 속도뿐입니다. 제 기억이 맞다면 초당 100만 건 이상의 호출이 가능합니다.

 
fxsaber # :

티켓 시퀀스를 완전히 기억하지 않으면 이러한 솔루션은 실패합니다.

기억하는 것은 비용이 많이 들지 않을 수 있지만 완전한 상태를 추적하는 것은 비용이 많이 들 수 있습니다. 나는 이전 것들에 동의하고 합리성과 우선 순위의 논리로 부하를 줄입니다.

우리가 살고 있는 비동기 세계는 요청 순서에 대한 응답 순서를 보장하지 않으며 일반적으로 순서를 보장하지 않습니다.
1...2829303132333435
새 코멘트