거래 처리 OnTradeTransaction - 페이지 8

새 코멘트
 
fxsaber :

01:35 및 03:35부터 이 비디오를 시청하세요.


집에서 만든 제품이 왜 필요한가요? 놀랐 잖아. 이러한 프로그래밍 지식으로는 OnTradeTransaction 핸들러를 파악할 수 없습니다.

 
Alexey Viktorov :

집에서 만든 제품이 왜 필요한가요? 놀랐 잖아. 이러한 프로그래밍 지식으로는 OnTradeTransaction 핸들러를 파악할 수 없습니다.

작업을 상상조차 하지 않는 사람과 대화하는 것은 어렵습니다.

 
Alexey Viktorov :

위치가 없거나 따옴표 안에 있습니까?

네팅의 관점에서 볼 때 포지션이 없는 것은 지극히 정상적인 상황입니다(즉, 총 포지션 == 0.0).

그리고 두 명의 고문의 관점에서 볼 때 - 각각은 자신의 열린 입장 을 가지고 있습니다.

여러 고문이 하나의 기호로 거래할 수 있습니다. 또한 일부 거래는 손으로 할 수 있습니다.

 
JRandomTrader :

네팅의 관점에서 볼 때 포지션이 없는 것은 지극히 정상적인 상황입니다(즉, 총 포지션 == 0.0).

그리고 두 명의 고문의 관점에서 볼 때 - 각각은 자신의 열린 입장 을 가지고 있습니다.

여러 고문이 하나의 기호로 거래할 수 있습니다. 또한 일부 거래는 손으로 할 수 있습니다.

아내는 침대 옆 탁자에 있는 돈을 가지고 TV를 샀다. 남편은 TV를 빼앗아 팔아 돈을 협탁에 두었습니다. 그물에 관해서는 TV가 없습니다. 그리고 당신의 논리에 따르면 아내는 침대 옆 탁자에 TV와 돈을 가지고 있습니다. 그리고 그들은 앉아서 다른 TV를 사거나 돈을 마시기로 결정합니다.

아니면 각각 TV에 나오나요? 결국, 그들 각자는 그것을 손에 쥐었습니다. 나는 과장한다.


한 명의 어드바이저가 포지션을 개설하고 두 번째 어드바이저가 포지션을 닫으면 없어집니다... 잊어버리세요... 단 하나의 포지션도 없습니다.

 
Alexey Viktorov :

아내는 침대 옆 탁자에 있는 돈을 가지고 TV를 샀다. 남편은 TV를 빼앗아 팔아 돈을 협탁에 두었습니다. 그물에 관해서는 TV가 없습니다. 그리고 당신의 논리에 따르면 아내는 침대 옆 탁자에 TV와 돈을 가지고 있습니다. 그리고 그들은 앉아서 다른 TV를 사거나 돈을 마시기로 결정합니다.

아니면 각각 TV에 나오나요? 결국, 그들 각자는 그것을 손에 쥐었습니다. 나는 과장한다.


한 명의 어드바이저가 포지션을 개설하고 두 번째 어드바이저가 포지션을 닫으면 없어집니다... 잊어버리세요... 단 하나의 포지션도 없습니다.

위치가 없습니다.

그러나 논리의 틀 내에서 각 고문은 자신의 입장을 유지합니다. 예를 들어, 하나는 "장기"가 손실을 상쇄하고 다른 하나는 현재 "스캘퍼"가 역추세에 영향을 미칠 것입니다.

 
JRandomTrader :

위치가 없습니다.

그러나 논리의 틀 내에서 각 고문은 자신의 입장을 유지합니다. 예를 들어, 하나는 "장기"가 손실을 상쇄하고 다른 하나는 현재 "스캘퍼"가 역추세에 영향을 미칠 것입니다.

분명히 당신은 두 가지 헤지 전략의 논리를 네팅에 연결하려고 합니다. 그러한 순서는 더 논리적으로 보일 것입니다.

역추세의 스캘퍼는 포지션을 닫고 자신의 가상 포지션에 대한 추정 TP 가격에 제한을 둡니다. 그리고 이 제한이 작동하면 위치가 완전히 복원되지만!!! 이미 다른 티켓으로. 따라서 폐쇄된 입장 의 연속이라고 생각하는 것은 절대적으로 잘못된 것이며 장기 고문은 이를 자신의 것으로 정의할 수 없을 것입니다.

또 다른 것은 스캘퍼가 더 작은 볼륨으로 작동하는 경우입니다. 그러면 시작 가격이 변경되더라도 최소한 티켓은 그대로 유지됩니다. 일반적으로 헤지를 위한 네팅 전략으로 단순히 전환하려고 하지 마십시오. 좋은 결과는 없을 것입니다. 유추는 효과가 있지만 행동은 달라야 합니다. 그물의 특성을 고려할 필요가 있습니다.

 
Alexey Viktorov :

