Discussão do artigo "Linguagem MQL como um meio de marcação da interface gráfica de programas MQL. Parte 1"
Li o artigo com atenção novamente e não encontrei o conceito de uma linguagem de marcação. Há algumas ideias sobre implementações em outras linguagens e possibilidades de emprestar algumas bibliotecas, mas o autor ainda não construiu o conceito. Sem ele, não faz sentido tomar emprestado ou modificar qualquer coisa.
O conceito deve ser descrito em palavras simples e claras, sem códigos, e explicar a essência da tecnologia - o que e como ela deve funcionar. Mas no artigo há alguns códigos, exemplos, etc. .... Do que se trata?
O capítulo:"Designing a markup language" (Projetando uma linguagem de marcação) não contém o conceito de uma linguagem de marcação. Autor, preste atenção que você não escreveu nada sobre tecnologia de linguagem de marcação, mas foi direto a alguns detalhes, como, onde e o que pode ser emprestado. Em seguida, você fala sobre alguma hierarquia de controladores (que na verdade não descreve) e entra em detalhes não relacionados.
É necessário começar com o conceito da tecnologia que está sendo criada, e esse conceito ainda não existe.
Bom artigo e boas decisões, é bom ler.
Para torná-lo 5+, um pouco não foi suficiente - uma breve revisão do "que é ruim/bom no resto do mundo" :-) O autor é claramente dono do assunto e não escreve do nada...
Espero das seguintes partes: algo como Geometry & Style Managers (para se livrar do cálculo de coordenadas e da distribuição de cores), o trabalho da GUI em termos de interação com a lógica básica.
outra junta.
Quantas peças serão, 38 ou 55?
E quantas partes haverá, 38 ou 55?
Nem todo mundo pode escrever "Guerra e Paz" em artigos no fórum MQL.
O autor de mais de um ciclo de 4 artigos nunca foi visto antes ))))
O material do artigo parece ser bem lido, mas há algum desconforto, em algum lugar que eu não sei em que se basear - XAML é tomado como base? - infelizmente, eu não o estudei e não o uso, assim como exceto WinForms e não uso outros recursos do C#.
Em geral, interessante, vamos ver o que vem a seguir, o único desejo é um pouco mais de imagens, na minha opinião o material parece muito seco se você apenas o ler.
O profissionalismo do autor inspira esperança, desde que ele possa lidar com o conceito e a implementação do início ao fim. O primeiro artigo dá a entender a intenção de pegar uma biblioteca pronta, modificá-la e transformá-la em uma linguagem de marcação. Não acredito no sentido de tal solução. A biblioteca em si é limitada, e a linguagem de marcação será fraca. Sem um nível qualitativamente novo de tecnologia e de controladores na tela, a "pele de carneiro" não vale a pena e, se o autor assumir os elementos desenhados, você precisará refazer o básico. Tudo isso requer um conhecimento muito profundo de tecnologia e muito tempo. A julgar pela maneira como o autor se apega aos nomes das variáveis (que serão milhares), à sintaxe e às regras, receio que não conseguirá concluir....
MAS! Este é apenas o primeiro artigo. Vamos ver...
Nem todo mundo pode escrever "Guerra e Paz" no fórum MQL em artigos
o autor de mais de um ciclo de 4 artigos não foi visto antes de ))))
O material do artigo parece ser bem lido, mas há algum desconforto, em algum lugar que não sei em que se basear - XAML é tomado como base... - infelizmente, eu não o estudei e não o uso, assim como não uso WinForms e não uso outros recursos do C#
Em geral, interessante, vamos ver o que vem a seguir, o único desejo é um pouco mais de imagens, na minha opinião o material parece muito seco se você apenas o ler.
Tentei estudar XAML, só que desde o início, e não entendi a piada de humor - por que estudar mais uma linguagem, e ainda por cima extremamente especializada, o que, além disso, não expande as possibilidades, mas as reduz. De qualquer forma, um dia você vai querer "ajustar" algo no funcionamento do programa ou tornar a interface mais flexível, então terá que estudar como tudo é feito de forma direta, sem pads. O benefício da linguagem de marcação é insignificante e, se você levar em conta que ainda terá que aprendê-la, é muito duvidoso. Ou eu não entendi a ideologia da XAML.
E eu tentei estudar XAML, só que desde o início, e não entendi a piada de humor - por que estudar outra linguagem, e ainda por cima uma linguagem muito pouco especializada, que, além disso, não expande as possibilidades, mas as restringe. De qualquer forma, um dia você vai querer "ajustar" algo quando o programa funcionar ou tornar a interface mais flexível, então terá que estudar como tudo é feito de forma direta, sem pads. O benefício da linguagem de marcação é insignificante e, se você levar em conta que ainda terá que aprendê-la, é muito duvidoso. Ou eu não entendi a ideologia da XAML.
Vamos aguardar o autor do artigo, que pode dar a direção da pesquisa sobre o que é conveniente no XAML, talvez eu leia, embora o principal, de fato, seja o resultado do artigo, o quão conveniente e funcional ele será, nesse estágio estou satisfeito com o SB para primitivas gráficas - as fontes estão disponíveis e são legíveis.
SZY: Sobre novas linguagens, bem, tudo é relativo, eu queria usar o SB para salvar alguns gráficos em .bmp... mas não entendi em um dia, cuspi no Google e me familiarizei com o Google Charts em 15 minutos e, em vez de .bmp, gerei .html - mesmo off-line, é possível visualizar os gráficos, ou seja, a usabilidade é a chave para o uso! ;)
E eu tentei estudar XAML, só que desde o início, e não entendi a piada de humor - por que estudar outra linguagem, e ainda por cima uma linguagem muito pouco especializada, que, além disso, não expande as possibilidades, mas as restringe. De qualquer forma, um dia você vai querer "ajustar" algo quando o programa funcionar ou tornar a interface mais flexível, então terá que estudar como tudo é feito de forma direta, sem pads. O benefício da linguagem de marcação é insignificante e, se você levar em conta que ainda terá que aprendê-la, é muito duvidoso. Ou eu não entendi a ideologia da XAML.
O grande valor do XAML é que ele simplifica o desenvolvimento de todos os tipos de janelas de diálogo e outras bobagens. No MFC, não é fácil criar uma lista com uma aparência diferente da padrão, você tem que se esforçar muito, mas aqui é uma ou duas vezes. Eu estive brincando com ele, é incrível, mas se você precisa criar interfaces, pode dominá-lo. E você não precisa aprender, é apenas um pedaço de Sharp. Ele realmente começa a economizar tempo, não imediatamente, mas à medida que você o aprende.
Pessoal, por que vocês estão criticando uma pessoa desde o primeiro artigo quando não conseguem ver o resultado? Nunca escrevi comentários aqui, mas o seu me obrigou a fazê-lo.
Não sou um programador profissional, mas um amador. E muitos artigos aqui, mesmo os malsucedidos, me fazem procurar soluções melhores, estudar mais profundamente as linguagens de programação. Para entender por que o autor implementou essa maneira específica de resolver o problema. Para aplicar algo em meus próprios desenvolvimentos. Qualquer artigo me faz aumentar a quantidade de conhecimento muitas vezes mais do que se eu apenas lesse livros e documentação.
Aqui está um exemplo simples. Já existem vários artigos sobre GUI aqui, mas tudo é implementado, embora com a ajuda de classes, mas no estilo procedural. Isso é incômodo e inconveniente. Você precisa entender todo o código, do início ao fim. Isso me fez olhar para outras linguagens, como C++, C#, em que, ao substituir um método virtual, por exemplo, doubleclick, você pode implementar o que quiser sem entrar em uma situação de loucura.
Comecei a estudar padrões de design e estruturas de dados dinâmicas. Como não há delegates no mql, tive que entender o que é esse prato e com o que ele é consumido. Tive que reescrever todas as classes padrão. Comecei do início, com CObject. No final, escrevi uma implementação simples do tratamento de eventos OnTradeTransaction, OnChartEvent e OnTimer usando OOP "real". Não estou familiarizado com a marcação XAML e, quando tentei estudá-la, pareceu-me muito entediante, mas agora vou me aprofundar nela para entender o que o autor quer transmitir e tive a oportunidade de implementar algumas de suas ideias por mim mesmo.
Portanto, antes de criticar duramente qualquer artigo, pense que há pessoas como eu que precisam de uma visão diferente sobre o mesmo assunto. Sugira, oriente, se você tiver um conhecimento mais profundo. Forme uma equipe. Será mais produtivo do que criticar um artigo.
- www.mql5.com
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Novo artigo Linguagem MQL como um meio de marcação da interface gráfica de programas MQL. Parte 1 foi publicado:
O artigo propõe uma nova ideia para descrever a interface de programas MQL com ajuda das construções da linguagem MQL. As classes especiais transformam o esquema visual MQL em elementos da GUI, permitem gerenciá-los de maneira unificada, configurar propriedades e processar eventos. Além disso, apresenta exemplos de uso de layouts para caixas de diálogo e elementos da biblioteca padrão.
Para que separar o layout do código e descrevê-lo numa linguagem especial? Aqui estão as principais vantagens dessa abordagem.
Para o ambiente MQL, fizemos algumas tentativas para resolver alguns desses problemas. Em particular, o designer visual das caixas de diálogo é apresentado no artigo Como projetar e construir classes de objeto, ele funciona com base na biblioteca MasterWindows. Mas seus os métodos de layout e sua lista de tipos de elementos suportados são muito limitados.
Nos artigos Usando layouts e contêineres para controles de GUI: a classe cbox e classe cgrid é sugerido um sistema de layout mais avançado, mas sem um designer visual. Ele suporta todos os controles padrão e outros herdados de CWndObj ou CWndContainer, mas o usuário ainda deve lidar nele com tarefas rotineiras para criar e colocar componentes.
Conceitualmente, essa abordagem com contêineres é muito avançada (basta apontar sua popularidade em quase todas as linguagens de marcação) e, portanto, vamos adotá-la. Num dos meus artigos anteriores (Implementado OLAP na negociação (Parte 2): Visualizando resultados da análise interativa de dados multidimensionais), propus uma modificação dos contêineres CBox e CGrid, além de alguns controles para apoiar as propriedades de "borracha". Em seguida, usaremos esses desenvolvimentos e melhorá-los para resolver o problema do posicionamento automático de elementos usando os objetos da biblioteca padrão como exemplo.
Autor: Stanislav Korotky