A lona é legal! - página 55
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
Se você se lembra da Borland, a GUI foi montada em um editor visual, o layout dos controles foi adicionado ao painel, e então você escreve os manipuladores.
Se ME tivesse esse recurso gráfico para construir layouts em modo visual, isso tornaria muito mais fácil a construção de aplicações gráficas.
Como a maioria dos programadores modernos, que estudaram a construção de GUI, se acostumaram (assim foram ensinados) com o editor visual de GUI,
E construir um layout de uma aplicação gráfica em código puro estilo C é de pouco interesse para eles. Uma vez que já é ao estilo hardcore C.
Precisamos de um editor visual para construir uma aplicação gráfica, e então as pessoas estarão ansiosas para aprender, e aqueles que trabalharam em VS ou RadStudio, eles até mesmo rapidamente dominam o editor visual.
Aqui, já havia um protótipo de um editor visual desse tipo na MQL. No entanto, as pessoas foram veementemente contra. Eles disseram que não era necessário no comércio.
Em geral, eles estavam desmoralizando o melhor que podiam. Portanto, não sei o que a comunidade realmente precisa.
Eu apoio plenamente a necessidade de ter a capacidade de coletar...
Mas se é necessário ou não, é outra questão.
Será que os próprios desenvolvedores vêem o terminal como uma ferramenta comercial ou de programação?
Posso estar errado neste ponto, mas sempre pensei que o ME foi projetado para implementar exatamente a funcionalidade que o usuário precisa para o comércio. Exatamente comercial!
Mas hoje em dia a profundidade da programação em ME foi para áreas onde você realmente precisa ser capaz de "construir" dados e ter uma compreensão muito séria de programação....
E ao que isso leva no final? Isso leva ao fato de que ferramentas comerciais avançadas tornam-se disponíveis apenas para programadores experientes!
Ou seja, se você não é um programador, não tem nada a ver com comércio... Mas isto é um absurdo.
ME é apenas um assistente para preencher a funcionalidade em falta, que teria sido mais corretamente embutida no próprio terminal (feiticeiros diferentes).
E de fato ME está agora evoluindo como um novo ambiente de desenvolvimento, exigindo cada vez mais conhecimento dos usuários.
Com base nesta conclusão, as ferramentas de visualização são necessárias, mas seu uso deve estar disponível para os usuários que não possuem conhecimentos profundos de programação.
Somente neste caso, eles serão procurados.
Esta é apenas a minha opinião e não estou impondo-a a ninguém.
Se você considerar a classe CCanvas, há cerca de 20 funções de desenho de primitivas gráficas. Suponha que um usuário conheça todas elas e conheça as regras e a sintaxe do OOP. Entretanto, é muito pouco até a mais simples visualização de seus dados. Sem mencionar a criação do controle mais simples - um botão. Ou seja, é relativamente fácil desenhar primitivos na tela, mas usar esses primitivos na criação de visualização ou GUI é muito mais difícil. E você não pode fazer aqui sem conhecimento - você não pode fazer aqui sem o talento do desenvolvedor. Mas quantas pessoas o têm? Esse é o principal problema.
Para usar o potencial da classe Kanvas é preciso ser capaz de combinar primitivas gráficas em objetos mais complexos (controles), para vincular sua operação com o modelo orientado por eventos, para escrever as relações com funções... Ou, converter dados digitais em diferentes curvas gráficas... Este é um trabalho para usuários talentosos e com muito trabalho. Na verdade, não os usuários, mas os desenvolvedores.
Aqui, já havia um protótipo de um editor visual desse tipo na MQL. No entanto, as pessoas foram veementemente contra. Eles disseram que não era necessário no comércio.
Em geral, eles estavam desmoralizando o melhor que podiam. Portanto, não sei o que a comunidade realmente precisa.
Uau, então existe um protótipo.
Então talvez os desenvolvedores devam reconsiderar os pontos de vista superficiais da comunidade? E reavivar o plano para desenvolver um modo visual.
Um pouco estranho, é claro, desmoralizar uma característica essencialmente muito procurada.
Há muito poucos lugares agora onde ensinam como construir uma interface gráfica no estilo C, se é que já ensinam alguma coisa.
Agora todos são ensinados a trabalhar em IDE com modo visual, e como o MT5 foi além de apenas a plataforma comercial
, o modo visual de construção de aplicações gráficas estaria em grande demanda.
Honestamente, estou chocado que os desenvolvedores tenham ouvido as pessoas de vistas curtas que estavam contra.
Se considerarmos a classe CCanvas, existem cerca de 20 funções para desenhar primitivas gráficas. Suponha que o usuário conheça todas elas e conheça as regras e sintaxe do OOP. Entretanto, até a mais simples visualização de seus dados - é muito pouco. Sem mencionar a criação do controle mais simples - um botão. Ou seja, é relativamente fácil desenhar primitivos na tela, mas usar esses primitivos na criação de visualização ou GUI é muito mais difícil. E você não pode fazer aqui sem conhecimento - você não pode fazer aqui sem o talento do desenvolvedor. Mas quantas pessoas o têm? Esse é o principal problema.
Para usar o potencial da classe Kanvas é preciso ser capaz de combinar primitivas gráficas em objetos mais complexos (controles), para vincular sua operação com o modelo orientado por eventos, para escrever as relações com funções... Ou, converter dados digitais em diferentes curvas gráficas... Este é um trabalho para usuários talentosos e com muito trabalho. Na verdade, não os usuários, mas os desenvolvedores.
Peter, você diz as palavras certas!
Por isso, defendo a criação de tais bibliotecas que seriam intuitivamente compreensíveis para programadores que não estão familiarizados com o OOP também.
E isto se aplica não apenas à GUI.
Na biblioteca padrão e na biblioteca do Anatoly, seria preciso muito esforço para construir uma forma simples! De verdade! Um passo para a direita ou para a esquerda dos exemplos e pronto, nada funciona, você tem que entender todos os detalhes.
Em todos os idiomas, claro, a GUI também é construída sobre bibliotecas, mas há uma importante MAS! Existe um conjunto inicial de controles, que no nível central da biblioteca estão completamente "amarrados", todos os manipuladores de eventos básicos estão "conectados", tudo o que resta é assiná-los se você quiser mudar o comportamento ou a apresentação.
Em essência, a arquitetura da biblioteca padrão é muito bem pensada e poderia ser usada como base para uma biblioteca mais avançada.
Wah, então há um protótipo disponível.
Então talvez os desenvolvedores devam reconsiderar os pontos de vista superficiais da comunidade? E reavivar o plano para desenvolver um modo visual.
É estranho, é claro, que eles desmoralizaram uma característica essencialmente muito procurada.
Afinal, poucos lugares agora ensinam como construir uma interface gráfica no estilo C, se é que ainda é ensinada.
Agora eles ensinam a trabalhar em IDE com o modo visual, e como o MT5 não é mais apenas uma plataforma de negociação,
então o modo visual de construção de aplicações gráficas seria muito requisitado.
Para ser honesto, estou chocado que os desenvolvedores tenham ouvido as pessoas de vistas curtas que estavam contra.
Há alguns outros fatores surpreendentes: os indicadores são 100% visuais, os EAs são 80% visuais e os scripts são 20% visuais. O que quer que você queira chamar, tudo é visual e a compreensão disto está na superfície. Entretanto, há um desenvolvimento sobre a integração com outros ambientes de desenvolvimento, e o que está na superfície....
Aparentemente, todos os outros usuários de terminais estão pedindo píton e sql.
Roman, Peter, Nikolai... os desenvolvedores de terminais têm sua própria visão, eles são os autores e proprietários do produto de software. Acho que o desenvolvimento da funcionalidade ME e do terminal como um todo é baseado em pesquisa de mercado.
Mas ninguém está nos impedindo de falar :)
Há alguns outros fatores surpreendentes: os indicadores são 100% visuais, os EAs são 80% visuais e os scripts são 20% visuais. O que quer que você queira chamar, tudo é visual e a compreensão disto está na superfície. Entretanto, há um desenvolvimento sobre a integração com outros ambientes de desenvolvimento, e o que está na superfície....
Aparentemente, todos os outros usuários de terminais perguntam sobre python e sql.
Roman, Peter, Nikolay... Os desenvolvedores do terminal têm sua própria visão, eles são os autores e proprietários do produto de software. Penso que o desenvolvimento da funcionalidade ME e do terminal em geral é baseado em pesquisa de mercado.
Mas ninguém está nos impedindo de falar :)
É isso mesmo.
Minha opinião é: a interface visual dos EAs permitirá acumular estratégias em uma aplicação, o que afetará negativamente as vendas no mercado. Se todos podem facilmente criar Expert Advisors com um conjunto dinâmico de estratégias (GUI permite isso), sua rotação atual no Mercado irá diminuir, o que afetará as vendas. Conselheiros especializados que integram e modificam as estratégias internamente, chegarão à vanguarda e eliminarão clones que diferem apenas em configurações ou em algumas condições. Isto será bom para o mercado? Eu não sei. Mas o nível de Consultores Especialistas subirá e será muito mais interessante examiná-los na vitrine.
Talvez a maioria dos usuários queira que o CCanvas, CGrafic e CCanvas3D sejam aplicações que produzem as visualizações necessárias, ao invés de aulas que exigem conhecimento dos princípios e sintaxe do OOP. E não apenas para saber, mas essencialmente para construir seu próprio sistema de visualização, como faz Nicholas.
Qual é o princípio de oop que você precisa saber? Colocar um ponto e escolher um método da lista?
Uma pergunta complementar: quantas e quais das funções MQL "mais potentes" e "mais simples
é suficiente para escrever um Expert Advisor totalmente funcional e potencialmente o mais rentável para qualquer
dos principais pares de moedas do mundo?
E que função R ou Python, sobre a qual todos aqui perderam a cabeça, é suficiente para escrever...? E veja, o banco onde você está sentado - é adequado para isso...?
Bem, se você se lembra da Borland, a GUI foi montada em um editor visual, você coloca o layout de controle no painel, e depois escreve os manipuladores.
Se ME tivesse essa capacidade gráfica de construir layouts visualmente, isso simplificaria muito a construção de aplicações gráficas.
Como a maioria dos programadores modernos, que estudaram a construção de GUI, se acostumaram (assim foram ensinados) com o editor visual de GUI,
E construir um layout de uma aplicação gráfica em código puro estilo C é de pouco interesse para eles. Uma vez que já é ao estilo hardcore C.
Precisamos de um editor visual para construir uma aplicação gráfica, e então as pessoas estarão ansiosas para aprender, e aqueles que trabalharam em VS ou RadStudio, eles até mesmo rapidamente dominam o editor visual.
Por que eles são necessários aqui?
É isso mesmo.
Minha opinião é: a interface visual dos EAs permitirá acumular estratégias em uma aplicação, o que afetará negativamente as vendas no mercado. Se todos podem facilmente criar Expert Advisors com um conjunto dinâmico de estratégias (GUI permite isso), sua rotação atual no Mercado irá diminuir, o que afetará as vendas. Conselheiros especializados que integram e modificam as estratégias internamente, chegarão à vanguarda e eliminarão clones que diferem apenas em configurações ou em algumas condições. Isto será bom para o Mercado? Eu não sei. Mas, o nível de EAs vai crescer e será muito mais interessante vê-los na vitrine.
Absolutamente um problema rebuscado.
A interface visual para a coleta de estratégias é desnecessária, se você precisar de dados, vá para o tslab.
E tenho visto programas de geração de código mql que coletam estratégias com cubos em modo visual.
Não precisamos do modo visual para o desenvolvimento de estratégias e indicadores comerciais, ele é realmente desnecessário.
Mas para aplicações gráficas modulares, o modo visual, como você mostrou no gif, seria útil.