분명히 당신은 두 가지 헤지 전략의 논리를 네팅에 연결하려고 합니다. 그러한 순서가 더 논리적일 것입니다.

역추세의 스캘퍼는 포지션을 닫고 자신의 가상 포지션에 대한 추정 TP 가격에 제한을 둡니다. 그리고 이 제한이 작동하면 위치가 완전히 복원되지만!!! 이미 다른 티켓으로. 따라서 폐쇄된 입장 의 연속이라고 생각하는 것은 절대적으로 잘못된 것이며 장기 고문은 이를 자신의 것으로 정의할 수 없을 것입니다.

또 다른 것은 스캘퍼가 더 작은 볼륨으로 작동하는 경우입니다. 그러면 시작 가격이 변경되더라도 최소한 티켓은 그대로 유지됩니다. 일반적으로 헤지를 위한 네팅 전략으로 단순히 전환하려고 하지 마십시오. 좋은 결과는 없을 것입니다. 유추는 효과가 있지만 행동은 달라야 합니다. 그물의 특성을 고려할 필요가 있습니다.

스캘퍼와 장기 스캘퍼는 하나의 예일 뿐이며, 심볼에 많은 어드바이저가 있을 수 있으며, 로트가 다를 수 있습니다.

"역추세에 있는 스캘퍼는 포지션을 닫고 자신의 가상 포지션에 대해 주장되는 TP 가격에 제한을 둡니다." - 그러나 스캘퍼는 자신이 "자신의 가상 위치"를 가지고 있다고 믿습니다.

그리고 전체 위치의 티켓이 변경되었다는 사실 - 너무 장기적으로 불필요하기 때문에 그는 이미 자신의 위치가 있다는 것을 알고 있으며 이는 총계와 전혀 관련이 없습니다.

결과적으로 각 고문은 이 기호에 대해 그와 함께 작업하는 다른 사람과 관계없이 작업하며 이에 대해 아무것도 모르고 알고 싶어하지도 않습니다.

그리고 예, 저는 MT5, FORTS 및 네팅으로 즉시 시작했기 때문에 헤지 전략을 바꾸려는 것이 아닙니다. 나는 단지 여러 로봇이 심볼을 거래할 수 있고 여전히 그들을 방해하지 않고 손을 거래할 수 있기를 원했습니다.

 

JRandomTrader :

그러나 스캘퍼는 자신이 "자신의 가상의 위치"를 가지고 있다고 믿습니다.

나는 그것에 대해 이야기하고 있으며 그물을 위해서는 다른 논리를 구축해야 합니다. 가상의 위치가 없어야 합니다. 당신이 나를 이해할 수 있는 다른 단어를 찾지 못했기 때문에 이렇게 썼습니다. 리필이 있는 경우 총 포지션 거래량과 신규 포지션 개시 가격이 고려되고, 부분 청산이 동일하면 총 가격과 거래량이 고려됩니다.

 
Alexey Viktorov :

나는 그것에 대해 이야기하고 있으며 그물을 위해서는 다른 논리를 구축해야 합니다. 가상의 위치가 없어야 합니다. 당신이 나를 이해할 수 있는 다른 단어를 찾지 못했기 때문에 이렇게 썼습니다. 리필이 있는 경우 총 포지션 거래량과 신규 포지션 개시 가격이 고려되고, 부분 청산이 동일하면 총 가격과 거래량이 고려됩니다.

그런 다음 우리는 로봇 사이의 일종의 상호 작용을 차단하고 오늘과 내일, 아마도 다른 사람들에게 혼자인 "이웃"의 행동을 고려해야 합니다. 그리고 그것이 어떤 이득을 가져다줄지는 미지수다.

로봇 알고리즘의 관점에서 가상의 위치가 필요합니다. 로봇이 열면 닫아야 합니다.

 
JRandomTrader :

그런 다음 우리는 로봇 사이의 일종의 상호 작용을 차단하고 오늘과 내일, 아마도 다른 사람들에게 혼자인 "이웃"의 행동을 고려해야 합니다. 그리고 그것이 어떤 이득을 가져다줄지는 미지수다.

로봇 알고리즘의 관점에서 가상의 위치가 필요합니다. 로봇이 열면 닫아야 합니다.

단순화하기 위해 아마도 그렇습니다. 동의한다.

그런 다음 "운송 부서장"은 문제와 그의 행동을 완전히 말하지 않았습니다.

OnTradeTransaction 절차에서 트랜잭션의 트랜잭션을 포착하고 이를 기반으로 보류 중인 정지 주문을 내립니다.

