Aprender e escrever juntos em MQL5 - página 18

Novo comentário
 
Yedelkin:

Bem, já percebeu o ponto. Digo-lhe meticulosamente, pode verificar: a função OrderSend() devolve um valor booleano. Neste caso, se o pedido for verificado com sucesso, o bilhete de encomenda é escrito em variável da estrutura MqlResult. Chamo-lhe "função de devolução do bilhete de encomenda" para mim. Aqui está o link para a fonte:"Ao enviar um pedido de compra utilizando a função OrderSend(), pode descobrir imediatamente o bilhete da encomenda que foi criada se o pedido for verificado com sucesso.

E se vai divagar do tema por iniciativa do moderador, tem uma resposta semelhante: não há e nunca haverá um tutorial MQL5, por isso não está claro, que tutorial está a ver... Talvez possamos discutir a substância da discussão, ou nada? :)

Obrigado pela resposta sobre a 'proibição', recebi-a.

Não há uma compreensão correcta do que irá acontecer quando se recebe uma resposta do servidor.

OrderSend() devolve realmente um valor booleano, mas não é o mais importante - o principal é a estrutura, que é preenchida quando se recebe uma resposta do servidor.

Sim, nós escrevemos um bilhete na estrutura (não só encomendas, mas também negócios), mas será mais importante do que o resto da informação na estrutura?

Vamos analisar a estrutura da resposta. Na minha opinião, o quadro é aproximadamente o seguinte

struct MqlTradeResult
{
//Очень важная информация
uint     retcode;          // Код результата операции
//Важная информация (важна при успешном запросе)
ulong    deal;          // Тикет сделки, если она совершена
ulong    order;         // Тикет ордера, если он выставлен
//Малосущественная информация (важна при успешном запросе, а также в случае реквоты)
double   volume;        // Объем сделки, подтверждённый брокером
double   price;         // Цена в сделке, подтверждённая брокером
//Малосущественная информация (важна при реквоте)
double   bid;           // Текущая рыночная цена предложения (цены реквота)
double   ask;           // Текущая рыночная цена спроса (цены реквота)
//Не существенная информация
string   comment;       // Комментарий брокера к операции (по умолчанию заполняется расшифровкой)
};

PS

O nome correcto para uma estrutura é MqlTradeResult e não MqlResult (embora na minha opinião não seja muito importante).

Se o pedido for correcto e executado, então o volume e o preço são importantes no caso do servidor "ter o direito" de reduzir os parâmetros de dados da transacção e pode exigir uma reacção do Expert Advisor sobre as acções do servidor.

 
sergeev:

Infelizmente, ainda não percebi.

precisa de ter um campo "tempo" na estrutura de retorno por alguma razão. use o tempo na ordem que aparece. Isto é suficiente para controlar uma pequena história.

"Ao enviar um pedido de compra utilizando a função OrderSend(), pode conhecer imediatamente o bilhete da encomenda que foi criada quando o pedido foi verificado com sucesso. Mas ao mesmo tempo, a ordem em si pode ainda não aparecer no terminal do cliente e uma tentativa de a seleccionar utilizando a função OrderSelect falhará. Da segunda frase resulta que nem sempre é possível trabalhar com as propriedades da encomenda (tempo de encomenda), mesmo que o seu bilhete seja conhecido. Portanto, "utilizar o tempo na ordem que apareceu" não é uma solução ideal. Além disso, a encomenda pode "não abrir" de todo. A minha abordagem resolveria o "pequeno problema do controlo da história" independentemente do que acontecesse à ordem antes de passar à história.
 
Interesting:

A estrutura deveria chamar-se MqlTradeResult , e não MqlResult (embora na minha opinião não tenha grande importância).

Escrevi 'de memória', em resposta a conselhos para estudar um livro didáctico
Interessante:

Não é exactamente um entendimento correcto do que acontece quando se recebe uma resposta do servidor.

OrderSend() devolve realmente um valor booleano, mas não é o mais importante. O principal é a estrutura que é preenchida ao receber uma resposta do servidor.

Sim, de facto, um bilhete é escrito na estrutura (não só encomendas, mas também negócios), mas será mais importante do que o resto da informação na estrutura?

Bem, não vamos discutir quem tem uma melhor compreensão :) Ver a minha resposta a Sergeev. E aqui repito: de acordo com a lógica da estratégia, preciso apenas do bilhete e do tempo de aceitação da encomenda para a produção. O que salientou não é nenhum dos dois. "Informação muito importante", como o retcode, não ajuda em nada a optimizar o carregamento da história, que é basicamente aquilo de que estou a falar.
 
Yedelkin:
"Ao enviar um pedido de compra utilizando a função OrderSend(), podemos conhecer imediatamente o bilhete da encomenda que foi criada quando o pedido foi verificado com sucesso. Mas ao mesmo tempo, a ordem em si pode ainda não aparecer no terminal do cliente e uma tentativa de a seleccionar utilizando a função OrderSelect falhará. Da segunda frase resulta que nem sempre é possível trabalhar com as propriedades da encomenda (tempo de encomenda), mesmo que o seu bilhete seja conhecido. Portanto, "utilizar o tempo na ordem que apareceu" não é uma solução ideal. Além disso, a ordem pode "não abrir" de todo. A minha abordagem resolveria o problema de controlar uma pequena história, independentemente do que aconteceu à ordem antes de esta entrar para a história.

