Errors, bugs, questions - page 1742
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
The help states:
In "By Market" and "Exchange" execution modes the fill policy "Return" is always allowed for all order types. Allowance of other types is checked using SYMBOL_FILLING_FOK and SYMBOL_FILLING_IOC properties.
But not always. So on Robo accounts "Return" doesn't work, neither on Pro, nor on ECN accounts.
The help states:
In "By Market" and "Exchange" execution modes the fill policy "Return" is always allowed for all order types. Allowance of other types is checked using SYMBOL_FILLING_FOK and SYMBOL_FILLING_IOC properties.
But not always. So, on Robo accounts the "Return" does not work, neither on Pro, nor on ECN accounts.
Forum on trading, automated trading systems and testing trading strategies
Bugs, bugs, questions
fxsaber, 2016.10.20 08:24
SB on all trading servers//| Get the property value "ORDER_TYPE_FILLING" |
//+------------------------------------------------------------------+
ENUM_ORDER_TYPE_FILLING COrderInfo::TypeFilling(void) const
{
return((ENUM_ORDER_TYPE_FILLING)OrderGetInteger(ORDER_TYPE_FILLING));
}
ALWAYS in the tester returnsENUM_ORDER_TYPE_FILLING::ORDER_FILLING_RETURN.
That's why if you set filling in OrderModify via COrderInfo::TypeFilling(), then on the same RoboForexEU-MetaTrader 5 there will be a logical error [Unsupported filling mode]. However, this error doesn't occur in MetaQuotes-Demo - wrongly configured developer's server?
The help states:
In "By Market" and "Exchange" execution modes the fill policy "Return" is always allowed for all order types. Allowance of other types is checked using SYMBOL_FILLING_FOK and SYMBOL_FILLING_IOC properties.
But not always. For example, "Return" does not work on Robo accounts, neither on Pro, nor on ECN accounts.
I have a suspicion that the "Return" setting is default for all trade servers (at least FxPro answered so.
Forum on trading, automated trading systems and trading strategies testing
Filling modes on servers
Karputov Vladimir, 2016.10.14 19:18
Filling mode "Return":
Return
No ID
This mode is used for market (Buy and Sell), limit and stop-limit orders and only in "Market Execution" and "Exchange Execution" modes. In the case of partial execution, a market or limit order with a residual volume is not removed, but remains in effect.
Here is the reply from the brokerage company regardingthe "Return" mode
Our MT5 expert has confirmed with Metaquotes that return is used by default, and its applied when you choose nothing on filling.
)
In other words - it's some kind of stub.There is a suspicion that the "Return" fill setting is the default for all trading servers (at least, FxPro answered as such).
In other words - it's some kind of stub.In some companies (in particular MT5 has been recently launched) it is necessary to specify the type of filling clearly - if you do not specify, there will be an error.
Although, in Robo, the server returns true for "Return" check, but in fact, this type of fill does not work. In short, it's a total mess with these fills.
{
public:
virtual int f()
{
Print(__FUNCSIG__);
return(0);
}
};
class B : public A
{
public:
virtual int f()
{
Print(__FUNCSIG__);
return(0);
}
};
void OnStart()
{
// A* b = new B;
B* b = new B;
((A*)b).f();
delete b;
}
Do I understand correctly that if virtual in descendant is overridden, the base virtual can never be reached? I.e. there is no way to call A::f from b.
Almost. In C++, the following entry is allowed:
b.A::f();
But you can't do that here. Therefore, only and exclusively by crutch:
{
public:
virtual int f()
{
Print(__FUNCSIG__);
return(0);
}
int f1()
{
return A::f();
}
};
Almost. In C++, the following entry is allowed:
b.A::f();
Then I don't understand why it works in C++. After all, an overridden virtual in the virtual method table should be completely overridden. And there should be no trace of the base one.
But it's impossible to do so here. That's why it is only by crutch:
{
public:
virtual int f()
{
Print(__FUNCSIG__);
return(0);
}
int f1()
{
return A::f();
}
};
After all, the overridden virtual in the virtual method table should be completely overridden. And there should be no trace of the base method.
If the type is explicitly specified, the method is called directly, without using the virtual function table.
This way, even a pure virtual function can be called if it has a body.
Then A* b = new B; will not work.
In this case, you need another crutch -- move the function internals in the base class to a non-virtual method and call it inside the virtual one. Then we could explicitly call non-virtual method from base class and inheritor.
If the type is explicitly specified, the method is called directly, without using the virtual function table.
Even a purely virtual function can be called this way if it has a body.
In this case, we need another crutch, which would be to move the function internals to a non-virtual method in the base class and call it inside the virtual one. Then, you could explicitly call the non-virtual method from both base and descendant.