Errors, bugs, questions - page 1185
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
Adopting only (*a) to refer to member functions does not give any clear advantages, but instead makes it impossible to use the operators in a simple and clear way.
Try to rewrite it taking your suggestion into account
You cannot use the object itself instead of the pointer because operator <<(...) can return only a pointer to the object.
You must have misunderstood me. I wasn't speaking about disabling the current implementation. I asked to make it additionally possible to take a reference or a pointer to an object so that you don't depend on the compiler's whims.And I will decide what to do in each case. If I'm in need of a super-reliable program, I can easily do it the way you've described. Yes, it's complicated. But if metaquotes suddenly introduce a special action of the << operator for pointers, we won't be afraid of it.
I didn't say to forbid the current implementation. I asked to make an additional possibility to take a reference or pointer to an object, so as not to depend on the whims of the compiler.
If (b) is an object, then the additional feature (&b) in addition to the existing GetPointer( b ) is clear - it brings the syntax closer to C++.
If (a) is a pointer, the additional feature (*a) in addition to the existing (a) probably gives a reasonable compromise
On the one hand, a contradiction is eliminated, and on the other hand, the existing order is not brokenThe compiler allows identically named variables in parameters and function bodies within the same scope
Although a warning is generated, it's not enough for such a hard-to-find error (in a large code). At least the C++ compiler generates the same error in the same casePerhaps the consequence of the previous error is that this construct
Causes execution error: Invalid EX5 file (8)Who has faced with it? How is it solved and what is the problem? Otkrytie broker.
When the price of a pending order is moved by drag'n'drop to a new level, SL/TP changes together with it. Can this be disabled? It is not always necessary to move SL/TP synchronously with the price.
How do you see it? I see it like this:
If you hold the Ctrl key, the pending order will move along with SL/TP. If you don't press Ctrl, it will move as it is now.
Also note that in terminal settings, you can set management of trading levels only when holding Alt. Then, you should press Ctrl+Alt for the interaction described above.
How do you see it? I see it like this:
If you hold the Ctrl key, the pending order will move along with SL/TP. If you don't press Ctrl, it will move as it is now.
Also note that in terminal settings, you can set management of trading levels only when holding Alt. Then for the interaction described above, press Ctrl+Alt.
Is this from the documentation? I've read about Alt and use it, not about Ctrl.
When the price of the pending order is moved by drag'n'drop to a new level, the SL/TP changes along with it. Is there any way to disable it? SL/TP should not always be moved synchronously with the price.