Não sei, se é tão importante pedir aos criadores que façam adições à estrutura MqlTradeResult (na forma de tempo para o qual uma transacção é executada ou uma ordem é definida).

Embora não compreenda porque é necessário, prefiro acrescentar parâmetros à OnTrade().


 
Interesting:

Não sei, se é tão importante, pedir aos programadores que façam adições na estrutura MqlTradeResult(como tempo de negócio executado ou de encomenda efectuada).

Bem, era sobre isso que eu estava a perguntar desde o início :) Existiu um precedente, por assim dizer :)

Adição. Se alguém fizesse esta pergunta há meio ano atrás, poderíamos esperar por um aparecimento relativamente rápido desta funcionalidade, enquanto esperamos pelo próximo ano - é mais fácil introduzir uma variável para a data. Embora não seja completamente exacta, mas ainda assim.

Interessante:

Embora não compreenda porque é necessário, prefiro acrescentar parâmetros à OnTrade().

Pessoalmente, não posso esperar mais pelo aparecimento da estrutura/parâmetros de Comércio. Já há 9 meses que estou à espera disso. Vou ter de me contentar com o que tenho.

 
Yedelkin:
Escrevi "de memória", em resposta a conselhos para estudar um livro-texto Bem, não vamos discutir, quem tem uma melhor compreensão :) Vejam a minha resposta a Sergeev. E aqui repito: de acordo com a lógica da estratégia, só preciso de um bilhete e do tempo de levar a encomenda à produção. O que salientou não é nenhum dos dois. "Informação muito importante" como o retcode não ajuda em nada a optimizar o carregamento da história, que é do que estou a falar em geral.

1) EncomendarEnviar() e carregar a história, e a partir deste ponto, por favor, elaborar (não consigo compreender do que estamos a falar, e penso que estamos sem relva).

2. Logicamente, se a análise for baseada apenas no resultado OrderSend(), a sequência de acções é a seguinte

a) Verificar o código retc, precisamos de saber o que realmente aconteceu;

b) Se o resultado for bem sucedido, obter o bilhete, o volume e o preço. Se formos solicitados, obtemos os novos preços (e verificamos se nos satisfazem).

c) Se a resposta for satisfatória e não tivermos erros, obter um bilhete e tempo. Pode utilizar a hora do servidor ou tentar retirá-la do histórico (para o cálculo aproximado no momento, é melhor conhecer a hora do servidor);

d) Se não estivermos satisfeitos com a resposta (ou satisfeitos apenas parcialmente) - não corresponder ao volume ou se tivermos um requote, decidir sobre os próximos passos.

PS

Em suma, não importa como se olha para ele, o código retcode deve ser visto.

 
Interesting:

Não sei do que estás a falar, e penso que estamos sem erva).

Veja a discussão desde o início. ...Ninguém nega a importância do retcode, mas para soluções simples pode passar sem ele.
 
Yedelkin:
Veja a discussão desde o início. ...Ninguém nega a importância do retcode, mas para soluções simples pode passar sem ele.

Até que ponto esta opção é crítica para si?

c) Se a resposta for satisfatória e não houver erros, recebemos um bilhete. Pode usar a hora actual;

 
sergeev:

Até que ponto esta opção é crítica para si?


Esta é a variante padrão (que tem as suas desvantagens mencionadas acima) + economia de tempo independente. Uma vez que não preciso de verificação de código retcode, há apenas uma questão sobre poupança de tempo: seja de forma independente ou esteticamente com MqlTradeResult. Na verdade, esta é a razão da pergunta :)
 
Yedelkin:
Esta é a opção padrão (que tem as suas desvantagens, mencionadas acima) + economia de tempo. Uma vez que não preciso de verificação de código retcode, há apenas uma questão de economia de tempo: seja de forma independente, ou esteticamente com MqlTradeResult. Na verdade, esta é a razão da minha pergunta :)

Se o pedido for bem sucedido, mais cedo ou mais tarde, o comércio ficará na história e a ordem aparecerá na lista. Consequentemente, poderá descobrir exactamente o que aconteceu e como aconteceu.

E a variante sugerida é, por assim dizer, "a curto prazo", para aqueles que querem obter todos os dados necessários de uma só vez e não se preocupar com acções desnecessárias.

Claro que talvez se acrescente algo mais no servidor de resposta, mas há uma série de características e razões pelas quais os criadores podem não concordar com esta opção (e o pedido, lamentavelmente pouco justificado e confirmado por argumentos convincentes).

PS

Embora, talvez me tenha escapado alguma coisa e os criadores tenham decidido que é bastante razoável.

1...111213141516171819202122232425...46
Novo comentário