¡Promotores! ¿Acaso pruebas lo que creas? - página 10

[Vasiliy Sokolov]

Mikalas:

¡Oh, Dios mío! ¿Es válido en la historia?

¿Papaklass probablemente quería decir que OnTradeTransaction devuelve errores?

Si la información en OnTradeTransaction puede no ser válida, tenemos que tomarla del historial para asegurarnos de que es válida.

Si la información de onTradeTransaction no es siempre fiable, tenemos que tomarla del historial para asegurarnos de que la información fue procesada.

La pregunta es ¿por qué demonios necesitamos OnTradeTransaction si tenemos que tomar la información del historial de todos modos? - Sólo lo necesita para la comprobación de errores. El corredor rechazó la orden y recibimos la respuesta de por qué fue rechazada en OnTradeTransaction y la analizamos.

[Mikhail Filimonov]

sergeev:
¿pero por qué babear por 9 páginas?

Por favor, no seas grosero. Por cierto, ¡ya son 10!

Y estás en tu derecho de no leer nada de lo que se escribe aquí.

[Vasiliy Sokolov]

Mikalas:

C-4, se procesará, por supuesto, pero ¿por qué la necesidad de OnRefresh()?

Muchos eventos -> un manejador.

[Mikhail Filimonov]

C-4:
Muchos eventos -> un manejador.

¡Errores de todos los rincones en una pila! :)

[Vasiliy Sokolov]

Mikalas:
¡Errores de todos los rincones en una pila! :)

No son los errores los que se envían, sino los datos. Los errores pueden estar en el manejador, pero son fáciles de arreglar porque sólo hay un manejador.

papaklass:
Eso es exactamente lo que quiero decir. Necesitas separación de eventos.

No necesitas una separación de eventos, necesitas una separación de manejadores. Los eventos generan datos. Cada tipo de dato es manejado por su propio manejador. No importa quién haya recibido los datos, lo importante es que haya un único gestor para cada tipo de datos.

[Mikhail Filimonov]

C-4:

No son los errores los que se envían, sino los datos. Los errores pueden estar en el manejador, pero son fáciles de arreglar porque sólo hay un manejador.

No hay que separar los eventos, hay que separar los manejadores. Los eventos generan datos. Cada tipo de datos es manejado por un manejador diferente. No importa quién haya recibido los datos, lo importante es que haya un único manejador para cada tipo de datos.

¿Qué no se comparte aquí?

