Strategy tester trades not closing the strategy tester's opened ACTIVE trades - page 2
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
Above I provided a link in my answer for syncing global variables (at writing).
If you see correct values both in indicator and EA, then check/debug the trading part of code as I suggested w/o a signal.
Yes, thank you. I will do some further testing and come back with the results.
Thanks for your time.
MQL programs (indicator and EA) runs in separate threads, each of which can be paused and resumed by operating system behind the scenes at any microscopic moment. So you can set one variable but not another, and inbetween of this EA tries to read incomplete set of data.
Just one last question. How much should I be leaning on these results? I've read a couple articles about how it's important to forward test as well. When is a good spot to say, it's good enough to rely on for real-life trading on a demo?
I ask, because I've spent a lot of time getting to this point, and for the longest time I couldn't even get my code to run in ST, but it feels soo valuable if you can hinge strong decisions on the tester. There is only so much time in a trading day, and let's be honest, there isn't a lot of action to get good forward test results at the moment. Let alone a EA only placing a couple trades a day will take a very long time to start bringing together enough data to decide whether or not to put on a live account.
Just one last question. How much should I be leaning on these results? I've read a couple articles about how it's important to forward test as well. When is a good spot to say, it's good enough to rely on for real-life trading on a demo?
I ask, because I've spent a lot of time getting to this point, and for the longest time I couldn't even get my code to run in ST, but it feels soo valuable if you can hinge strong decisions on the tester. There is only so much time in a trading day, and let's be honest, there isn't a lot of action to get good forward test results at the moment. Let alone a EA only placing a couple trades a day will take a very long time to start bringing together enough data to decide whether or not to put on a live account.
I'm not sure I got you right, because it seems a bit off topic for original subject. Of course, optimization and finding best parameters on history worths a little if you do not perform a forward test which confirms that EA with these settings keeps making profits in a wild. Every algotrader does this, because it works statistically - that means that your win online is very probable but not guaranteed. The tester allows you to analyze and test the history with sufficient number of trades, for example, several years if you have 2 trades per day in average - this way the results are statistically significant.
Yes, a bit off topic, but since you seemed like the right person to ask.
Thank you. =)
It appears that the issue is global variables. Per these posts they are simulated and not used the same as in real testing. Now I've got to dig into finding an alternative...
https://www.mql5.com/en/forum/11224
https://www.mql5.com/en/forum/224907
This post is interesting. It doesn't appear to work as it's not a native functionality. The search continues as apparently using files doesn't work that great.
https://www.mql5.com/en/forum/277766/* Functions --------- bool InitByChart (string prefix=NULL, CHART id=NULL, bool commonfolder=false) bool Init (string filename, bool commonfolder) bool SetDouble (string name, double value, bool permanent=false) bool SetString (string name, string value, bool permanent=false) double GetDouble(string name, bool reload=true) string GetString(string name, bool reload=true) bool IsDefined(string name, bool reload=true) bool Delete(string name, bool reload=true) bool DeleteAll(string prefix=NULL, bool reload=true) bool Update() datetime GetTC(string name) Prop-Functions -------------- bool AutoUpdate(bool flag) - default ON bool AutoUpdate() bool Display(bool flag) - default OFF bool Display() bool Prefix(string value=NULL) - If NULL, a unique prefix is used string Prefix() long GetUniqueId - Returns a unique identifier Predefined objects ------------------ __ChartVars - database with variables in the sandbox of the chart __LocalVars - database with variables limited to the current instance of MT4/MT5 __GlobalVars - global data, valid for all instances of either MT4 or MT5 __GlobalVarsMTX - global data, valid for all instances of any MT4 and MT5 Sample without initialization / direct usage ----------------- __ChartVars.SetDouble("Value",1) double v=__ChartVars.GetDouble("Value"); Architecture of var database ---------------------------- int - number of records (m_cnt) SDBVarsData[] - main records 0-max (m_data[]) int[] - string index table (m_sx[]) string[] - string records 0-max Comments -------- The focus is performance. Therefore the main table in SDBVarsData[] is always compressed. When a record is removed, the remaining records are shifted and on every access, the main table is loaded at once into memory. But, shifting strings would decrease speed due to too many disk accesses. Therefore the strings are allocated via a string-index table. This way, a record of the main table which points to a string, only has the index to the string and when it is shifted during compression, the string itself remains at the same physical adress. */Yes, a bit off topic, but since you seemed like the right person to ask.
Thank you. =)
It appears that the issue is global variables. Per these posts they are simulated and not used the same as in real testing. Now I've got to dig into finding an alternative...
Since you have a EA and an indicator, and oneway flow of information (signals) from the indicator to the EA, the easiest and most proper way of communication would be via indicator buffer: just create an additional indicator buffer to store signals and price levels, update its several elements on ticks, and read them from EA as usual via CopyBuffer.
As for global variables - they do work in tester, but every Windows process (either the terminal, or the tester agent) has its own set of global variables. So, when you run a test, global variables are created and shared by all programs inside the test, yet they are separate to those global variables which exist in the terminal. It's ok to use global variables in the tester. The only problem I pointed out is a probable unsynchronization of their writing/reading among concurrently running MQL programs - this aspect should be properly handled in any case - not only in the tester, but in the terminal as well.
All sorted. Turned out to be a if nesting issue. I've kept your recommendations though to improve my code.
I am also testing 2-3 EA's at the same time (including this one) on a demo account, so I closed those to prevent the same global variables from being shared. Or, is it safe to assume the GVs in the tester and in the console are not a shared workspace?
Thank you for all your support and time!
All sorted. Turned out to be a if nesting issue. I've kept your recommendations though to improve my code.
I am also testing 2-3 EA's at the same time (including this one) on a demo account, so I closed those to prevent the same global variables from being shared. Or, is it safe to assume the GVs in the tester and in the console are not a shared workspace?
The live account and the tester (each agent on its own) have their own storages of global variables, but if you run multiple EAs on a demo account online they all access the same storage of global variables, so you need to use, for example, unique prefixes in the names to prevent them to interfere with each other.