![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
A questão é que, ao implementar algo assim, você inevitavelmente se deparará com uma falta catastrófica de comprimento do controle deslizante.
Sim, já me deparei com isso;)
fiz um longo
Toda essa dança do pandeiro foi apenas com o propósito de
ver como, de fato, e o mais importante, de que e por que o preço se move.
Agora está tudo claro ;))))
é claro que o terminal tem um belo desenho, mas não é verdade!
gráfico correto no trailersim, já me deparei com ele ;)
fez um longo
Toda essa dança do pandeiro foi apenas com o propósito de
ver como realmente funciona e, mais importante, o que faz o preço subir e por quê.
Bem, agora está tudo claro ;))))
Na minha opinião, é muito mais conveniente e visual ter um controle deslizante bidimensional, cuja coordenada de altura é responsável pela escala.
![](https://c.mql5.com/3/422/DinCh2__1.gif)
Algo assim:
Nesse caso, é necessário apenas um clique do mouse com movimento para chegar a qualquer momento do histórico inteiro com qualquer escala.
Para mim, um controle deslizante bidimensional com uma coordenada de altura responsável pela escala é muito mais conveniente e visual.
Algo assim:
você tem um muito legal ;)
você tem um muito legal ;)
Obrigado,
. Quero fazer um completo sobre o WebAssembly (em Rust).
Obrigado,
. Quero criar um desses no WebAssembley (em Rust)
Sim.
O principal é que você não precisa trocar nada.
O prazo mínimo é escalonado.
E estou intrigado - como é possível que os sinais sejam diferentes em diferentes períodos de tempo com o mesmo preço?
Quem vai para a floresta, quem vai para a floresta....
Os períodos de tempo não são nem mesmo necessários em sua essência.
Os ticks são necessários e isso é tudo
Sim
Você não precisa trocar nada.
o prazo mínimo é dimensionado.
E estou intrigado - como os sinais são diferentes em diferentes períodos de tempo com o mesmo preço?
quem vai para a floresta, quem vai para a floresta....
Os períodos de tempo não são nem mesmo necessários em sua essência.
Você precisa de ticks, só isso.
Sim, o modelo atual de período de tempo é muito inconveniente. Cada barra do TF sênior contém um número diferente de barras de minutos. Com essa estrutura, se o TF sênior for suavemente reduzido para o júnior, os gráficos não coincidirão.
Não estou muito certo
não em escala, mas comprimido.
Os TFs desaparecem.Eu não estava muito certo
não em escala, mas compactado.
TFmas desaparecemAjude-me a entender o conceito de um recurso gráfico e como ele difere do conceito de um objeto gráfico em um gráfico.
Por exemplo, se eu excluir um objeto gráfico criado com o Canvas usando a função ObjectDelete() e, em seguida, em um loop, criarei objetos do Canvas com nomes diferentes várias vezes, mas usando a mesma instância da classe Canvas... e novamente excluir objetos gráficos usando ObjectDelete(). Há algum perigo nisso?
Ainda não entendo muito bem a diferença entre ObjectDelete() e C.Destroy(), mas gostaria de entender....
Ainda não entendo muito bem a diferença entre ObjectDelete() e C.Destroy(), mas gostaria de entender....
Canvas é um objeto ao qual está vinculada uma matriz de pixels. O Resource é responsável por vincular essa matriz de pixels (consulte a função bool CCanvas::Create())
É uma má prática excluir e recriar uma tela o tempo todo.
É uma boa prática criar uma tela quando você precisar dela e excluí-la quando não precisar mais dela, por exemplo, no final do programa.
Depois de criar um objeto de tela, você pode limpá-lo, substituir a matriz de pixels a cada quadro, redimensionar a tela e movê-la para onde quiser.