Erros, bugs, perguntas - página 1742
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
A ajuda declara:
Nos modos de execução "Por Mercado" e "Troca" a política de preenchimento "Retorno" é sempre permitida para todos os tipos de ordens. A permissão de outros tipos é verificada usando propriedades SYMBOL_FILLING_FOK e SYMBOL_FILLING_IOC.
Mas nem sempre. Assim, em contas Robo "Return" não funciona, nem em contas Pro, nem em contas ECN.
A ajuda declara:
Nos modos de execução "Por Mercado" e "Troca" a política de preenchimento "Retorno" é sempre permitida para todos os tipos de ordens. A permissão de outros tipos é verificada usando propriedades SYMBOL_FILLING_FOK e SYMBOL_FILLING_IOC.
Mas nem sempre. Assim, nas contas Robo "Return" não funciona, nem nas contas Pro, nem nas contas ECN.
Fórum sobre comércio, sistemas comerciais automatizados e teste de estratégias comerciais
Insectos, insectos, perguntas
fxsaber, 2016.10.20 08:24
SB em todos os servidores comerciais//| Get the property value "ORDER_TYPE_FILLING" |
//+------------------------------------------------------------------+
ENUM_ORDER_TYPE_FILLING COrderInfo::TypeFilling(void) const
{
return((ENUM_ORDER_TYPE_FILLING)OrderGetInteger(ORDER_TYPE_FILLING));
}
SEMPRE no testador retornaENUM_ORDER_TYPE_FILLING::ORDER_FILLING_RETURN.
É por isso que se definir o preenchimento no OrderModify via COrderInfo::TypeFilling(), então no mesmo RoboForexEU-MetaTrader 5 haverá um erro lógico [Unsupported filling mode]. No entanto, este erro não ocorre em MetaQuotes-Demo - servidor do programador configurado erradamente?
A ajuda declara:
Nos modos de execução "Por Mercado" e "Troca" a política de preenchimento "Retorno" é sempre permitida para todos os tipos de ordens. A permissão de outros tipos é verificada usando propriedades SYMBOL_FILLING_FOK e SYMBOL_FILLING_IOC.
Mas nem sempre. Por exemplo, "Return" não funciona em contas Robo, nem em contas Pro, nem em contas ECN.
Tenho uma suspeita de que a configuração "Return" está por defeito em todos os servidores de comércio (pelo menos a FxPro respondeu a isso.
Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais
Modos de enchimento nos servidores
Karputov Vladimir, 2016.10.14 19:18
Modo de enchimento "Regressar":
Regresso
Sem identificação
Este modo é utilizado para ordens de mercado (Compra e Venda), ordens de limite e stop-limit e apenas nos modos "Execução de Mercado" e "Execução de Bolsa". No caso de execução parcial, uma ordem de mercado ou de limite com um volume residual não é removida, mas permanece em vigor.
Aqui está a resposta da empresa de corretagem sobreo modo "Return
O nosso perito MT5 confirmou com Metaquotes que o retorno é utilizado por defeito, e é aplicado quando não se escolhe nada sobre o enchimento.
)
Por outras palavras - é algum tipo de toco.Há uma suspeita de que a configuração de preenchimento "Return" é o padrão para todos os servidores de negociação (pelo menos a FxPro respondeu da mesma forma).
Por outras palavras - é algum tipo de toco.Em algumas empresas (em particular a MT5 começou recentemente) é necessário especificar o tipo de enchimento - se não especificar, haverá um erro.
Embora, no Robo, o servidor retorna verdadeiro para a verificação "Return", mas na realidade, este tipo de preenchimento não funciona. Em suma, é uma confusão total com estes preenchimentos.
{
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;
}
Compreendo correctamente que se o virtual na descendência for anulado, a base virtual nunca poderá ser alcançada? Ou seja, não há forma de chamar A::f de b.
Quase. Em C++, é permitida a seguinte entrada:
b.A::f();
Mas não se pode fazer isso aqui. Portanto, única e exclusivamente por muleta:
{
public:
virtual int f()
{
Print(__FUNCSIG__);
return(0);
}
int f1()
{
return A::f();
}
};
Quase. Em C++, é permitida a seguinte entrada:
b.A::f();
Então não percebo porque funciona em C++. Afinal de contas, um virtual anulado na tabela do método virtual deve ser completamente anulado. E não deve haver vestígios da base.
Mas é impossível fazê-lo aqui. É por isso que é apenas por muleta:
{
public:
virtual int f()
{
Print(__FUNCSIG__);
return(0);
}
int f1()
{
return A::f();
}
};
Afinal de contas, o virtual anulado na tabela do método virtual deve ser completamente anulado. E não deve haver vestígios do método de base.
Se o tipo for explicitamente especificado, o método é chamado directamente, sem utilizar a tabela de funções virtuais.
Desta forma, mesmo uma função puramente virtual pode ser chamada se tiver um corpo.
Então A* b = novo B; não vai funcionar.
Neste caso, é preciso outra muleta -- mover os internos da função na classe base para um método não virtual e chamá-lo dentro do virtual. Depois poderíamos chamar explicitamente método não-virtual da classe base e herdeiro.
Se o tipo for explicitamente especificado, o método é chamado directamente, sem utilizar a tabela de funções virtuais.
Mesmo uma função puramente virtual pode ser chamada desta forma se tiver um corpo.
Neste caso, precisamos de outra muleta, que seria mover as funções internas para um método não virtual na classe base e chamá-lo dentro da virtual. Então, poderia chamar explicitamente o método não-virtual tanto da base como do descendente.