the new Data Types are very annoying!!

 

The easiest way for an EA to get information either from another chart or from the previous start was to use GlobalVariables.

But they only exists and can take and provide doulbes: 8 byte.

If you now want to save a long (int) 8 byte too variable its typ is casted and it may lose its exact value - so you can't use Global Variables anymore:

Look at this example:

        GlobalVariableSet("myScript", ChartID() );
        Print((string)((long)GlobalVariableGet("myScript"))," == ",(string)ChartID()," => ",
               ( (long)GlobalVariableGet("myScript") == ChartID() ) );

i get:

2014.03.25 21:18:25.329 myScript GBPUSD,M1: 130370193351027472 == 130370193351027474 => false

I would like to use this to give an EA a way of self-organizing for a multi-currency-trading.

The same may happen with datetime it is an integer value with as well 8 bytes. Is you save it in a global variable you may get back a false = different value!!

Thanks Metaquotes!

 

global variables is designed to contain doubles

datetime GlobalVariableSet(

string name, // Global variable name
double value // Value to set

);

so try to use another method like FileWrite
regardless it more reliable than globalvariables

 
gooly:

The easiest way for an EA to get information either from another chart or from the previous start was to use GlobalVariables.

But they only exists and can take and provide doulbes: 8 byte.

If you now want to save a long (int) 8 byte too variable its typ is casted and it may lose its exact value - so you can't use Global Variables anymore:

Look at this example:

i get:

I would like to use this to give an EA a way of self-organizing for a multi-currency-trading.

The same may happen with datetime it is an integer value with as well 8 bytes. Is you save it in a global variable you may get back a false = different value!!

Thanks Metaquotes!


As usual you criticize from how you think things should be and not based on how things are. It's a waste of time. I suggest you to read the documentation carefully, and adapt your code to work as the documentation says. If something is not permitted by the language, you have to find an other way. You can always make suggestion for improvements by writing to ServiceDesk.

About datetime there is no problem to save them in GlobalVariables up to 2038 or something.

If you explain what you are trying to achieve with long/datetime and GlobalVariables, maybe we can try to help you.


 
angevoyageur:

As usual you criticize from how you think things should be and not based on how things are. It's a waste of time. I suggest you to read the documentation carefully, and adapt your code to work as the documentation says. If something is not permitted by the language, you have to find an other way. You can always make suggestion for improvements by writing to ServiceDesk.

About datetime there is no problem to save them in GlobalVariables up to 2038 or something.

If you explain what you are trying to achieve with long/datetime and GlobalVariables, maybe we can try to help you.




Nah, it is better for gooly to write his own master dll, so that when there is updates, that dll can straight away adapt to it.

For me, last time my ea works only up to build 509. Since then, the code have a major improvement to work to the latest build of 625.

Because what I see here, the mql language will keep on going forward, not backwards. So I have to improve myself so that I can catch-up as fast as the build releases or prepare myself to take on any new build releases as soon as possible.

That's the way I see right now. Instead of complaining, I am updating myself too. Nice and smart way.

When you are updating yourself, you will find no time to complain anymore. :)

 
angevoyageur:


About datetime there is no problem to save them in GlobalVariables up to 2038 or something.


the size of an int is: 2147483647 (+) seconds in a year: 31556926

so you have 68 years + 18 days + 15 hours + 57 min. + 59 sec. since 01/01/1970 00:00 to use it (LOL)

 

I want my multi-currency-trading EA to organize itself on several charts with different setups (currencies to trade).

That should be fail save by either a script and/or if solely applied to a chart, so that e.g. no setup is installed twice and another one is missing.

To find the right setup it should know what and where a setup is already installed and running.

For this the various ChartID (ChartFirst, ChartID, ChartNext) would be ideal - if their IDs could be communicated to other charts.

It would be a lot easier if the ID would only between 0 and 100 (=CHARTS_MAX). This is what I initially thought and this could be used as an index for the array of the setups e.g. - I thought.

Then I realized that it is a huge, huge number like the serial code of some hardware??

For what else a ChartID could be used than to compare it to another chartID. But for this you have to communicate to another chart - how would you do it?

Named Pipes? Isn't that a bit like using a sledgehammerto crack a little nut? I need that only for the installation.

Another way would be if I would be able to get the name of the EA that is running on another chart.

I can get all the indicators of another chart (ChartIndicatorsTotal() and ChartIndicatorName() ), I can get the ChartSymbol(ChartID) of another Chart but not the name of the EA and may be its status (running, stopped,...)

They have provided so many new functions ..AsInteger(), ..AsDouble(), ..AsString().

All this first gave me hope for an elegant solution which is immediately disappointed.

I'll try tomorrow ChartSetString() ChartGetString().

Good night.


 
qjol:

the size of an int is: 2147483647 (+) seconds in a year: 31556926

so you have 68 years + 18 days + 15 hours + 57 min. + 59 sec. since 01/01/1970 00:00 to use it (LOL)


datetime has (now?) 8 bytes like long (ChartID) and doubles - int only 4 bytes!! If the (date-) number is small - I guess far earlier than the highest possible date - you don't have a problem!

Bt if not you will have the same problem I have with the ChartID.

In the prv version we had only int (4 bytes) and doubles 8 (bytes) and we did not had problems casting int to doubles.

I could be that the reason is the internal representation of doubles: mantissa and exponent and then a difference of 1,2,3.. or even more is within the accepted accuracy.

:(

 
i have a sulotion for you use your own ChartID
double MyChartID(long chartid)
   {
   long mydiv = 20000000000;
   double mychartid = chartid / mydiv;
   return(mychartid);
   }
 
qjol:

the size of an int is: 2147483647 (+) seconds in a year: 31556926

so you have 68 years + 18 days + 15 hours + 57 min. + 59 sec. since 01/01/1970 00:00 to use it (LOL)

I think the GV double can hold a much bigger datetime than that, it should be able to hold 999999999999999.0 which is about 31 million years.
 
you right but still not the size of a long
 

yes thats true, and in 31 million years we will need the gv to be a long but, judging by the way my ea's work on backtesting every one of them would have lot the entire federal budget several times over and bankrupted the entire planet by then lol

Reason: