Erros, bugs, perguntas - página 989
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
Não, todas as máquinas são individuais. Até os eixos são licenciados, desde a grusha até à WS. Tenho um sentimento de presunção de culpa. Vai ter de arranjar desculpas... Justificar-me... Registos, este e aquele...
Vender mais agentes de fechaduras do que os núcleos deve ser proibido e mais nada!
...
E colocar mais agentes de fechaduras do que núcleos deve ser proibido por lei, é tudo!
Boa tarde. Tenho uma pergunta para os criadores. O ciclo ideal de geração de transacções consiste nos seguintes passos:
1.Enviar um pedido através de OrderSend() seguido de verificação de que o método retornou o verdadeiro e correcto retcode.
2.A seguir, é necessário seguir a passagem do pedido no servidor através da OnTradeTransaction(). Este manipulador é muito útil e dá total controlo sobre o processo.
Mas vivemos no mundo real e, por exemplo, devido a falha de ligação ou simplesmente porque a transacção foi "perdida na entrega", não podemos esperar por transacções como TRADE_TRANSACTION_REQUEST. Assim, o ciclo de espera tornar-se-á interminável e será impossível determinar se a transacção foi concluída a pedido ou não.
Existe algum procedimento ANTECEDENTES para lidar com tais emergências com a obtenção inequívoca de uma conclusão de processo logicamente correcta para qualquer força maior? Por exemplo, se não esperarmos pelo TRADE_TRANSACTION_REQUEST dentro de 20 (ou 30 ou 40) segundos, então mudamos para um algoritmo mais lento mas correcto, nomeadamente: comparamos o volume do símbolo actual com o volume antes de OrderSend(), pesquisamos o histórico de encomendas e calculamos o seu estado e decidimos se fazemos mais um pedido para abrir ou saltar o sinal. A tarefa torna-se ainda mais complicada para o método OrderSendAsync(): temos de ter um critério preciso de quando uma determinada ordem não foi accionada e saber quando começar a aplicar esse critério. Se eu entender algo de errado, por favor corrijam-me.
Para o método OrderSendAsync(), a tarefa é ainda mais complicada - é necessário ter um critério exacto para que uma ordem específica não seja accionada e saber quando aplicar este critério. Se eu entender algo de errado, por favor corrijam-me.
HistorySelectByPosition - em teoria, deve ajudar, a identificação é dada quando a encomenda é enviada.
VanHelsing:
Os sistemas 32x Win7 têm problemas com operações com números reais, em XP recusa-se a trabalhar ao passar valores para a biblioteca"wininet.dll".
1. Fazer uma regra para enviar ordens de negociação no tick actual e verificar a sua execução no tick seguinte. Então, não terá laços infinitos.
2. Ao verificar a execução de ordens dadas durante o tick anterior, não se incomode com OnTrade()/ OnTradeTransaction(). Verifique as alterações no estado da sua conta, ou seja, trabalhe com a fonte. Afinal, qualquer acordo comercial tem por objectivo alterar o estado da sua conta de negociação. Portanto, verifique a mudança no estado.
3. Dependendo dos resultados dos testes e faça mais lógica do seu robô.
Antes de utilizar funções como OnTrade()/OnTradeTransaction(), decida o que é mais importante para si:
a). conseguir a abertura/fecho/alteração de uma posição em determinadas condições de mercado;
b) Perder o seu tempo a tentar descobrir a razão pela qual a sua ordem comercial não foi executada, e a procurar alguém a quem culpar.
Ainda assim, fiquei com algum mal-entendido. Se os resultados da verificação no tick seguinte NÃO mostrarem quaisquer alterações na posição, então o que devemos fazer neste caso. As razões para a ausência de mudanças podem ser bastante diferentes. Como alternativa:
uma ordem a pedido foi formada no servidor, mas foi rejeitada por alguma razão,
o servidor está sobrecarregado - a execução é atrasada,
a ligação é perdida durante algum tempo.
Gostaríamos de ter um critério exacto para que a ordem não seja executada. A ligação ao tempo num sistema assíncrono não me parece muito precisa e, portanto, permite a incerteza. Talvez faça sentido seleccionar a ordem a partir do histórico e verificar o seu estado, ou, como sugerido por sion, utilizar HistorySelectByPosition. Presumo que se os criadores conceberam este sistema desta forma, então deveria haver métodos "correctos" de lidar com tais operações-chave.
Queremos ter um critério exacto para que a ordem não seja executada
Já lhe foi explicado que
não se preocupe com OnTrade()/ OnTradeTransaction().
Trabalhar com o código fonte.
Olá a todos!
Como posso fazer com que todo o conteúdo do separador "Especialistas" seja sobrescrito quando o guião começa? (Como um comando cls), porque pode ser difícil distinguir onde a saída de impressão do início anterior do guião e a actual acabou.
Obrigado!!!
Olá a todos!
Como posso fazer com que todo o conteúdo do separador "Especialistas" seja sobrescrito no início do guião? (Como um comando cls), porque pode ser difícil distinguir onde terminou a saída de impressão do início anterior do guião e a actual.
Obrigado!!!
Adicione a seguinte linha ao deinit do guião
Imprimir("===================== O Fim ===================")