void OnTradeTransaction( const MqlTradeTransaction &trans, const MqlTradeRequest &request, const MqlTradeResult &result )
{
 // Print( "Ticket = ", string( trans.order ), " --> ", EnumToString( trans.type ), " --> ", EnumToString(trans.order_state) );
  
  switch( trans.type )
  {
    TRADE_TRANSACTION_ORDER_DELETE:      switch( trans.order_state )
                                         {
                                           Удаление ордера из списка открытых.
                                           Ордер может быть удален из открытых в результате выставления
                                           соответствующего запроса либо в результате исполнения (заливки) и переноса в историю.
 
                                         } 
                                         break;
    
    TRADE_TRANSACTION_ORDER_ADD:         switch( trans.order_state )
                                         {
                                           Добавление нового открытого ордера.
                                         } 
                                         break;
                                          
    TRADE_TRANSACTION_DEAL_ADD:          switch( trans.order_state )
                                         {
                                           Добавление сделки в историю. Осуществляется в результате исполнения ордера или проведения операций с балансом счета.
                                         }
                                         break;
                                                    
    case TRADE_TRANSACTION_HISTORY_ADD:  switch( trans.order_state )
                                         {
                                           Добавление ордера в историю в результате исполнения или отмены.
                                         }
                                         break;
    
    case TRADE_TRANSACTION_ORDER_DELETE:  switch( trans.order_state )
                                         {
                                           Удаление ордера из списка открытых.
                                           Ордер может быть удален из открытых в результате выставления
                                           соответствующего запроса либо в результате исполнения (заливки) и переноса в историю.
                                         }
                                         break;
                                         
    case TRADE_TRANSACTION_ORDER_UPDATE: switch( trans.order_state )
                                         {
                                           Изменение открытого ордера. 
                                           К данным изменениям относятся не только явные изменения
                                           со стороны клиентского терминала или торгового сервера,
                                           но также и изменение его состояния при выставлении
                                           (например, переход из состояния ORDER_STATE_STARTED в ORDER_STATE_PLACED или
                                           из ORDER_STATE_PLACED в ORDER_STATE_PARTIAL и т.д.).
                                         }
                                         break;
                                         
    case TRADE_TRANSACTION_DEAL_UPDATE:  switch( trans.order_state )
                                         {
                                           Изменение сделки в истории. Возможны ситуации, 
                                           когда ранее исполненная сделка изменяется на сервере.
                                           Например, сделка была изменена во внешней торговой системе (бирже),
                                           куда она была выведена брокером.
                                         }
                                         break;
                                         
    case TRADE_TRANSACTION_DEAL_DELETE: switch( trans.order_state )
                                        {
                                          Удаление сделки из истории.
                                          Возможны ситуации, когда ранее исполненная сделка удаляется на сервере.
                                          Например, сделка была удалена во внешней торговой системе (бирже), куда она была выведена брокером.
                                        }
                                        break; 
             
    case TRADE_TRANSACTION_HISTORY_UPDATE: switch( trans.order_state )
                                           {
                                             Изменение ордера, находящегося в истории ордеров.
                                             Данный тип предусмотрен для расширения функциональности на стороне торгового сервера.
                                           }
                                           break;
                                          
    case TRADE_TRANSACTION_HISTORY_DELETE: switch( trans.order_state )
                                           {
                                             Удаление ордера из истории ордеров.
                                             Данный тип предусмотрен для расширения функциональности на стороне торгового сервера.
                                           }
                                           break;
                                                                                 
    case TRADE_TRANSACTION_POSITION:       switch( trans.order_state )
                                           {
                                            Изменение позиции, не связанное с исполнением сделки. 
                                            Данный тип транзакции свидетельствует именно о том,
                                            что позиция была изменена на стороне торгового сервера.
                                            У позиции может быть изменен объем, цена открытия,
                                            а также уровни Stop Loss и Take Profit.
                                            Информация об изменениях передается в структуре MqlTradeTransaction
                                            через обработчик OnTradeTransaction.
                                            Изменение позиции (добавление, изменение или ликвидация) в результате совершения
                                            сделки не влечет за собой появление транзакции TRADE_TRANSACTION_POSITION.
                                           }
                                           break;                                                                                                                                                                                  
  case TRADE_TRANSACTION_REQUEST:  Уведомление о том, что торговый запрос обработан сервером,
                                     и результат его обработки получен.
                                      Для транзакций данного типа в структуре MqlTradeTransaction
                                      необходимо анализировать только одно поле - type (тип транзакции).
                                      Для получения дополнительной информации необходимо анализировать второй
                                      и третий параметры функции OnTradeTransaction (request и result).
                                    break;
}

[Mikhail Filimonov]

Y luego están

const MqlTradeRequest &request, const MqlTradeResult &result

[Vasiliy Sokolov]

Mikalas:

¿Qué no se comparte aquí?

Mucha combinatoria. Conclusión: hoja gigante en OnTradeTransaction y lógica complicada. No puedo responder cómo lo haría yo, porque no conozco la tarea. En todo caso caso caso->caso->caso... es un poco sospechoso.

[Vasiliy Sokolov]

papaklass:

Lo que sugieres (tratamiento de los tipos de datos) es lo que tiene MK en este momento. El manejador OnTradeTransaction maneja un determinado tipo de datos MqlTradeTransaction. Es cierto, en este tipo de datos ponen muchas cosas, es decir, tipos de datos correspondientes a diferentes eventos.

Sugiero que cada evento tenga sus propios datos y su propio manejador. A tantos eventos, tantos manejadores. La división de eventos (abrir una posición, cerrar una posición, colocar una orden, modificar una orden, modificar una posición, etc.). Y son los desarrolladores los que deciden qué tipos de datos asignar a cada evento.

Con la palabra "manejador", no me refiero a una función del sistema que recibe algún evento, sino a algún módulo del Asesor Experto que analiza este evento. Para multiplicar el número de funciones en... Cada uno de ellos para su propio evento - no tiene sentido, más aún es elemental crear un número necesario de manejadores personalizados. Así es como se hace en mi caso:

///
/// Принимаем событие.
///
void OnEvent(Event* event)
{
   switch(event.EventId())
   {
       case EVENT_MOUSE_MOVE:
           OnMouseMove(event);
           break;
       case EVENT_KEY_DOWN:
           OnKeyDown(event);
           break;
       case EVENT_ORDER_CHANGE:
           OnOrderChange(event);
           break;
       //etc...
   }
}

Puede parecer extraño que una misma clase de evento se pase a manejadores completamente diferentes que requieren tipos de datos completamente diferentes. Por ejemplo, OnMouseMove requiere una máscara de teclas pulsadas en el ratón y sus coordenadas, OnKeyDown() requiere el código de una tecla pulsada, OnOrderChange requiere un ticket de la orden que se cambió y probablemente un enum que describa el cambio exacto. Se podría pensar que la clase de evento contiene campos para todos los eventos posibles. Pero no es el caso. De hecho, el objeto de la clase de evento ni siquiera puede existir, ya que su constructor está oculto en el área protegida. Pero sus descendientes existen en abundancia - cada uno de ellos para manejar sólo un evento diferente. Sin embargo, para cualquier evento existe un identificador que indica a qué tipo pertenece. Sabiendo este identificador, puede pasar con seguridad de un tipo más grande a uno más pequeño. Es el tipo de hijo al que se realiza la conversión implícita cuando se pasa el manejador. Veamos cómo nuestros manejadores ven realmente el evento:

///
/// Реагируем на перемещение мыши.
///
OnMouseMove(EventMouseMove* event)
{
   int yCoord = event.YCoord();
   int xCoord = event.XCoord();
   printf("X координата: " + xCoord + "; Y координата: " + yCoord);
}

///
/// Реагируем на перемещение мыши.
///
OnOrderChange(EventOrderChange* event)
{
   int ticket = event.Ticket();
   ENUM_ORDER_STATE state = event.OrderState();
   printf("Ордер с тикетом " + ticket + " изменил свое состояние на " + EnumToString(state));
}

//etc...

Hermoso... Parece que sólo hay un evento, pero en realidad podría haber docenas de ellos. El evento parece no contener prácticamente ninguna información, excepto su tipo, pero de hecho, los manejadores se refieren libremente a métodos conocidos sólo por ellos.

[Vasiliy Sokolov]

No hay eventos "externos" e "internos", sólo eventos. Y el número de estos eventos es potencialmente infinito. Un evento puede ser cualquier cosa. Un evento puede contener todo tipo de datos. Siguiendo esta filosofía alcanzamos un nuevo y más alto nivel de abstracción de datos. ¡Por qué crear restricciones en tu cabeza, por qué imponer una clasificación que limite la abstracción!

papaklass:

La diferencia esencial entre los eventos internos y externos es el tiempo de ejecución. Los eventos internos tienen un tiempo de ejecución prácticamente nulo, mientras que los externos tienen cientos de milisegundos o segundos.

Los eventos no tienen un tiempo de ejecución. Si un evento ha llegado, ya se ha ejecutado. Así es como funciona el modo asíncrono. Por tanto, es un error clasificar los eventos en internos y externos por la rapidez con la que se ejecutan. Lo correcto es no clasificar en absoluto, sino pensar de forma muy abstracta a partir de la aplicación concreta.