Diskussion zum Artikel "Communicating With MetaTrader 5 Using Named Pipes Without Using DLLs" - Seite 4

Neuer Kommentar
 
Renat:
Bei der Übertragung von Zeichenketten werden 4 Bytes ihrer Größe zuerst übertragen.

Die Funktion zum Empfangen von Daten mit Angabe der expliziten Puffergröße wurde korrigiert.

Ich habe den Grund verstanden, warum die Rückübertragung nicht funktioniert hat - ich habe die Länge der übertragenen Daten nicht angegeben.

Ich danke Ihnen sehr. Alles hat funktioniert.

Pipes sind mächtig. Respekt an den Autor des Artikels.

 
Renat:
Das wurde in der letzten Version von MetaTrader 4 gemacht.
Ich entschuldige mich, ich dachte, ich hätte etwas übersehen. Ich habe mir die Ankündigung 445 angesehen - dort ist tatsächlich von Pips die Rede. Die Frage ist, dass in der Hilfe kein Wort darüber zu finden ist. Wird es Updates zu diesem Thema geben, und wann? Vielleicht können Sie es im Forum beschreiben.
 

Pipes in 4 funktionieren ähnlich wie in 5, auch durch Dateioperationen.

Wir werden einen Artikel für MT4 veröffentlichen.

 
Renat:

Pipes in 4 funktionieren ähnlich wie in 5, auch durch Dateioperationen.

Wir werden einen Artikel für MT4 veröffentlichen.

Hallo, kann ich ein einfaches Beispiel für MT4 haben? Ich rechne natürlich nicht mit einem Artikel.

Mich interessiert konkret, wie ich drei Parameter aus meinem selbstgeschriebenen Programm in einen Expert Advisor im Terminal einlesen kann.

 
Renat:
Es wurde mit dem letzten Build von MetaTrader 4 erstellt.

Auf MT5 scheint alles gut zu funktionieren.

Der einzige Punkt:

  • Es wäre gut, wenn man es so einrichten könnte, dass beim Versuch, mit ReadString und anderen Methoden aus dem Kanal zu lesen, zuerst die Integrität des Pipe-Kanals überprüft wird.

Sonst hängen wir in der WaitForRead-Methode auf unbestimmte Zeit fest, obwohl die Serverseite schon lange geschlossen ist. All dies wurde unter Win7-64 geprüft.

Ich habe die WaitForRead-Methode auf der Serverseite mit Timeout und einigen anderen Tricks versehen und ein funktionierendes System mit automatischen Reconnects auf beiden Seiten des Kanals erhalten,

aber es ist alles ein bisschen "krüppelig".

 
Dima_S:

Auf MT5 scheint alles gut zu funktionieren.

Der einzige Punkt:

  • Es wäre gut, wenn man es so einrichten könnte, dass beim Versuch, mit ReadString und anderen Methoden aus dem Kanal zu lesen, zuerst die Integrität des Pipe-Kanals überprüft wird.

Sonst hängen wir in der WaitForRead-Methode auf unbestimmte Zeit fest, obwohl die Serverseite schon lange geschlossen ist. All dies wurde unter Win7-64 geprüft.

Ich habe die WaitForRead-Methode auf der Serverseite mit Timeout und einigen anderen Tricks versehen und ein funktionierendes System mit automatischen Reconnects auf beiden Seiten des Kanals erhalten,

aber es ist alles ein bisschen "krüppelig".

Von unserer Seite war es eine Demonstration der Möglichkeit.

Bitte posten Sie Ihre Variante der Klasse. Wir werden die Standardklasse fertigstellen.

 
Eigentlich habe ich nur die WaitForRead-Methode mit Fehlerprüfung und Beendigung durch Timeout (Wartezeit - in konventionellen Einheiten - Anzahl von ca. 20msec Intervallen) hinzugefügt:
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 );
}


Der Client-Teil selbst sieht ungefähr so aus:

while( !IsStopped( ))
{
// Versucht, eine Verbindung zum Server herzustellen 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" );

// Datenempfangszyklus:
    while( !IsStopped( ))
    {
// Überprüfen Sie die Integrität der Verbindung:
      if( !pipe_Ptr.WriteString( "@" ))
      {
        Print( "Disconnected: ", GetLastError( ));
        pipe_Ptr.Close( );
        break;
      }

// Abrufen von Daten:
      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 );
}

Der Punkt ist, dass die FileSize-Methode, die während des Wartens auf Daten verwendet wird, eine Verbindungsverletzung nicht erkennt (anscheinend prüft sie nicht).

Timeout hilft, aber IMHO nicht in allen möglichen Situationen. Es wäre gut, alle diese Fehler in der FileSize-Methode zu überprüfen.

 

Seltsam...

Bilder aus dem Puffer kommen nicht in die Kommentare und genau wenn man alt+PrntScr benutzt und in den Editor einfügt, wird das Bild eingefügt, aber die Nachricht kommt nicht in den Zweig.

Okay, das Problem ist, dass das Testbeispiel aus dem Artikel nicht durchgeht

Aber im Terminal protokolliert das Skript nichts, bis ich es aus dem Diagramm lösche.

und dann sehe ich im 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 vom 21. März 2013

 

Gerade überprüft, alles funktioniert.


In MQ5 müssen Sie nur die Zeile

uint items=ExtPipe.ReadDoubleArray(buffer);

на 

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

Gerade überprüft, alles funktioniert.


In MQ5 muss man nur die Leitung ersetzen

Ich habe keine ...

Ich habe die Zeile ersetzt, sonst würde es nicht kompilieren.

1234567
Neuer Kommentar