Submitorder jforex mt4

Detalhe do Método submitOrder Envia um novo pedido. A ordem devolvida está no status IOrder. State. CREATED e será atualizada para o status IOrder. State. OPENED após a confirmação do servidor. Parâmetros: rótulo - identificador definido pelo usuário para o pedido. O rótulo deve ser exclusivo para a conta de usuário especificada entre os pedidos atuais. Caracteres permitidos: letras, números e. O rótulo deve ter no máximo 256 caracteres. instrumento - instrumento orderCommand - tipo de valor do pedido enviado - valor em milhões para o preço do pedido - preço preferencial para o pedido. Se zero, o último preço de mercado visível no JForex será usado. O preço deve ser divisível em 0,1 pips ou o pedido será rejeitado. No caso de ordens de mercado, o preço incorreto (pior do que o mercado atual) será alterado para o preço atual e o slippage de slippage - slippage. O valor de slippage significa seguinte: se negativo, então o valor padrão de 5 pips é usado se Double. isNaN (slippage) true, então nenhum slippage é usado, deslize é definido em pips, você deve passar 1, não 0.0001 stopLossPrice - preço do parar a perda de. O preço deve ser divisível em 0,1 pips ou o pedido será rejeitado takeProfitPrice - preço do take profit. O preço deve ser divisível por 0,1 pips ou o pedido será rejeitado goodTillTime - quanto tempo o pedido deve durar se não for executado. Somente se 0, então orderCommand NÃO deve ser nem IEngine. OrderCommand. BUY nem IEngine. OrderCommand. SELL market order. comentário - comentário que será salvo na ordem Retorna: nova instância de pedido no estado IOrder. State. CREATED Lança: JFException - se label não é válido ou já existe, se goodTillTime 0 e orderCommand não é BID / OFFER, se o valor for menor que mínimo permitido, se alguns dos parâmetros necessários forem nulos submitOrder Envia novo pedido. A ordem retornada está no status IOrder. State. CREATED e será atualizada para o status IOrder. State. OPENED após a confirmação do servidor Parâmetros: rótulo - identificador definido pelo usuário para o pedido. O rótulo deve ser exclusivo para a conta de usuário especificada entre os pedidos atuais. Caracteres permitidos: letras, números e. O rótulo deve ter no máximo 256 caracteres. instrumento - instrumento orderCommand - tipo de valor do pedido enviado - valor em milhões para o preço do pedido - preço preferencial para o pedido. Se zero, o último preço de mercado visível no JForex será usado. O preço deve ser divisível em 0,1 pips ou o pedido será rejeitado. No caso de ordens de mercado, o preço incorreto (pior do que o mercado atual) será alterado para o preço atual e o slippage de slippage - slippage. O valor de slippage significa seguinte: se negativo, então o valor padrão de 5 pips é usado se Double. isNaN (slippage) true, então nenhum slippage é usado, deslize é definido em pips, você deve passar 1, não 0.0001 stopLossPrice - preço do parar a perda de. O preço deve ser divisível em 0,1 pips ou o pedido será rejeitado takeProfitPrice - preço do take profit. O preço deve ser divisível por 0,1 pips ou o pedido será rejeitado goodTillTime - quanto tempo o pedido deve durar se não for executado. Somente se 0, então orderCommand NÃO deve ser nem IEngine. OrderCommand. BUY nem IEngine. OrderCommand. SELL market order. Retorna: nova instância de pedido no estado IOrder. State. CREATED Lança: JFException - se label não é válido ou já existe, se goodTillTime 0 e orderCommand não são BID / OFFER, se o valor for menor que o mínimo permitido, se alguns dos parâmetros requeridos é null submitOrder Envia novo pedido. A ordem retornada está no status IOrder. State. CREATED e será atualizada para o status IOrder. State. OPENED após a confirmação do servidor Parâmetros: rótulo - identificador definido pelo usuário para o pedido. O rótulo deve ser exclusivo para a conta de usuário especificada entre os pedidos atuais. Caracteres permitidos: letras, números e. O rótulo deve ter no máximo 256 caracteres. instrumento - instrumento orderCommand - tipo de valor do pedido enviado - valor em milhões para o preço do pedido - preço preferencial para o pedido. Se zero, o último preço de mercado visível no JForex será usado. O preço deve ser divisível em 0,1 pips ou o pedido será rejeitado. No caso de ordens de mercado, o preço incorreto (pior do que o mercado atual) será alterado para o preço atual e o slippage de slippage - slippage. O valor de slippage significa seguinte: se negativo, então o valor padrão de 5 pips é usado se Double. isNaN (slippage) true, então nenhum slippage é usado, deslize é definido em pips, você deve passar 1, não 0.0001 stopLossPrice - preço do parar a perda de. O preço deve ser divisível em 0,1 pips ou o pedido será rejeitado takeProfitPrice - preço do take profit. O preço deve ser divisível por 0,1 pips ou o pedido será rejeitado Retorna: nova instância de pedido no estado IOrder. State. CREATED Lança: JFException - se o rótulo não for válido ou já existir, se o valor for menor que o mínimo permitido, se algum dos requisitos parameters is null submitOrder Envia um novo pedido. A ordem retornada está no status IOrder. State. CREATED e será atualizada para o status IOrder. State. OPENED após a confirmação do servidor Parâmetros: rótulo - identificador definido pelo usuário para o pedido. O rótulo deve ser exclusivo para a conta de usuário especificada entre os pedidos atuais. Caracteres permitidos: letras, números e. O rótulo deve ter no máximo 256 caracteres. instrumento - instrumento orderCommand - tipo de valor do pedido enviado - valor em milhões para o preço do pedido - preço preferencial para o pedido. Se zero, o último preço de mercado visível no JForex será usado. O preço deve ser divisível em 0,1 pips ou o pedido será rejeitado. No caso de ordens de mercado, o preço incorreto (pior do que o mercado atual) será alterado para o preço atual e o slippage de slippage - slippage. O valor de slippage significa seguinte: se negativo, então o valor padrão de 5 pips é usado se Double. isNaN (slippage) true, então nenhum slippage é usado, deslize é definido em pips, você deve passar 1, não 0.0001 Returns: new order instance no estado IOrder. State. CREATED Lança: JFException - se o rótulo não for válido ou já existir, se o valor for menor que o mínimo permitido, se algum dos parâmetros necessários for nulo submitOrder Envia um novo pedido. A ordem devolvida está no status IOrder. State. CREATED e será atualizada para o status IOrder. State. OPENED após a confirmação do servidor. Nota: o valor padrão de 5 pips de slippage é usado. Para especificar o slippage personalizado ou desabilitar o slippage, use os métodos extended submitOrder (.). Parâmetros: rótulo - identificador definido pelo usuário para o pedido. O rótulo deve ser exclusivo para a conta de usuário especificada entre os pedidos atuais. Caracteres permitidos: letras, números e. O rótulo deve ter no máximo 256 caracteres. instrumento - instrumento orderCommand - tipo de valor do pedido enviado - valor em milhões para o preço do pedido - preço preferencial para o pedido. Se zero, o último preço de mercado visível no JForex será usado. O preço deve ser divisível em 0,1 pips ou o pedido será rejeitado. No caso de ordens de mercado, o preço incorreto (pior do que o mercado atual) será alterado para o preço atual e slippage. Retorna: nova instância de pedido no estado IOrder. State. CREATED Lança: JFException - se label não é válido ou já existe, se o valor é menor que o mínimo permitido, se alguns dos parâmetros necessários forem nulos Consulte também: submitOrder (String, Instrument, OrderCommand, double, double, double). submitOrder (String, Instrumento, OrderCommand, double, double, double, double, double). submitOrder (String, Instrument, OrderCommand, duplo, duplo, duplo, duplo, longo). submitOrder (String, Instrumento, OrderCommand, double, double, double, double, long, String) submitOrder Envia um novo pedido. A ordem devolvida está no status IOrder. State. CREATED e será atualizada para o status IOrder. State. OPENED após a confirmação do servidor. Nota: o valor padrão de 5 pips de slippage é usado. Para especificar o slippage personalizado ou desabilitar o slippage, use os métodos extended submitOrder (.). Parâmetros: rótulo - identificador definido pelo usuário para o pedido. O rótulo deve ser exclusivo para a conta de usuário especificada entre os pedidos atuais. Caracteres permitidos: letras, números e. O rótulo deve ter no máximo 256 caracteres. instrumento - instrumento orderCommand - tipo de pedido enviado. Somente IEngine. OrderCommand. BUY e IEngine. OrderCommand. SELL são permitidos nesta quantidade de método - quantidade em milhões para a ordem Devoluções: nova instância de ordem no estado IOrder. State. CREATED Lança: JFException - se o rótulo não for válido ou já existir, se amount é menor que o mínimo permitido, se alguns dos parâmetros necessários forem nulos ou se orderCommand não for BUY ou SELL See Also: submitOrder (String, Instrumento, OrderCommand, double, double, double). submitOrder (String, Instrumento, OrderCommand, double, double, double, double, double). submitOrder (String, Instrument, OrderCommand, duplo, duplo, duplo, duplo, longo). submitOrder (String, Instrumento, OrderCommand, double, double, double, double, long, String) getOrder Retorna a ordem por label, ou null se nenhuma ordem for encontrada getOrderById Parâmetros: orderId - orders id Retorna: order ou null. getOrders, 24 25. : FX 24 25 18:00 GMT 24 23:00 GMT 24 18:45 GMT 25 23:00 GMT 27 17:30 GMT 24 EUA30.IDX / USD, USATECH. IDX / USD, USA500.IDX / USD. 7:00 GMT 25 18:00 GMT 25 USA30.IDX / USD, USATECH. IDX / USD, USA500.IDX / USD. 7:00 GMT 28 17:30 GMT 24 JPN. IDX / JPY. 1:00 GMT 25 18:00 GMT 25 JPN. IDX / JPY. 1:00 GMT 28 18:00 GMT 24 LIGHT. CMD / USD 23:00 GMT 24 18:00 GMT 25 LIGHT. CMD / USD. 23:00 GMT 27 17:30 GMT 24 BRENT. CMD / USD 1:00 GMT 25 18:45 GMT 25 BRENT. CMD / USD. 1:00 GMT 28 Dukascopy 21 ndash 22 Fórum Dukascopy Bank Lantern Fundo 21 -22. . CFD, CFD 7. , USD / MXN 1:10,. 8,. . , USD / MXN CFD 1:10. Dukascopy AO VIVO. (EUR / RUB) AO VIVO. EUR / RUB 1:10. . TROCA . 1: 10 USD / MXN: USD 30 000, 27 de Outubro de 2016, Dukascopy: CFD, das 09: 10h às 14: 00h; Dukascopy 27 de 2016, Dukascopy: 6, 22:00 GMT, USD / MXN 1:10. . 8 10:00 GMT, 30.000 USD (7). (US $ 30.000), 8,. 9, 05:00 GMT. Dukascopy 25 2016, 30,. , 21:00 GMT / 5pm EST. 22:00 CET /. 6 22:00 GMT / 5pm EST / 23:00 CET /. 20 2016 Dukascopy Dukascopy Bank, cópia DUKES COPY LTD dukes. , (sfc. hk/web/EN/alert-list/all. html1738), Dukascopy. , forex,. Dukascopy 30 2016, 3,, 3, FX, 3 r CFD, 3 DEU. IDX / EUR, CFDsPara os últimos 4-5 meses, o backtesting de uma estratégia que estamos desenvolvendo vem indo muito bem. Aproximadamente 85 das entradas nos testes de backtesting tiveram os lotes preenchidos. (Todo o caminho até a versão 2.1.4 da plataforma do cliente) Como uma nota lateral, uma das equipes de desenvolvimento, já levantou um ID de ticket: DKW-979094 sobre esse problema. Na segunda-feira, 12 de janeiro, usando o novo cliente 2.1.5 backtesting a mesma estratégia inalterada com os mesmos parâmetros e descobrimos que 80-85 em negociações foram rejeitadas Ordem falhou, tentando novamente. O teste de backtesting, uma vez testado, estava completo, declarado cancelado por falta de liquidez pelo preço. Descobrimos mais tarde que o parâmetro slippage de 2 (que havia trabalhado por 4-5 meses antes com a plataforma do cliente anterior à v2.1.5) era muito baixo para permitir que as entradas do backtest fossem preenchidas. Quando levantamos o escorregão para 20/30/40, os negócios que são rejeitados são muito menores. (mas impacta fortemente o desempenho da estratégia) Tentamos recompilar o Java e o JFX usando uma versão 2.5 da API. Isso não resolveu o problema. Parece que o mecanismo de preenchimento de pedidos para o backtesting mudou - isso pode ter a ver com o deslocamento do tamanho mínimo do lote. (de 0.1 a 0.01) Isso é muito frustrante depois de 4-5 meses de esforços que parecem ter sido desperdiçados depois que o software cliente da plataforma foi atualizado para 2.1.5 (Atualização: problema ainda existe com o cliente v2.1.13). a estratégia por um tempo considerável, mas estamos agora em uma perda agora e, por enquanto, não vá em frente com a abertura de uma conta real. O backtester é uma vantagem competitiva muito considerável que o Duakscopy comparou com todos os outros corretores. O MT4 é muito limitado em suas capacidades de backtesting e, até onde eu saiba, ninguém mais desenvolveu backtesters com funcionalidades realísticas de múltiplos pares e preço de compra. O código para fazer pedidos está listado abaixo. Estamos usando o JFX API 2.5 e o jftoolbox 1.6. Estou ciente de que o submitOrderSync do JFToolBox também aguarda uma resposta do pedido, mas queríamos esperar um pouco mais se o pedido não fosse preenchido. Usar a modificação acima corrige o problema que estávamos vendo. Quando tentei os testes esta manhã, meu cliente não viu nenhuma alteração, mas depois de recompilar, recebi os resultados esperados. Eu não sei o que mudou entre as versões do JForex para introduzir originalmente o problema, mas está funcionando agora. Obrigado pela ajuda. Ignore o texto original abaixo Este código não faz a diferença. Antes do novo cliente, essa estratégia era testada sem problemas. Depois que o novo cliente foi implementado, a mesma estratégia exatamente com os mesmos parâmetros durante o mesmo período de tempo começou a ter problemas durante o backtest. 80 de ordens agora falham. Nosso código não mudou, apenas o cliente JForex fez. Algo mudou no JForex na forma como os pedidos são preenchidos durante um backtest. Fizemos alguns experimentos para tentar reduzir o problema e descobrimos que, se ampliarmos o desvio de um valor de 2 para valores mais altos, como 20 a 30, o número de pedidos com falha diminuirá significativamente, mas o resultado é que a estratégia não é mais rentável. Para reiterar, antes do novo cliente, um parâmetro de slippage de 2 foi executado com êxito sem nenhum pedido com falha. Depois que o novo cliente estava disponível. O deslizamento de 2 causa 80 ou mais falhas de pedido na mesma estratégia durante o mesmo período. Alargar o parâmetro de slippage em uma ordem de magnitude (20 a 30 em vez de 2) reduz o número de pedidos com falha, mas altera significativamente o resultado da estratégia. Uma vez que estamos tendo problemas é com o par de moedas GBPUSD 2007-04-05 10:58:03. O que mudou no modo como a JForex preenche pedidos durante o backtesting no novo JForex Client