아래는 거래 거래 코드입니다.

 case TRADE_TRANSACTION_DEAL_ADD :
        {
         drop_info2( "TRADE_TRANSACTION_DEAL_ADD\r\n" +TransactionDescription(trans));
         if ((trans.deal_type== DEAL_TYPE_BUY || trans.deal_type== DEAL_TYPE_SELL ) && trans.order!= 0 )
           {
             if (getIsDealOfExpert(trans.deal)) //функция проверки принадлежности сделки к роботу
              {
               drop_info2( "Сделка наша" );
               analyzeFilledOrder(trans.order,trans.volume); //процедура по выставлению отложенных стоп ордеров
              }
           }
        }
       break ;

거래가 로봇에 속하는지 확인하기 위한 기능 코드

 bool getIsDealOfExpert( ulong dealTicket)
     {
       if ( HistoryDealSelect (dealTicket) && HistoryDealGetInteger (dealTicket, DEAL_MAGIC )==magic_number && HistoryDealGetString (dealTicket, DEAL_SYMBOL )==symbol)
         return true ;
       else
         return false ;
     }

보류 중인 중지 주문을 위한 절차 코드

 void analyzeFilledOrder( ulong orderTicket, double volume)
  {
   bool isFindOrder= false ;
   string fullComment;
   ENUM_ORDER_TYPE orderType;
   if (getIsOrderOfExpert(orderTicket, true )) //Если ордер из сделки уже в истории
     {
      fullComment= HistoryOrderGetString (orderTicket, ORDER_COMMENT );
      orderType= ENUM_ORDER_TYPE ( HistoryOrderGetInteger (orderTicket, ORDER_TYPE ));
      isFindOrder= true ; //локальная переменная, если нашли в истории
     }
   if (!isFindOrder && getIsOrderOfExpert(orderTicket, false )) //Если не нашли ордер в истории и ордер есть не в истории
     {
      fullComment= OrderGetString ( ORDER_COMMENT ); 
      orderType= ENUM_ORDER_TYPE ( OrderGetInteger ( ORDER_TYPE ));
      isFindOrder= true ; //локальная переменная, если нашли не в истории
     }
   if (isFindOrder) //если хоть где-то нашли, то выставляем отложенные стоп ордера
     {
     //выставляем стоп ордера

내역이 아닌 내역에 있는 주문 검색 기능의 코드

 bool getIsOrderOfExpert( ulong OrderTicket , bool isHistory)
     {
       bool is_expert= false ;
       //если ордер находится в истории
       if (isHistory)
        {
         if ( HistoryOrderSelect ( OrderTicket ) && HistoryOrderGetInteger ( OrderTicket , ORDER_MAGIC )==magic_number && HistoryOrderGetString ( OrderTicket , ORDER_SYMBOL )==symbol)
            is_expert= true ;
        }
       else
        {
         if ( OrderSelect ( OrderTicket ) && OrderGetInteger ( ORDER_MAGIC )==magic_number && OrderGetString ( ORDER_SYMBOL )==symbol)
            is_expert= true ;
        }
       return is_expert;
     }

나는 터미널에서 수신된 순서대로 로그에 트랜잭션의 도착에 대한 정보를 표시합니다. 이제 데모 계정에서 거래할 때 발생한 문제:

주기적으로 거래는 TRADE_TRANSACTION_ORDER_DELETE, TRADE_TRANSACTION_DEAL_ADD, TRADE_TRANSACTION_HISTORY_ADD 순서로 도착합니다. 이 경우 종종 거래가 완료된 후 중지 주문이 설정되지 않습니다. 내 생각에 이것은 주문이 이미 삭제되었지만 아직 내역에 입력되지 않았기 때문입니다. 즉, 거래 내역이나 터미널에서 주문을 찾을 수 없습니다. 의심스럽긴 하지만 사실은 남아 있습니다. 로봇이 모든 차원에서 주문을 검색한 후 찾지 못하기 때문에 중지 명령이 내려지지 않습니다( isFindOrder= false ). 거래 순서는 정확할 수 있지만 주문은 여전히 어디에도 없습니다. 모든 경우에 로봇은 거래를 올바르게 결정하지만 주문에 도달하지는 않습니다. 동시에 모든 것이 때때로 올바르게 작동하고 주문이 이루어집니다.

다른 접근 방식을 시도했지만 아무 것도 도움이되지 않습니다. 이제 보류 중인 주문을 하는 절차의 시작 부분에 1초의 절전 모드를 추가할 생각입니다. 시간이 충분하지 않을 수 있습니다. 일반적으로 나는 다른 곳을 파야할지조차 모릅니다.

경험과 아이디어를 공유해 주세요.

중지 명령은 무엇을 의미합니까? 일반 직위를 위해 또는 이 특정 고문이 일하는 부분에 대해서만???
12345678910
새 코멘트