Discussion of article "Communicating With MetaTrader 5 Using Named Pipes Without Using DLLs" - page 4

New comment
 
Renat:
When transmitting strings, 4 bytes of its size go first.

Fixed the function of receiving data with specifying the explicit buffer size.

Understood the reason why the reverse transfer didn't work - I didn't specify the length of the transferred data.

Thank you very much. Everything worked.

Pipes are powerful. Respect to the author of the article.

 
Renat:
It was done in the last build of MetaTrader 4.
I apologise, I thought I had missed something. I looked at the announcement 445 - there is indeed about pips there. The question is that there is no word about it in the help. Will there be any updates on this subject, and when? Maybe you can describe it in the forum.
 

Pipes in 4 work similarly to 5, also through file operations.

We will release an article for MT4.

 
Renat:

Pipes in 4 work similarly to 5, also through file operations.

We will release an article for MT4.

hello, can I have a simple example for MT4? I don't count on an article, of course.

I am specifically interested in how to read three parameters from my self-written programme into an Expert Advisor in the terminal.

 
Renat:
It was made in the last build of MetaTrader 4.

Everything seems to work fine on MT5.

The only point:

  • It would be good to make it so that when trying to read from the channel using ReadString and other methods, the integrity of the pipe-channel is checked first.

Otherwise, we hang in the WaitForRead method indefinitely, although the server side has been closed for a long time. All this was checked under Win7-64.

I added timeout and some other tricks to the WaitForRead method on the server side and got a working system with automatic reconnects on both sides of the channel,

but it's all a bit "crutchy".

 
Dima_S:

Everything seems to be working fine on MT5.

The only point:

  • It would be good to make it so that when trying to read from the channel using ReadString and other methods, the integrity of the pipe-channel is checked first.

Otherwise, we hang in the WaitForRead method indefinitely, although the server side has been closed for a long time. All this was checked under Win7-64.

I added timeout and some other tricks to the WaitForRead method on the server side and got a working system with automatic reconnects on both sides of the channel,

but it's all a bit "crutchy".

From our side it was a demonstration of the possibility.

Please post your variant of the class. We will finalise the standard class.

 
Actually, I added only WaitForRead method with error checking and exit by timeout ( waiting time - in conventional units - number of about 20msec intervals):
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 );
}


The client part itself looks roughly like this:

while( !IsStopped( ))
{
// Trying to connect to the server 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" );

// Data reception cycle:
    while( !IsStopped( ))
    {
// Check the integrity of the connection:
      if( !pipe_Ptr.WriteString( "@" ))
      {
        Print( "Disconnected: ", GetLastError( ));
        pipe_Ptr.Close( );
        break;
      }

// Retrieving data:
      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 );
}

The point is that the FileSize method, which is used while waiting for data to arrive, doesn't detect a connection violation ( apparently it doesn't check).

Timeout helps, but IMHO not in all possible situations. It would be good to check all these errors in the FileSize method.

 

Strange...

Pictures from the buffer don't get into comments and exactly if you use alt+PrntScr and paste it into the editor, the picture is inserted but the message doesn't get into the branch.

Okay, the problem is that the test example from the article doesn't go through

But in the terminal, the script doesn't log anything until I delete it from the chart.

and then I see in the 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 dated 21 March 2013

 

Just checked, everything works.


In MQ5 you only need to replace the line

uint items=ExtPipe.ReadDoubleArray(buffer);

на 

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

Just checked, everything works.


In MQ5 you only need to replace the line

I don't have ...

I replaced the line or it wouldn't compile.

1234567
New comment