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
i might be wrong, but this seems to be the first scenario where i would use a GlobalVariable
You make a good point, given that Fromin explicitly limits his/her requirements to "in one MT4 terminal at once".
The file-locking route has the disadvantages of complexity and requiring "Allow DLL imports" to be turned on. However, it also has three small advantages:
* If MT4 crashes or an EA/script shuts down in a disorderly fashion, a global-variable lock will remain in place and have to be manually removed. The file-based lock can be done in a way which is automatically freed when MT4 terminates.
* The file-based method is more future-proof; it offers the possibility of extending the locking beyond the single MT4 instance.
* I'm not 100% sure that MT4 synchronises access to global variables. If you have two EAs starting at exactly the same time, e.g. because MT4 is starting up with EAs already in place on its charts, then it may be possible for both EAs to think that the lock is free because e.g. they both call GlobalVariableCheck() before either of them then goes on to acquire a lock by calling GlobalVariableSet(). Or, depending on how you code it, two simultaneous calls to GlobalVariableSet() might both return 0.
However, it also has three small advantages: [...]
* It's very easy for the user to manually override a global-variable lock and allow multiple EAs to trade at once. Whereas a lock which is done by having or not having an open file handle (i.e. my version of the code) requires specialist tools to override.
You make a good point, given that Fromin explicitly limits his/her requirements to "in one MT4 terminal at once".
The file-locking route has the disadvantages of complexity and requiring "Allow DLL imports" to be turned on. It has three small advantages over global variables:
* If MT4 crashes or an EA/script shuts down in a disorderly fashion, a global-variable lock will remain in place and have to be manually removed. The file-based lock can automatically be freed when MT4 terminates.
* The file-based method is more future-proof; it offers the possibility of extending the locking beyond the single MT4 instance.
* I'm not 100% sure that MT4 synchronises access to global variables. If you have two EAs starting at exactly the same time, e.g. because MT4 is starting up with EAs already in place on its charts, then it may be possible for both EAs to think that the lock is free because e.g. they both call GlobalVariableCheck() before either of them then goes on to acquire a lock by calling GlobalVariableSet(). Or, depending on how you code it, two simultaneous calls to GlobalVariableSet() might both return 0.
Hi, i agree with the crash situation, which your file lock mechanism would handle nicely. Good point here is that you only lock the file but don't write anything into it. Could be tricked out by writing the actual time in the global variable and if there was no update in the last X minutes the EA could regain operation status.
GlobalVariableSetOnCondition() operations seems (according to the doc) providing atomic access so the syncho will not be a problem.
I personally would go for the GlobalVar() solution, but maybe because i don't want to use dll's if possible. I had to many problems when switching form xp to win7 to wine (operating in osx)
Of course, there's also a fourth difference which could either be an advantage or disadvantage as far as Fromin is concerned:
* It's very easy for the user to manually override a global-variable lock and allow multiple EAs to trade at once. Whereas a lock which is done by having or not having an open file handle (i.e. my version of the code) requires specialist tools to override.
GlobalVariableSetOnCondition() operations seems (according to the doc) providing atomic access so the syncho will not be a problem. [...]
You're right. I'd forgotten about GlobalVariableSetOnCondition(). It ought to be possible to do the following, though this route is vulnerable to abuse if you can delete the global variable and start a second EA in between ticks to the first EA. Relatively easy to do overnight or at the start/end of the week. Both EAs then believe that they're in control of the global variable. Protecting against that would complicate the code yet further.
That issue is easy to ship around.
If the GlobalVariable is not existend, simply create it and set it to unlocked, of course at this moment you don't have the lock. Afterwards you can use GVSetOncondition to lock it.
The only problem with your routine is when you start two EA's simultaneosly and both pass the first GlobalVariableCheck() call. Theoretically it would be possible that both of the EA's are able to get a lock.
sorry for the formatting, i typed it here in the comment box.
If the GlobalVariable is not existend, simply create it and set it to unlocked, of course at this moment you don't have the lock. Afterwards you can use GVSetOncondition to lock it.
Much the same problem. In your code, once an EA reaches the state where hasLock == true then it's still the case that all it is does is a check for the existence of the global variable. The way to cheat your code is as follows:
The only significant point is that all this is close to becoming more complex than the equivalent file I/O code. If you strip out all the stuff from my earlier example which isn't directly relevant to the single-instance scenario, then it's very debatable which is more complicated.
The only significant point is that all this is close to becoming more complex than the equivalent file I/O code. If you strip out all the stuff from my earlier example which isn't directly relevant to the single-instance scenario, then it's very debatable which is more complicated.
The file I/O route for a single-instance solution looks like this. There's a very strong argument that this is simpler than global variables, and while it does require "Allow DLL imports" to be turned on, it's not using DLLs in the usual worry-inducing sense of custom DLLs which are prone to be flaky and cause MT4 to crash. It's not actually necessary to delete the lock file, and therefore you could save three further lines of code by removing the import of DeleteFile(); the global variable which holds the filename; and the use of DeleteFile() in deinit().
You are right, i missed that point.
Since the EA's have no options to identify itself by some unique number all those options will fail.
Your file lock seems to be the only valid solution in addition with the options to lock more then one mt4 instance
can someone help me edit sar ohlc to use heiken ashi ohlc
Hi, I have an MTF indicator that uses sar, however I'd like the sar to calculate heiken ashi ohlc, and not the normal type
Can you tell me how I can do this, my mtf indicator calls to the sar indicator to calculate sar formula, I think it is calling to the internal indicator in mt4 that can not edit
you can skype or email if you can assist and like to talk about it
skype sty671
email sty671@gmail.com
I can also supply the original file that I'm trying to use heiken ashi ohlc for