Desejos para MQL5 - página 29

 
Cronex:

Na posição de ver a situação do mercado como histriônica, suplico-lhe que discorde... Mas esta é a minha própria opinião. No caso de uma ordem lucrativa, faz sentido olhar para o prazo mais alto para decidir se deve esperar por um pequeno recuo e continuar trabalhando com a ordem em um prazo mais alto ou simplesmente fechá-la por falta de sucesso.

Não estou dizendo que o histórico do mercado não deve ser levado em conta. Na verdade, é a única coisa que pode e deve ser levada em conta.

Estou dizendo que não faz sentido (prejudicial) levar em conta a data e o preço de abertura de um pedido. Nesse sentido, majik é um meio para manter as ilusões :) Não quero me repetir, dê uma olhada aqui.

E no arame, acho que a majik não vai servir. Imaginem quantos programadores infelizes existem. Em alguns programas, uma solicitação de um majik certamente entrará em um loop e sobrecarregará o servidor. E se mesmo um programa desse tipo entrar em circulação, será o fim de toda a tecnologia.

 
SK. писал (а):

E no arame, eu não acho que haverá nenhum majestoso. Imagine quantos programadores miseráveis existem. Em alguns programas, uma solicitação de um majik certamente entrará em um loop e carregará o servidor. Se até mesmo um programa desse tipo entrar em circulação, toda a tecnologia será arruinada.

Acho que estava errado: eu não estava sugerindo solicitá-lo separadamente do servidor. Eu sugeri que só o substituíssemos quando a OrderModify fosse chamada.



 
SK. писал (а): Imagine quantos programadores mal orientados existem. Em alguns programas, um pedido para MUDAR um majik é obrigado a entrar em um loop e carregar o servidor.

Vejo o que você quer dizer12 , o perigo existe. Assim como com o rearranjo SL e TP.

 
Cronex:
SK. escreveu (a): Imaginem quantos programadores deploráveis existem. Em alguns programas, um pedido para MUDAR um majik é obrigado a entrar em um loop e carregar o servidor.

Vejo o que você quer dizer12 , o perigo existe. Assim como com o SL e TP móvel


Este já é um detalhe do que eles não farão sem você e eu:) Mas se fosse, a solicitação ou resposta também seria assumida - como você a vê. Por exemplo, uma mudança no SL do servidor de um PC conectado à conta responderia exibindo o novo valor do SL em todos os PCs conectados à conta.

Você e eu somos como Dobczynski e Bobczynski:

Bobchinsky. ... "Eh!" digo a Peter Ivanovich...
Dobczynski. Não, Pyotr Ivanovich, eu disse: "э!"
Bobchinsky. Primeiro você o disse, e depois eu o disse. "Э! - Peter Ivanovich e eu dissemos. - "E por que ele deveria sentar-se aqui, quando o caminho para ele
para a província de Saratov"...

 
SK. писал (а):


Sim... Tudo o que o usuário pode fazer para colocar o sistema de joelhos, ele fará. Mesmo sem ganharem juízo :-)

Infelizmente, como conseqüência, muitos produtos estão sobrecarregados com checagens e verificações, proteção de interface contra "tolices" e ações acidentais imprevisíveis do usuário.

Recentemente tive que me comunicar com um cliente que interpretou o status de "Aprovado" de um documento oficial de forma algo peculiar. O documento é uma espécie de documento aprovado e assinado, mas tudo nele pode ser alterado sem necessidade de nova consideração e reaprovação. Imagine como exemplo: você envia uma ordem de pagamento ao banco, o banco a executa fielmente, e você então, tendo corrigido o documento original, vem ao banco e faz um acerto com a expressão "execução incorreta da ordem de pagamento".

 
Cronex:

Infelizmente, como conseqüência disso, muitos produtos estão sobrecarregados com funcionalidades de verificação e reconfiguração, proteção da interface contra "tolos" e ações acidentais imprevisíveis do usuário.

Sim, eu estou bem ciente disso. Por esta razão, tive que gastar muito tempo para tornar o programa infalível, então o trabalho já se estendeu por meio ano. E tudo porque o usuário pode mudar a cor ou a aparência do ícone de controle e depois reclamar.

A propósito, sobre o tópico deste tópico. Há uma necessidade de propriedades do objeto programáveis : proibir/permitir mudanças de cor, tamanho, fonte, destaque, exclusão, etc.

 
Deixe-me lembrar que é possível executar o terminal sem uma interface gráfica.
Por exemplo, o mesmo campeonato, claramente um especialista que funciona bem não precisa de uma interface gráfica.
 

Uma grande solicitação para possibilitar a execução de um EA (indicador, roteiro), não apenas na chegada de um novo tick, mas de diferentes maneiras

Eu preciso de

  1. Por carrapato
  2. Por tempo
  3. Por evento externo, importante para conexão com cálculos de outras matrizes.

Talvez como esta 3 funções começam

Início 0 {} // funciona por carrapato

Iniciar 1 {} // funciona por hora (selecionar a cada segundo, minuto, hora, etc.)

Iniciar 2 {} // corre em um evento externo, digamos quando um programa externo completou os cálculos e os dados foram atualizados no arquivo de resultados dos cálculos desse programa.

Obrigado de antemão.

 

Também pode ser útil ser capaz de organizar indicadores de usuários por grupos em pastas no sistema de arquivos. Não é uma boa idéia ter um monte de indicadores em uma pasta :-)

 

Também seria bom poder estabelecer uma escala de preço fixo (pips/pixel) com os limites da escala mudando automaticamente por múltiplos de um determinado valor, por exemplo, 5 ou 10 pips.

Razão: