MetaTrader 4 Build 600 with Updated MQL4 Language and Market of Applications Released - page 38
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Want to BUMP the idea of ........
Tools>Option>Debug - add start date and start time - if populated then will backtest + debug - if not populated will debug on ticks (latest) as currently does.
This allows offline and weekend backtesting+debugging and pattern targeting.
Might mention some have created idea that you can backtest renko and range charts - think they have MQH + "server account entry"
Is commercial so am reluctant to mention here in case get into trouble.
But it is a concept that is worth considering by Meta guys so will risk it
http://www.az-invest.eu/backtesting-range-bars-in-metatrader-4 ... see server setting
Might ask them if they can do as described above on normal bars.
How?
Clicking compile button in the cpp code invokes the C++ compiler.
I have waited years for MetaQuotes to implement these into MQL4. I finally get my wish, and they BOTH have been implemented WRONG. WHY?
TimeGMT should give me the GMT time. PERIOD. NOT taking into account Daylight Savings and NOT taking into account local time.
TimeGMTOffset should give me the difference between GMT time and my BROKER's time. Again, NOT anything to do with local time or Daylight Savings.
FXDD is GMT+2 right now, but using TimeGMT and calculating the offset myself using:
int GMTOffset = ((TimeCurrent()-TimeGMT())/3600);
... I sometimes get 3, sometimes 2, sometimes 1.
This is rediculous!
Also, per Forex Factory, the Sessions in GMT time change twice a year, when the U.S. (New York) observes DST change. This means I calculate DST myself, because I don't want the DST given by computer by each user of my EAs no matter where in the world they are, I want it to only change twice a year. If you want to know what they are, you can see my webpage here showing the session times: <link remoed by moderator>
Up to this point, I have used multiple MS codes I found on net to give me GMT time, MT4GUI, HTTTP, and MQL4 to get GMT time to calculate offsets, and only ONE of all of them is correct, and now it's name conflicts with new MQL4 function name (TimeGMT).
So it looks like I will have to continue using the one method that consistently works and forget using MQL4 functions. I guess I'm just frustrated because:
1. It should not be difficult to ascertain session times.
2. It should not be difficult to asertain GMT time or GMT offset from BROKER TIME.
Yet in all this time (I've been using MQL4 since 2007) these two things can't be made to work by the developers of the software yet I can do it.
Clicking compile button in the cpp code invokes the C++ compiler.
Ratz. I was hoping more along the line of supporting managed code (ie. C#).
Ok. First wish list item for the next build:
We have Volume[] and iVolume to get tick volume data. Yet, the only way to get lot volume is through CopyRealVolume(params ). How about adding RVolume[] and/or iRVolume() or something of the sort?
Ok. First wish list item for the next build:
We have Volume[] and iVolume to get tick volume data. Yet, the only way to get lot volume is through CopyRealVolume(params ). How about adding RVolume[] and/or iRVolume() or something of the sort?
And it would be a good idea to make that data visible at least in the data window, or even in the main window.
And it would be a good idea to make that data visible at least in the data window, or even in the main window.
The new data structure is ready to accept the real volume, just not implemented. I guess this feature has very low priority currently, as there are many unimplemented features that must be solved preferably.
Ok. First wish list item for the next build:
We have Volume[] and iVolume to get tick volume data. Yet, the only way to get lot volume is through CopyRealVolume(params ). How about adding RVolume[] and/or iRVolume() or something of the sort?
oh, I notice that ArrayCopy result data order change from OLHC to OHLC:
old version complied script run on v604:
Thank you. Fixed