Minha abordagem. O núcleo é o motor. - página 140
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
Sim. Exatamente. Todas as informações necessárias para que o motor reproduza uma GUI específica e trabalhe com ela. Agora estou instalando-o diretamente no motor, e depois tornando-o carregável a partir do arquivo que o construtor imprime.
Como isto é complicado e confuso.
Não seria mais fácil para o usuário de suas caldeiras shaitan fazê-lo de modo que depois que o usuário constrói os formulários, janelas e elementos necessários, ele apenas emite um arquivo mqh para se conectar ao programa via #include? O arquivo já contém OnChartEvent(), OnTimer(), OnTick() e outros elementos de ligação. A única coisa que resta é prescrever-lhe as ações necessárias, o que, de qualquer forma, terá de ser feito, mas você também precisa aprender sua linguagem de marcação. Caso contrário, você não precisa de nada disso - basta escrever em mql o que você precisa no arquivo mql gerado e ficar feliz.
Você percorreu o caminho de criar uma linguagem de marcação e conectá-la usando uma linguagem que o usuário não entende por alguma razão. Esta solução não atrairá usuários de linguagem mql para o produto.
Parece que, olhando para as maravilhas neste fio - o maior esforço mental que se tende a fazer é permanecer um tolo.
Mas ele irá sobrescrever todas as edições e encadernações dos usuários que estão nos eventos ?
Assim que a GUI muda - o usuário pressiona um botão e imprime os novos arquivos. O motor carrega os novos kernels e a aplicação do usuário tem que conectar os arquivos de emparelhamento atualizados.
Neste caso, um arquivo só precisa ser substituído (Conjunction Properties) e o outro arquivo precisa ser reconectado. Mas, é possível copiar o código já escrito do arquivo anterior.
O principal é não preencher os arquivos de conexão antes de se decidir sobre a GUI. Se forem acrescentadas novas janelas, isso dificilmente afetará nada. Se janelas e elementos antigos forem alterados, o código pode ter que ser retrabalhado também no programa.
Tudo isso está no construtor. O código KIB é escrito e o arquivo é recompilado.
Veja como trabalhar com a construtorahttps://www.mql5.com/ru/blogs/post/717782
Vejam só... Erros bobos infantis com nomes de arquivos e pastas, você trabalha no editor como se estivesse abrindo pela primeira vez...
E o que eu percebi é que não é de modo algum um construtor. Pensei que tinha um construtor visual...
E você chama este conceito de um avanço? De onde e para onde?
Como isto é complicado e confuso.
Não seria mais fácil para o usuário de sua caldeira shaitan-boiler fazê-lo de modo que depois que o usuário constrói os formulários, janelas e elementos necessários, ele simplesmente produz um arquivo mqh- para se conectar ao programa via #include? O arquivo já contém OnChartEvent(), OnTimer(), OnTick() e outros elementos de ligação. A única coisa que resta é prescrever-lhe as ações necessárias, o que, de qualquer forma, terá de ser feito, mas você também precisa aprender sua linguagem de marcação. Caso contrário, você não precisa de nada disso, basta escrever em mql o que você precisa no arquivo mql gerado e ficar feliz.
Você percorreu o caminho da criação de uma linguagem de marcação e conectividade usando uma linguagem que o usuário não entende por alguma razão. Esta solução não atrairá usuários de linguagem mql para o produto.
A propósito, sim.
Eu tenho exatamente o mesmo modo quando recompilando. É claro que nunca fiz arquivos MQH prontos para uso, apenas escrevo textos simples e depois deles transfiro textos de procedimentos de inicialização para módulos básicos, mas a idéia é a mesma.
Peter, realmente - tornaria a vida de seus usuários bastante fácil se, ao invés de configurações que você tem que lembrar como usar - seria gerado um arquivo MQH pronto com configurações prontas!
E este é seu conceito que você chama de avanço? De onde e para onde?
Este é um avanço - desde pessoas que querem Expert Advisors prontos com um botão "cutp dough" (ou pelo menos com dois botões, outro - "cutp huge dough") - até pessoas que irão negociar em modo semi-automático, abrindo negócios, acompanhando-os e fechando-os com a ajuda dos componentes visuais de Peter!
Estou convencido de que se tais pessoas aparecerem - será realmente um grande avanço.
Só tenho dúvidas de que isso seja possível. As pessoas são preguiçosas por natureza, e para o comércio manual (mesmo semi-automático) - você precisa de muita experiência, e de onde o monde Beau monde local o obtém?
A propósito, sim.
Este é exatamente o caminho que eu tomo quando recompilando. Mas não preparo os arquivos MQH, escrevo os de texto simples e depois deles transfiro o texto dos procedimentos de inicialização para os módulos principais, mas a idéia é a mesma.
Peter, realmente - facilitaria a vida de seus usuários, se ao invés de configurações, que você tem que lembrar como usar - fosse gerado um arquivo MQH pronto com configurações prontas!
Não entendia de que configurações estávamos falando. Mas eu farei o que puder.
Explicar com mais detalhes.
Sem documentação, então links de memória (em algum lugar das profundezas da pista) :-)
Você gera um arquivo com uma função com muitos interruptores aninhados que despacha mensagens dos elementos da interface para "pressionado" "liberado". O usuário digita as reações aos eventos ali ocorridos.
Você mudou - editou a interface, e agora o que dizer deste arquivo?
Quanto trabalho, por exemplo, um usuário deveria ter para dividir o painel em duas janelas - uma contendo botões e outra uma mesa (assim, por exemplo, o usuário poderia fechá-la e não ficar mais solto na tela)?
E, por exemplo, algumas colunas devem ser trocadas. É apenas típico - fazer um layout, usá-lo, mudar a aparência para um mais conveniente
Eu não sei de que configurações estamos falando. Mas eu farei o que puder.
A idéia é que depois que todas as formas, janelas, elementos visuais forem construídos, um arquivo MQL pronto seria criado, destinado à compilação direta.
Como eu entendo agora, os usuários têm de inserir todos os tamanhos, coordenadas, travessões... Este é um trabalho muito tedioso e entediante. Seria bom se fosse automatizado. O resultado seria um arquivo MQH que está pronto para ser recompilado.
Eu não sei de que configurações estamos falando. Mas eu farei o que puder.
Aprenda OOP e você teria feito há muito tempo, e não apenas o que você poderia, mas muito mais - um enorme espaço para a criatividade, da qual você nem mesmo está ciente agora. De forma rápida, eficiente e profissional.
Mas há anos você tem se preocupado com o seu motor constantemente exagerado.
E se você está orgulhoso da quantidade de código que escreveu, você é um "índio" na programação. Isto não é um insulto - basta procurar por esta definição, ela se encaixa exatamente no que você faz.
Você pode escrever código de mil linhas e escrever código de cem linhas, e ambos farão o mesmo conjunto de ações. Mas é muito mais difícil mudar ou complementar o código inchado do que o código não inchado. Mas você prefere se vangloriar do número de linhas que você escreveu (cutucando o Nikolai no nariz com elas), chamando tudo isso de um enorme projeto. Como uma criança, por amor de Deus.