Discussão do artigo "Biblioteca para criação simples e rápida de programas para MetaTrader (Parte XXVII): trabalho com ordens de negociação - posicionamento de ordens pendentes" - página 3
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 sou eu quem não quer falar sobre o assunto, mas você não entendeu a essência desse tópico.
Você decidiu que eu não entendo que cada tipo de consulta adiada precisa de sua própria solução. Todas as solicitações têm suas próprias propriedades e uma solução comum é impossível. Uma solução para pedidos é uma solução, outra para solicitações repetidas de alguns dados. Nos dois últimos artigos, estamos trabalhando em uma solução para pedidos. O próximo também será sobre isso. Minha opinião é que isso é muito longo.
3 artigos para resolver uma solicitação pendente SOMENTE para pedidos, dois dos quais não completam nada.... Embora, de fato (não na forma), a solução para a solicitação de pedido pendente seja bastante fácil.
Você decidiu que eu não entendo que cada tipo de consulta pendente precisa de uma solução diferente. Todas as consultas têm suas próprias propriedades e uma solução comum é impossível. Uma solução para pedidos é uma solução, outra para solicitações repetidas de alguns dados. Nos dois últimos artigos, estamos trabalhando em uma solução para pedidos. O próximo também será sobre isso. Minha opinião é que ele é muito longo.
3 artigos para resolver uma solicitação pendente SOMENTE para pedidos, dois dos quais não completam nada.... Embora, de fato (não na forma), a solução da solicitação de ordem pendente seja bastante fácil.
A parte "impossível" é um pouco precipitada.
Exatamente, isso é impossível. Consultas de objetos diferentes - propriedades diferentes. Não é possível colocar todas as propriedades em um único objeto de consulta.
Fico imaginando como uma tarefa simples pode ser resolvida durante um mês e meio em três artigos. Se esse método de programação for considerado "eficiente", fico feliz por programar de forma diferente.
É impossível rastrear todas as chamadas do EA para o servidor.
Pergunto, porque a solução para o problema do envio repetido de ordens com falha (obviamente) não requer complicações e é resolvida de forma simples.
Se as ordens não forem enviadas usando os métodos da biblioteca, toda a lógica de negociação deverá ser escrita de forma independente. A biblioteca oferece uma oportunidade de não fazer isso, mas não o obriga a fazer tudo por meio de sua funcionalidade.
Em tal situação, a biblioteca não pode gerenciar funções de negociação que não sejam próprias. Mas ela poderá relatar o fato de uma solicitação de negociação bem-sucedida enviada por meio de funções de terceiros.
Use a funcionalidade da biblioteca, onde há uma reação aos erros retornados pelo servidor e seu processamento adequado.
O que você vê como um manipulador de códigos de retorno do servidor?
Exatamente, isso é impossível. Diferentes objetos de consulta - diferentes propriedades. Não é possível inserir todas as propriedades em um único objeto de consulta.
Fico imaginando como uma tarefa simples pode ser resolvida em três artigos durante um mês e meio. Se esse método de programação for considerado "eficiente", fico feliz por programar de forma diferente.
Os objetos são solicitações de negociação pendentes. Todas as informações sobre qualquer solicitação de negociação são armazenadas em uma única estrutura para todas as solicitações - MqlTradeRequest.
Você está trollando?
Na verdade, eu descrevo o conceito. Passo a passo. Em artigos (eu mesmo escrevo os textos, verifico se há erros três ou quatro vezes, e alguns deles me escapam). Expresso o conteúdo do conceito em artigos, a lógica e a funcionalidade, mostro como fazer isso. Ao mesmo tempo, penso em várias opções de antemão, e grande parte delas é jogada no lixo - ou seja, na verdade, escrevo código três ou quatro vezes mais do que há nos artigos. Às vezes, reescrevo completamente todo o código do zero e de acordo com princípios diferentes. Em seguida, testo tudo no testador e na demonstração - o que está descrito em cada artigo. E então sinto falta de alguns bugs e os corrijo mais tarde nos próximos artigos.
Se o código funcionar desde a primeira vez, isso significa que há uma bomba enterrada nele, e você deve esperar uma grande surpresa no futuro.
Fico surpreso que você escreva tudo sozinho em uma hora. Sem verificações, sem testes e contanto que ele se mova :)
Eu realmente gostaria de entender o que você considera simples aqui. Por que não quer entender que essa é uma parte da funcionalidade futura de outras partes da biblioteca, e que tudo o que for feito com antecedência deve ser vinculado "em sua mente" ao que ainda não existe, mas está planejado?
Eu não defino uma tarefa para fazer isso uma vez e deixá-la flutuar. Tenho uma tarefa diferente: pensar em como tudo será interconectado posteriormente. Isso leva tempo e requer uma certa abordagem. Se isso for difícil para você, bem... Então é complicado.
...
E o que você vê como o manipulador do código de retorno do servidor?
Vou lhe mostrar uma solução curta e eficaz.
1. Declare uma variável global: string Del_req;
2. Escreva a função void Delayed_request(). A função será chamada a partir de OnTimer() uma vez por segundo (se Del_req != NULL).
3. Adicione o parâmetro int delayed_request_ID = 0 a cada função de negociação que envia uma ordem.
4. Cada solicitação de negociação retorna uma resposta do servidor. Se delayed_request = 0 (não for uma chamada repetida de Delayed_request() ) e a resposta do servidor exigir a repetição da solicitação, as funções de negociação gravam todos os parâmetros de chamada na variável Del_req (por meio de dois separadores - delayed_request_ID e parâmetros) e, no final da linha, adicionam o número de tentativas necessárias (por exemplo, 10).
5. A função Delayed_request() verifica a cadeia de caracteres Del_req uma vez por segundo. Se a string não for NULL, a função a colocará em uma matriz e fará um loop para encontrar a substring da chamada, a encontrará, a extrairá da string total, a dividirá, verificará o tipo de chamada e passará os parâmetros para a função de negociação necessária juntamente com o delayed_request_ID. Em seguida, ele examina o contador de chamadas e o diminui em um. Se o contador for zero após a subtração de um, ele apaga toda a substring de chamada da string Del_req total.
6. Se a função de negociação aceitar uma chamada com delayed_request_ID e a solicitação ao servidor for bem-sucedida, ela apagará a subcadeia de chamadas da cadeia Del_req comum (localize-a por delayed_request_ID).
Tudo isso pode ser feito em um dia e pode ser aplicado não apenas a solicitações de negociação, mas a qualquer solicitação.
ZY. Sem trollagem, estou realmente surpreso com a não obviedade de soluções simples para programadores maduros.
Vou lhe mostrar uma solução curta e eficaz.
1) Declare uma variável global: string Del_req;
2. Escreva a função void Delayed_request(). A função será chamada a partir de OnTimer() uma vez por segundo.
3. Adicione um parâmetro int delayed_request_ID = 0 a cada função de negociação que envia uma ordem.
4. Cada solicitação de negociação retorna uma resposta do servidor. Se delayed_request = 0 (não uma chamada repetida de Delayed_request() ) e a resposta do servidor exigir a repetição da solicitação, as funções de negociação gravam todos os parâmetros de chamada na variável Del_req (por meio de dois delimitadores - delayed_request_ID e parâmetros) e, no final da linha, adicionam o número de tentativas necessárias (por exemplo, 10).
5. A função Delayed_request() verifica a cadeia Del_req uma vez por segundo. Se a cadeia não for NULL, a função a coloca em uma matriz e faz um loop para encontrar a chamada, encontra-a, extrai-a da cadeia total, divide-a, verifica o tipo de chamada e passa os parâmetros para a função de negociação necessária junto com o delayed_request_ID. Em seguida, ele examina o contador de chamadas e o diminui em um. Se o contador não for zero, Del_req altera o contador de chamadas na cadeia de chamadas para um valor menor que um; se for zero, ele apaga toda a cadeia de chamadas da cadeia Del_req total.
6. Se a função de negociação receber uma chamada com delayed_request_ID e a solicitação ao servidor for bem-sucedida, ela apagará a subcadeia de chamadas da cadeia Del_req total (localiza-a por delayed_request_ID).
Tudo isso pode ser feito em um dia e pode ser aplicado não apenas a solicitações de negociação, mas a quaisquer solicitações.
ZY: Sem trollagem, estou realmente surpreso com a não obviedade de soluções simples para programadores maduros.
Para deliberadamente colocar freios nos métodos?
E qual é a diferença entre o método proposto e o que está sendo feito? Além do fato de que você terá que trabalhar com funções caras para trabalhar com cadeias de caracteres? Conceitualmente, nada. É por isso que será como está sendo planejado. Além disso, o que está sendo feito, e você ainda não sabe disso, será usado para estender a funcionalidade de trabalhar com consultas diferidas.
Puxar conscientemente os freios nos métodos?
E qual é a diferença entre o método proposto e o que está sendo feito? Além do fato de que você terá que trabalhar com funções caras de trabalho com strings? Nenhuma. É por isso que será como está sendo planejado. Além disso, o que está sendo feito, e você ainda não sabe disso, será usado para estender a funcionalidade de trabalhar com consultas diferidas.
Faça como achar melhor. É sua criatividade. Eu expressei minha opinião.
E não há freios. As solicitações pendentes ainda são enviadas uma vez por segundo.
A diferença é que as solicitações pendentes não se transformam em objetos completos e, portanto, não arrastam muito código por trás delas.
Faça o que achar melhor. É sua arte. Eu dei minha opinião.
E não há freios. De qualquer forma, as solicitações pendentes são enviadas uma vez por segundo.
Por que elas são enviadas uma vez por segundo? Para inundar o servidor de negociação?
Ele se diferencia pelo fato de que as consultas pendentes não se transformam em objetos completos e, portanto, não arrastam muito código por trás delas.
E eu preciso de objetos completos para implementar o que planejei mais adiante. Mas você ainda não sabe disso e está tentando oferecer maneiras ineficazes de resolver uma pequena parte da tarefa para trabalho futuro. E aqui tudo está interligado, e o conceito geral é o mesmo - as outras coisas planejadas no futuro dependem dessa pequena parte.
De qualquer forma, obrigado por sua opinião - qualquer opinião é útil e faz sentido.
ZY: E, sim, não é terrível escrever um código funcional, extensível e compatível em vez de reescrever constantemente soluções incompletas escritas anteriormente de forma impensada para as próximas tarefas.