Empty4 v600 for Coders

[SpiderX]

Hi,

Thought that it would be nice to make a checklist of stuff to do when porting EA's over to the new version 600.
Please feel free to suggest stuff to add to this checklist, and will do my best to update this first post.

1. Replace all names with "." i.e "var1.limit" , change the "." to "_" , eg. "var1_limit"
2. All "return; " must be converted to "return(0);"
3. Function variables should not have same name as global variables
4. Replace StringSubStr with StringSubStrOld.
You need to add the function below into your EA code.

Reference: http://www.forexfactory.com/showthread. ... ost7268388

Code: Select all

string StringSubstrOld(string x,int a,int b=-1) {
if (a < 0) a= 0; // Stop odd behaviour
if (b<=0) b = -1; // new MQL4 EOL flag
return StringSubstr(x,a,b);
}

5. indicator_color is no longer valid, replace with indicator_color1
6. Add #property strict on top of the code and compile.
This would flush out more errors and warnings.
7.
Reference: http://www.stevehopwoodforex.com/phpBB3 ... 914#p88899
Need to add a boolean variable to catch the output of OrderSelect, OrderClose etc.

Code: Select all

bool Order_Select=false;
if(lastTicket>=0)
{
   Order_Select=OrderSelect(lastTicket,SELECT_BY_TICKET,MODE_TRADES);
}

Lets add on to the list as we find more stuff.
Cheers

[milanese]

Thank you for bringing this topic

Cheers

Tommaso

[dietcoke]

I have found that MQ4 function libraries where the functions are imported via an MQH header file compile ok, but new mq4 appears not to call the functions when the code that is using themi is run.

I have been having problems with an EA which uses LibOrdrReliable. basically, t wasn't opemning, modifying or closing anything until I moved the library functions to the include folder and renamed to MQH. Would be intereste to know if anyne else has seen this or tried it to fix another problem

[AnotherBrian]

I like the new compiler although it is talking smack about my code Good to know the shortfalls.

2. All "return; " must be converted to "return(0);" Agree, except for "void" functions where you use return; since it is not supposed to return a value.

Try putting #property strict at the top and the compiler.
http://forum.mql4.com/60555

Working with functions, scope of variables and memory release in local arrays has also been changed. Since the number of changes is large enough, the new #property strict property has been introduced to provide maximum compatibility with the previous approach to developing MQL4 programs. When creating new MQL4 application using MQL wizard, this property is always added to the template. The table below contains the differences between MQL4, new MQL4 without using strict and new MQL4 with specified strict compilation mode.

* Please pay special attention to "Array out of range" error - many old custom indicators will display this error in strict mode of the new compiler when launched on the chart. It is recommended to find the cause and eliminate it.

[SpiderX]

Hi all,

Yes. #property strict seems to do some stuff.
Putting it in BASA introduces the following errors and warnings

-implicit conversion from number to string
-possible loss of data due to type conversion
-possible use of uninitialized variable

Error
- xxx -undeclared identifier

This one is easy to resolve, the problem occurs when you have

Code: Select all

if(x==1) int y=5;

Solution is

Code: Select all

int y;
if(x==1) y=5;

Need to rack my brains on how to solve the rest.

Cheers

[SpiderX]

Next warning: implicit conversion from 'number' to 'string'

Results from

Code: Select all

SM("Magic number: "+MagicNumber+NL);

Solution:

Code: Select all

SM(StringConcatenate("Magic number: ",MagicNumber,NL));

Cheers

Edit: These turn out to be a lot of trouble to correct....would be great if someone can provide a quicker solution.

[renexxxx]

In my opinion, CrapQuotes has created a total mess with v60x, as it is the stepping stone to MQL5, but with (some) backward compatibility to MQL4.

For instance, for indicators we had in MQL4

Code: Select all

//+------------------------------------------------------------------+
//| Custom indicator initialization function                         |
//+------------------------------------------------------------------+
int init()
  {
//---- indicators
//----
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator deinitialization function                       |
//+------------------------------------------------------------------+
int deinit()
  {
//----
   
//----
   return(0);
  }
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int start()
  {
   int    counted_bars=IndicatorCounted();
//----
   
//----
   return(0);
  }

In Empty4-Build 60x that is now replaced by:

Code: Select all

int OnInit()
  {
//--- indicator buffers mapping
   
//---
   return(INIT_SUCCEEDED);
  }
//+------------------------------------------------------------------+
//| Custom indicator iteration function                              |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
//---
   
//--- return value of prev_calculated for next call
   return(rates_total);
  }
//+------------------------------------------------------------------+

However, the old format is still supported in Empty4-60x. That means that 95% of the Empty4 developers will continue to use the old format and will have to convert later -- because one thing is for certain, one day CrapQuotes will turn around and declare that the old way is no longer supported (eg. in v70x).

The next step, no doubt, will be is to get away from the internal indicator functions (such as: iMA(...)) and replace them with the IndicatorCreate(), to create a handle and to use CopyBuf() when you want to use the values, like this is now done in MQL5.

In this total mess, I find it hard to create "future-proof" code, as the MQL language/compiler is undergoing rapid changes. That means that us, coders, are too busy changing code, that we have no more time to actually make money. Thoughts?

[SpiderX]

As long as we have that stuff which we have in between our ears running...I guess we can take whatever they throw at us right ?

Cheers

[Pedigree]

As long as we have that stuff which we have in between our ears running...I guess we can take whatever they throw at us right ?

Cheers

Thank you so much for starting this. It is sorely needed and will be such great help.

A Question: What redress, if any, is there to help 509 dlls retain their viability in 6xx other than a complete re-write?

[SpiderX]

Apologies but I got no experience with dll.
Hopefully someone here is able to help you.

Cheers