Discussion of article "Migrating from MQL4 to MQL5" - page 3

New comment
 

I propose to migrate double MarketInfo(string symbol, int type) as a set of functions returning different types of data, according to the specification of input parameters


For example, these functions:

int MarketInfoInt(string symbol, int type);

string MarketInfoStr(string symbol, int type)....

I once communicated with the developers about REFERENCES and results of functions, but they refused to do it (and it's a pity).


PS

On this basis, I think the best solution for this moment will be the MarketInfo library, which will contain all the required functions.

By the way, this is exactly what I have done in my own library :)

 
Interesting:

In my opinion two features are needed to handle TF in a migration environment:

1. Converts the number of seconds to TF - say ENUM_TIMEFRAMES SecondToPeriod (int Value);

2. Converts the period into seconds - say int PeriodToSecond(ENUM_TIMEFRAMES Value).


Which I successfully did in my migration module at the very beginning (there is also a DLL option).


PS

To maximise compliance with MQL4, I personally got rid of all non-standard for it periods



the function is good and useful, but the execution....

I would do it this way

//+------------------------------------------------------------------+
//||
//+------------------------------------------------------------------+
void FixTF(int &tf)
  {
   switch(tf)
     {
      case 0: tf = 0;break;
      case 1: tf = PERIOD_M1;break;
      case 5: tf = PERIOD_M5;break;
      case 15: tf = PERIOD_M15;break;
      case 30: tf = PERIOD_M30;break;
      case 60: tf = PERIOD_H1;break;
      case 240: tf= PERIOD_H4;break;
      case 1440: tf=PERIOD_D1;break;
      case 10080: tf = PERIOD_W1;break;
      case 43200: tf = PERIOD_MN1;break;
      default: tf=0;break;
     }
  }
//+------------------------------------------------------------------+



in all functions you just need to define the size of arrays

just like az buki vedi.

 
CoreWinTT:

the function is good and useful, but the execution..... is heresy.

your work??

WHERE BREAK!!!!!! grief programmers!!!!


How is return worse than break?
 
I apologise.
 
CoreWinTT:

in all function just need to define the size of arrays
simply as az'buki vedi.

Not always, see section Access to timeseries and indicators:

Functions for working with timeseries and indicators. A timeseries differs from a regular array in that the indexing of timeseries elements is done from the end of the array to the beginning (from the most recent data to the oldest). It is recommended to use only dynamic arrays for copying the values of timeseries and indicators, because the copying functions distribute the necessary size of arrays-receivers of values independently.

There is an important exception tothis rule : if copying of timeseries and indicator values should be done frequently, for example, at each call of OnTick() in Expert Advisors or at each call of OnCalculate() in indicators, then in this case it is better to use statically distributed arrays, because memory allocation operations for dynamic arrays require additional time and this will affect the testing and optimisation of Expert Advisors.

 
Rosh:

Not always, see Access to Timeseries and Indicators:


As my practice shows it is better to do it than not.

Otherwise a data access error appears

especially with global arrays.


Firstly, because in an array with a designated size indexing is static and there are no these dangerous moments of arrays of inverts.

secondly, the space for arrays is allocated more sparingly

and thirdly, the probability of an array access error is reduced many times.

That is why I think that these functions simply need a function for determining the array size.

 
CoreWinTT:

the function is good and useful, but here is the execution....

I would do it this way

The article has been modified:

  • restored the TFMigrate() function to its original form
  • changed functions in section 18
 
Added iMAOnArray(...) function to the Reference Manual
 
Fixed iMAOnArray function. In MODE_SMA mode calculation time is significantly reduced.
 

I started to doubt a lot about the functionality of this design. No matter how hard I tried to understand the logic of the block, I couldn't (and I tried hard)....

int iBarShiftMQL4(string symbol,
                  int tf,
                  datetime time,
                  bool exact=false)
  {
   if(time<0) return(-1);
   ENUM_TIMEFRAMES timeframe=TFMigrate(tf);
   datetime Arr[],time1;
   CopyTime(symbol,timeframe,0,1,Arr);
   time1=Arr[0];
   if(CopyTime(symbol,timeframe,time,time1,Arr)>0)
      return(ArraySize(Arr)-1);
   else return(-1);
  }
12345678910...13
New comment