
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
TerminalCompany issue: version 610-618
my script use TerminalCompany() to determine the server timezone,
when I install a cleaning mt4 version from forexTime, run TerminalCompany() will got "ForexTime Ltd."
but if I use a mt4 instance init install from MetaQuotes demo server, then switch to forexTime demo server and open demo account and login,
run TerminalCompany() will return "MetaQuotes Software Corp.", it's the init install version company string, not the new one.
Those stop loss levels are on his broker's server. The broker needs to explain why their server is not closing orders. That demo server needs rebooted apparently.
Sorry, but I fail to see what would a reboot change? If the stop loss data is already on server side, nothing should be changed.
I can understand that a broker omits stop loss execution on one tick, two ticks ... but constantly? For how long would that broker last? But since the broker still exists shouldn't the cause for the problem be seeked for at other place(s) ... so common at these days? Or these are going to be new rules of trading using metatrader terminal in which case not so bright times ahead of traders coming
all the best
TerminalCompany issue: version 610-618
my script use TerminalCompany() to determine the server timezone,
when I install a cleaning mt4 version from forexTime, run TerminalCompany() will got "ForexTime Ltd."
but if I use a mt4 instance init install from MetaQuotes demo server, then switch to forexTime demo server and open demo account and login,
run TerminalCompany() will return "MetaQuotes Software Corp.", it's the init install version company string, not the new one.
Why not use AccountCompany? As the server is determined by the account not the branded terminal?
thank you, it works fine.
Is this a BUG?
Is this a BUG?
It is an annoying thing about the way computers handle doubles, even though it prints 8.800000000000001 it is 8.8
No, NormalizeDouble() does not format for printing . . . for that purpose you should be using DoubleToStr() or DoubleToString()
Well, I am using Print to see what is inside the double. I believe that if I can't truncate to 4 or 5 digit the triggering and math will be unstable. This problem did not existed on the prior 5.9 version.
Notwithstanding the Print() function, in prior version if I had a problem with a triggering, usually when testing for "0", I would truncate by using NormalizeDouble() -- so how do you truncate?