Minha abordagem. O núcleo é o motor. - página 26
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
Os construtores de GUI são feitos para uma biblioteca gráfica específica. Se houvesse um construtor de GUI para MQL, ele estaria aqui.
Eu vi um artigo em algum lugar, em algum lugar em hubre, parece, como "criar um construtor de GUI para Python", então eu pensei que talvez alguém tenha visto uma GUI multiplataforma onde eu poderia adicionar meu próprio código
Mas se eu quiser escrever um construtor do zero, eu preferiria usar MQL.
1. eu nunca o desenvolvi em Sharp, eu não tinha interesse, mas há cerca de 5 anos eu usei o Delphi para conectar .dll com botões e formulários e ele funcionou sem problemas, mesmo todo o projeto Delphi estava pronto durante um dia, eu até passei meio dia tentando encontrar a razão pela qual os formulários padrão não estavam funcionando, mas quando eu o conectei ligando para as janelas do sistema tudo estava funcionando corretamente, mas o MT4 estava muito lento na época, ele ficava muito lento agora ele voa
não tenho problemas para conectar .dll, sincronizar com mutex padrão - iniciar uma thread para conectar ao terminal e isso é tudo, então tudo vai por si só - separadamente um formulário em .dll, separadamente MT ninguém está esperando por ninguém
SZS: por favor, note que Delphi é bastante impraticável para criar um .dll, mas o que estava à mão (o que eu estava sentado na época) que eu usava)))
Mas quanto à essência, não entendo porque eles não podem usar as classes padrão do kit de ferramentas MT, seria legal unificar o processo de criação gráfica, talvez seja uma inclusão universal onde você poderia comentar botões/diálogos desnecessários, etc.
1. esta é uma forma muito, muito amadora de encarar o problema (sem ofensa). Um projeto que é feito em um dia não é um projeto. É uma tarefa pequena.
Imagine que você cria uma aplicação composta de 10 janelas, entre as quais há grandes tabelas de dados, janelas de ajustes e caixas de diálogo. Você os desenha em Delphi. Em seguida, você cria uma DLL. Em seguida, você o conecta ao seu projeto MT.
Sua aplicação MT precisa ser conectada à interface gráfica Delphi através de memória compartilhada. Conectar funções aos controles e dados às células da tabela. Você precisa organizar a complexa interação das duas partes da aplicação e pensar bem sobre ela.
Você precisa da operação síncrona e da troca de valores de parâmetros entre as duas partes - Aplicação GUI e MT.
Mais uma vez: se sua aplicação é grande e séria (tabelas, janelas de ajustes, caixas de diálogo, listas antigas, etc...) criar um trabalho único, coerente e eficiente de duas partes via DLL é uma tarefa MUITO séria. Já o fiz e sei do que estou falando.
E você está falando de uma pequena tarefa que pode ser feita em um dia. Não é grave.
Você pode usar a biblioteca padrão há muito tempo. Mas a questão é sobre o esforço necessário e o resultado que você obterá. O que são eles? Eu sei que Anatoly usou a biblioteca padrão como trampolim para criar sua própria biblioteca. Mas por que ele fez isso, se a biblioteca padrão também funciona? A resposta é simples - ele implementou tudo de melhor qualidade e foi além da Biblioteca Padrão. Mas, a distribuição em massa só pode ser alcançada reduzindo a dificuldade de uso. Quanto mais fácil de usar, - mais usuários serão (com um aumento na qualidade, é claro).
1. esta é uma maneira muito, muito amadora de olhar para o problema (sem ofensa). Um projeto que é feito em um dia não é um projeto. É uma tarefa pequena.
Imagine que você cria uma aplicação composta de 10 janelas, entre as quais há grandes tabelas de dados, janelas de ajustes e caixas de diálogo. Você os desenha em Delphi. Em seguida, você cria uma DLL. Em seguida, você o conecta ao seu projeto MT.
Sua aplicação MT precisa ser conectada à interface gráfica Delphi através de memória compartilhada. Conectar funções aos controles e dados às células da tabela. Você precisa organizar a complexa interação das duas partes da aplicação e pensar bem sobre ela.
Você precisa da operação síncrona e da troca de valores de parâmetros entre as duas partes - Aplicação GUI e MT.
Mais uma vez: se sua aplicação é grande e séria (tabelas, janelas de ajustes, caixas de diálogo, listas antigas, etc...) criar um trabalho único, coerente e eficiente de duas partes via DLL é uma tarefa MUITO séria. Já o fiz e sei do que estou falando.
E você está falando de uma pequena tarefa que pode ser feita em um dia. Isto não é grave.
Quais são suas reivindicações? Você simplesmente não entende que a troca de dados entre a MT e .dll é tão antiga quanto o mundo
Eu estava fazendo um .dll porque antes não havia gráficos decentes em MT, eu queria botões e um painel
tabelas? - desenhar bem as mesas, controles? - draw.... Você simplesmente não pode separar a tarefa, no mesmo Delphi há muitos componentes prontos, tanto para criar bancos de dados como para trabalhar com eles
Isto é, da MT você só precisa dos dados em si, e o resto fará um programa de terceiros, você pode acreditar em sua palavra, mas no mesmo Delphi para escrever trabalho com o banco de dados, com a saída em tabelas, gráficos, etc. trabalhar por um dia ;)
O que são dados na MT? = é apenas um carrapato e uma barra, e não adianta "correr" através de um .dll - basta despejar tudo em um arquivo uma vez e trabalhar com o arquivo em um programa de terceiros
SZS: alguém escreveu recentemente no fórum que as empresas modernas de TI valorizam os funcionários que não entendem bem o código em que trabalham, mas aqueles que o mais rápido possível podem realizar um grande volume de tarefas, ou seja, precisam ser capazes de integrar o trabalho de outras pessoas em suas tarefas, e não de construir cada vez do zero! Não conheço sua ocupação principal, nunca trabalhei como programador, mas estou constantemente trabalhando em áreas relacionadas, há muito tempo me dedicando à manutenção de controladores industriais, ACS e ACS, e tive que adicionar soluções de programas e interagir com os desenvolvedores, então tive que entrar em todas as soluções de software prontas - aqui você não pode escrever tudo do zero )))), e os fabricantes de "ferro" industrial usam sistemas de programação especializados, onde C, onde SCADA, e assembler, e cada vez deve ser capaz de ler o código de outra pessoa ;))
Você se propõe a criar, com base em seu "motor", um projeto condicionalmente funcional, que não pode ser modificado pelos programadores?
Quais são os ressentimentos? Você simplesmente não entende que a troca de dados entre a MT e .dll é tão antiga quanto o mundo
Eu fiz o .dll porque antes não havia gráficos decentes em MT, eu queria botões e painel
tabelas? - desenhar bem as mesas, controles? - draw.... Você simplesmente não pode separar a tarefa, no mesmo Delphi há muitos componentes prontos, tanto para criar bancos de dados como para trabalhar com eles
Isto é, da MT você só precisa dos dados, e o resto fará um programa de terceiros, você pode acreditar em sua palavra, mas no mesmo Delphi para escrever trabalho com o banco de dados, com a saída em tabelas, gráficos, etc. trabalhar por um dia ;)
ZS: o que são dados na MT? = é apenas um carrapato e uma barra, e não há sentido em "correr" a história através de um .dll - basta despejar tudo em um arquivo uma vez e trabalhar com o arquivo em um programa de terceiros
Se você pegar somente os dados que chegam a ele da MT, e os passar através de uma DLL para um aplicativo escrito em Delphi ou C++ ou C#, então isso é definitivamente possível. Então a aplicação comercial será completamente escrita em uma linguagem de programação diferente.
Ou seja, séries temporais, testadores, otimização, sintéticos e muitas outras coisas devem ser criadas em outra língua.
Por que você precisa de MQL? Basta fornecer os dados diretamente a uma aplicação de terceiros e usar a plataforma como remetente de eventos e pedidos. E isso é tudo. Mas as vantagens da MQL como linguagem de sistema comercial serão perdidas.
Por que você precisa da MQL?
Porque a MQL é uma linguagem de aplicação desenvolvida para escrever aplicações comerciais. Esta é sua principal vantagem. É leve e simples. Tem um monte de soluções prontas para programadores. Eles os pegam e usam.
Os programadores têm uma escolha:
Obviamente, a opção mais preferível é usar MQL e MT, porque eles dão vantagens - Teste, Otimização, Pesquisa (sintéticos), Indicadores, funções úteis, séries temporais... + Suporte técnico da linguagem no fórum.
Mas este ideal tem uma falha grave: a capacidade limitada de criar aplicações complexas, devido à dificuldade de criar uma GUI de qualidade.
Este último problema eu resolvi em sua maioria.
Portanto, quando se trata de praticar e você começa a escrever um pedido sério, você certamente escolherá a MT. Assim farão muitos, muitos outros.
...
Você está sugerindo criar, com base em seu "motor", um projeto condicionalmente funcional, que não pode ser modificado pelos programadores?
O motor é o "portador" daquela GUI que é criada em meu construtor. Não precisa ser modificado. Apenas conecte-o à aplicação e a GUI criada funcionará.
Mais uma vez: se o aplicativo é grande e sério (tabelas, janelas de ajustes, diálogos, listas antigas, etc...) criar uma operação única, coerente e eficiente das duas partes através da DLL é uma tarefa MUITO séria. Já o fiz, e sei do que estou falando.
Quem puder criar uma aplicação grande e complexa, definitivamente usará a biblioteca gui. O que o desenvolvedor deve fazer, se ele desenvolver sua aplicação e decidir adicionar animação, por exemplo? Ele deve procurá-lo e perguntar, ou ele deve quebrar tudo e construir do zero?
Onde você teve a idéia de que existe um problema com a criação de GUI. Olhe para o mercado, há muitas aplicações com GUI.
1. Quem puder criar uma aplicação grande e complexa, certamente usará a biblioteca gui.
2. O que o desenvolvedor deve fazer se, ao desenvolver sua aplicação, ele decidir, por exemplo, adicionar animação? Procurar por você e perguntar, ou quebrar tudo e construir do zero?
3) E onde você teve a idéia de que existe um problema com a criação da GUI. Olhe para o mercado, há muitas aplicações com GUIs.
1. A biblioteca GUI é uma biblioteca projetada para programadores sérios. Não pode ser produzido em massa devido à dificuldade de uso. Qual é o objetivo disso? Apenas alguns de nós vamos por sobre a biblioteca e criar aplicações complexas enquanto outros não serão capazes de...
2. Deixe o desenvolvedor criar animação em sua aplicação. O que isso tem a ver comigo? Ele pode chamar esta animação independentemente da GUI e do motor, ou ligar a chamada de sua animação a algum botão.
3) Há apenas algumas pessoas cuja GUI é digna de atenção. Você, Anatoly e talvez outra pessoa... O resto não atinge o nível mais grave.
3. Há apenas algumas pessoas cuja GUI é digna de nota.
Eu não seria tão categórico. E eu não estava falando do desenvolvimento de bibliotecas gui, eu estava falando de aplicações gui. Há muitos deles no mercado, alguns usando seus próprios desenvolvimentos, alguns usando a biblioteca padrão e outros usando a biblioteca da Anatoly.
1. Esse é o ponto. A biblioteca GUI é projetada para programadores sérios. Ela não pode ser espalhada em massa devido à dificuldade de uso. Qual é o objetivo disso? Alguns que porão por cima da biblioteca e criarão aplicações complexas e outros que não poderão?
2. Deixe o desenvolvedor criar animação em sua aplicação. O que isso tem a ver comigo? Ele pode chamar esta animação independentemente da GUI e do Motor, ou ligar a chamada de sua animação a algum botão.
3) Há apenas algumas pessoas cuja GUI é digna de atenção. Você, Anatoly e talvez outra pessoa... Os demais não atingem sequer o nível mais grave.
Peter, eu acho que o principal problema que você tem é o posicionamento do projeto.
Pode ser de interesse apenas para aqueles participantes que têm uma experiência bastante boa em programação, mas, ao mesmo tempo, preferem trocar de mãos.
Você acha que há muitos deles?
Veja - todos os críticos de seu projeto são pessoas que não se envolvem em comércio "manual" regularmente. No máximo - de vez em quando. E, como eles não olham para seu projeto como comerciantes "manuais" - eles o vêem como programadores. E, compreensivelmente, eles encontram muitas soluções muito dúbias.
Na minha opinião, sua pergunta agora deveria ser sobre encontrar este nicho (na minha opinião, um nicho muito estreito): programadores que preferem trocar de mãos.
Acho que vi um artigo em algum lugar, como no hubra, chamado "criar um construtor de GUI para Python", então pensei que talvez alguém tenha visto uma GUI multiplataforma onde eu possa adicionar meu próprio código
Se eu quiser escrever um construtor do zero, eu preferiria usar MQL.
Os modernos construtores de GUI (aqueles que "espalham botões em formulários") são uma coisa bastante tecnológica e anexar elementos MQL a eles não parece fantástico.
Na forma intermediária ( arquivo de projeto, etc.) quase todos eles têm XML descrevendo o layout e as relações entre os elementos.
A geração do código da plataforma alvo é de fato a transformação XSLT, que pode ser feita por qualquer um que pense ser um desenvolvedor da web :-)
Tomemos por exemplo o EasyAndFast (https://www.mql5.com/ru/code/19703) porque é baseado em objetos e tem todos os componentes necessários. (e aberto e documentado pelo caminho, ao contrário deste tópico),
e simplesmente escreva um tradutor.
Não há construtores de gui-mql, não porque seja mega-complexo, mas simplesmente porque não é procurado.