Discussion de l'article "Communiquer avec MetaTrader 5 en utilisant Named Pipes sans utiliser de DLL" - page 4

Nouveau commentaire
 
Renat:
Lors de la transmission de chaînes de caractères, 4 octets de leur taille sont placés en premier.

Correction de la fonction de réception de données avec spécification de la taille explicite de la mémoire tampon.

J'ai compris la raison pour laquelle le transfert inverse ne fonctionnait pas - je n'avais pas spécifié la longueur des données transférées.

Merci beaucoup. Tout a fonctionné.

Les tuyaux sont puissants. Respect à l'auteur de l'article.

 
Renat:
Cela a été fait dans la dernière version de MetaTrader 4.
Je m'excuse, je pensais avoir manqué quelque chose. J'ai regardé l'annonce 445 - il y a effectivement des pips. La question est qu'il n'y a aucun mot à ce sujet dans l'aide. Il y aura-t-il des mises à jour sur ce sujet, et quand ? Vous pouvez peut-être en parler dans le forum.
 

Les tuyaux de la version 4 fonctionnent de la même manière que ceux de la version 5, y compris par le biais d'opérations sur les fichiers.

Nous publierons un article pour MT4.

 
Renat:

Les tuyaux de la version 4 fonctionnent de la même manière que ceux de la version 5, y compris par le biais d'opérations sur les fichiers.

Nous publierons un article pour MT4.

Bonjour, puis-je avoir un exemple simple pour MT4 ? Je ne compte pas sur un article, bien sûr.

Je suis spécifiquement intéressé par la façon de lire trois paramètres de mon programme auto-écrit dans un Expert Advisor dans le terminal.

 
Renat:
Elle a été faite dans la dernière version de MetaTrader 4.

Tout semble fonctionner correctement sur MT5.

Le seul point :

  • Il serait bon de faire en sorte que lorsque l'on essaie de lire à partir du canal en utilisant ReadString et d'autres méthodes, l'intégrité du pipe-channel soit d'abord vérifiée.

Sinon, nous restons indéfiniment dans la méthode WaitForRead, bien que le serveur soit fermé depuis longtemps. Tout ceci a été vérifié sous Win7-64.

J'ai ajouté un délai d'attente et d'autres astuces à la méthode WaitForRead côté serveur et j'ai obtenu un système fonctionnel avec des reconnexions automatiques des deux côtés du canal,

mais tout cela est un peu "béquille".

 
Dima_S:

Tout semble fonctionner correctement sur MT5.

Un seul point :

  • Il serait bon de faire en sorte que lorsque l'on essaie de lire le canal à l'aide de ReadString et d'autres méthodes, l'intégrité du pipe-channel soit d'abord vérifiée.

Sinon, nous restons indéfiniment dans la méthode WaitForRead, bien que le serveur soit fermé depuis longtemps. Tout ceci a été vérifié sous Win7-64.

J'ai ajouté un délai d'attente et d'autres astuces à la méthode WaitForRead côté serveur et j'ai obtenu un système fonctionnel avec des reconnexions automatiques des deux côtés du canal,

mais c'est un peu "béquille".

De notre côté, c'était une démonstration de la possibilité.

Veuillez nous faire part de votre variante de la classe. Nous finaliserons la classe standard.

 
En fait, je n'ai ajouté que la méthode WaitForRead avec vérification des erreurs et sortie par timeout (temps d'attente - en unités conventionnelles - nombre d'intervalles d'environ 20 ms) :
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 partie client elle-même ressemble à peu près à ceci :

while( !IsStopped( ))
{
// Essai de connexion au serveur 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" );

// Cycle de réception des données :
    while( !IsStopped( ))
    {
// Vérifier l'intégrité de la connexion :
      if( !pipe_Ptr.WriteString( "@" ))
      {
        Print( "Disconnected: ", GetLastError( ));
        pipe_Ptr.Close( );
        break;
      }

// Récupération des données :
      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 );
}

Le problème est que la méthode FileSize, qui est utilisée en attendant que les données arrivent, ne détecte pas de violation de connexion (apparemment, elle ne vérifie pas).

Le délai d'attente aide, mais IMHO pas dans toutes les situations possibles. Il serait bon de vérifier toutes ces erreurs dans la méthode FileSize.

 

C'est étrange...

Les images de la mémoire tampon ne sont pas insérées dans les commentaires et si l'on utilise alt+PrntScr et qu'on le colle dans l'éditeur, l'image est insérée mais le message n'est pas inséré dans la branche.

Ok, le problème est que l'exemple de test de l'article ne passe pas

Mais dans le terminal, le script n'enregistre rien jusqu'à ce que je le supprime du graphique.

et je vois alors dans le journal 

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 daté du 21 mars 2013

 

Je viens de vérifier, tout fonctionne.


Dans le MQ5, il suffit de remplacer la ligne

uint items=ExtPipe.ReadDoubleArray(buffer);

на 

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

Je viens de vérifier, tout fonctionne.


Dans le MQ5, il suffit de remplacer la ligne

Je n'ai pas ...

J'ai remplacé la ligne sinon ça ne compilerait pas.

1234567
Nouveau commentaire