Discusión sobre el artículo "Comunicándonos con Meta Trader 5 usando conexiones designadas sin utilizar DLL" - página 4

Nuevo comentario
 
Renat:
Al transmitir cadenas, 4 bytes de su tamaño van primero.

Corregida la función de recepción de datos con especificación del tamaño explícito del buffer.

Entendida la razón por la que la transferencia inversa no funcionaba - no especifiqué la longitud de los datos transferidos.

Muchas gracias. Todo funcionó.

Las tuberías son poderosas. Respeto al autor del artículo.

 
Renat:
Se hizo en la última versión de MetaTrader 4.
Pido disculpas, pensé que me había perdido algo. Miré el anuncio 445 - hay efectivamente sobre pips allí. La cuestión es que no hay ninguna palabra al respecto en la ayuda. ¿Habrá alguna actualización sobre este tema, y cuando? Tal vez usted puede describir en el foro.
 

Las tuberías en 4 funcionan de forma similar a 5, también a través de operaciones de archivo.

Publicaremos un artículo para MT4.

 
Renat:

Las tuberías en 4 funcionan de forma similar a 5, también a través de operaciones de archivo.

Publicaremos un artículo para MT4.

Hola, ¿puedo tener un ejemplo sencillo para MT4? No cuento con un artículo, por supuesto.

Estoy específicamente interesado en cómo leer tres parámetros de mi programa auto-escrito en un Asesor Experto en la terminal.

 
Renat:
Se hizo en la última build de MetaTrader 4.

Todo parece funcionar bien en MT5.

El único punto:

  • Sería bueno hacer que cuando se intenta leer desde el canal utilizando ReadString y otros métodos, la integridad de la tubería-canal se comprueba en primer lugar.

De lo contrario, nos quedamos colgados en el método WaitForRead indefinidamente, aunque el lado del servidor haya estado cerrado durante mucho tiempo. Todo esto fue comprobado bajo Win7-64.

Añadí timeout y algunos otros trucos al método WaitForRead en el lado del servidor y conseguí un sistema que funciona con reconexiones automáticas en ambos lados del canal,

pero es todo un poco "muleto".

 
Dima_S:

Todo parece funcionar bien en MT5.

El único punto:

  • Sería bueno hacer que al intentar leer del canal usando ReadString y otros métodos, se compruebe primero la integridad de la tubería-canal.

De lo contrario, nos quedamos colgados en el método WaitForRead indefinidamente, aunque el lado del servidor haya estado cerrado durante mucho tiempo. Todo esto fue comprobado bajo Win7-64.

Añadí timeout y algunos otros trucos al método WaitForRead en el lado del servidor y conseguí un sistema que funciona con reconexiones automáticas en ambos lados del canal,

pero es todo un poco "muleto".

Por nuestra parte era una demostración de la posibilidad.

Por favor, publica tu variante de la clase. Finalizaremos la clase estándar.

 
En realidad, sólo añadí el método WaitForRead con comprobación de errores y salida por timeout (tiempo de espera - en unidades convencionales - número de intervalos de unos 20mseg):
bool
CFilePipe::WaitForRead( const ulong size, const int _time_out )
{
  int  count = 0;

  while( count < _time_out && m_handle != INVALID_HANDLE && !IsStopped( ))
  {
    if( FileSize( m_handle ) >= size )
    {
     return( true );
    }
    else if( GetLastError( ) != 0 )
    {
      return( false );
    }
    Sleep( 1 );
    count++;
  }

  return( false );
}


La parte del cliente en sí se ve más o menos así:

while( !IsStopped( ))
{
// Intentando conectar con el servidor PIPE:
  Print( "Try to connect" );
  if( pipe_Ptr.Open( ch_name, FILE_READ | FILE_WRITE | FILE_ANSI ) != INVALID_HANDLE )
  {
    if( IsStopped( ))
    {
      pipe_Ptr.Close( );
      return;
    }
    Print( "Pipe " + ch_name + " opened" );

// Ciclo de recepción de datos:
    while( !IsStopped( ))
    {
// Comprobar la integridad de la conexión:
      if( !pipe_Ptr.WriteString( "@" ))
      {
        Print( "Disconnected: ", GetLastError( ));
        pipe_Ptr.Close( );
        break;
      }

// Recuperando datos:
      if( pipe_Ptr.WaitForRead( sizeof( int ), 100 ))
      {
        if( !pipe_Ptr.ReadString( str ))
        {
          Print( "Reading string failed: ", GetLastError( ));
          pipe_Ptr.Close( );
          break;
        }
        Print( "Server: ", str, " received" );
      }
    }
  }
  Sleep( 1000 );
}

La cuestión es que el método FileSize, que se usa mientras se espera a que lleguen los datos, no detecta una violación de conexión ( aparentemente no lo comprueba).

Timeout ayuda, pero IMHO no en todas las situaciones posibles. Sería bueno comprobar todos estos errores en el método FileSize.

 

Extraño...

Las imágenes del buffer no llegan a los comentarios y exactamente si usas alt+PrntScr y lo pegas en el editor, la imagen se inserta pero el mensaje no llega a la rama.

Vale, el problema es que el ejemplo de prueba del artículo no pasa

Pero en el terminal, el script no registra nada hasta que lo borro del gráfico.

y entonces veo en el log 

2013.03.26 15:33:11     PipeClient (EURUSD,M5)  Client: sending welcome message failed
2013.03.26 15:33:11     PipeClient (EURUSD,M5)  Client: pipe opened

Win7x64 build 787 con fecha de 21 de marzo de 2013.

 

Acabo de comprobarlo, todo funciona.


En MQ5 sólo tienes que sustituir la línea

uint items=ExtPipe.ReadDoubleArray(buffer);

на 

uint items=ExtPipe.ReadArray(buffer);
 
Renat:

Acabo de comprobarlo, todo funciona.


En MQ5 sólo tiene que sustituir la línea

No tengo ...

Reemplacé la línea o no compilaría.

1234567
Nuevo comentario