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
Agora faz sentido!
Com assíncrono, apenas uma linha é escrita
correspondente a isto.
E NÃO há outra linha no diário de bordo! Assim, ele se igualaria a este.
O registro obviamente não está completo com o processamento assíncrono.
Mas com o processamento síncrono, há duas linhas no registro
2017.02.17 16:20:47.323 Trades '1007932': order #54042531 sell limit 1.00 / 1.00 RTS-3.17 at 121520 done in 15.978 ms
É por isso que os modos síncrono e assíncrono foram executados em tempo igual (o que é logicamente suposto) e o log do terminal informa que o modo assíncrono é duas vezes mais rápido. Isto é uma mentira/erro!
Podemos concluir.
No modo assíncrono, o registro não está completo e é enganoso.
A conclusão pode ser tirada.
No modo assíncrono, o registro não está completo e é enganoso.
Sim, mas isso infelizmente não resolve o problema de latência....
Em SD escreveu há muito tempo.
Eu também estou otimista :)
Eu escrevi para o RS há muito tempo
Minhas aplicações são respondidas muito prontamente. Talvez a linguagem que eu uso seja mais compreensível para os desenvolvedores do que a sua.
Às vezes tenho dificuldade de entender o que você quer dizer.
Mas às vezes a FOK não funciona, escreve erro 4756.
Estou usando SB, particularmente para compras:
1.0, // объем позиции
текущий аск, // цена исполнения
NULL, // символ
0.0, // цена Stop Loss
0.0, // цена Take Profit
ORDER_TIME_DAY, // тип истечения
0, // время истечения
"" // комментарий
)
Colegas, por favor, aconselhem sobre este ponto. Sempre usei a política ORDER_FILLING_RETURN em FORTS e agora tenho a tarefa de testar ORDER_FILLING_FOK.
Mas às vezes a FOK não funciona, escreve erro 4756.
Estou usando SB, particularmente para compras:
1.0, // объем позиции
текущий аск, // цена исполнения
NULL, // символ
0.0, // цена Stop Loss
0.0, // цена Take Profit
ORDER_TIME_DAY, // тип истечения
0, // время истечения
"" // комментарий
)
4756
Falha no envio do pedido comercial
Não tem nada a ver com o preenchimento de pedidos.
Trace a SB, talvez você veja onde o erro ocorre.
4756
Falha no envio do pedido comercial
Não tem nada a ver com o preenchimento de pedidos.
Traceroute SB, veja se você pode ver onde o erro ocorre.
Aqui está um trecho do histórico do pedido e da transação:
Verifique se o corretor apóia o derramamento da FOK
int filling_mode = int(SymbolInfoInteger(a_symbol, SYMBOL_FILLING_MODE));
if((SYMBOL_FILLING_IOC & filling_mode) != SYMBOL_FILLING_IOC)
{
MessageBox("Символ " + a_symbol + " не поддерживает filling IOC режим исполнения ордеров!", "Ошибка", MB_OK | MB_ICONHAND);
return(false);
}
if((SYMBOL_FILLING_FOK & filling_mode) != SYMBOL_FILLING_FOK)
{
MessageBox("Символ " + a_symbol + " не поддерживает filling FOK режим исполнения ордеров!", "Ошибка", MB_OK | MB_ICONHAND);
return(false);
}
Adicionado
E veja em SB function bool CTrade::FillingCheck(const string symbol)
Aqui está um extrato do histórico do pedido e da transação:
Um limitador pode ser FOK?
No fórum, eles postaram um recurso de seleção automática de tipo de preenchimento.