Discussão do artigo "Interfaces Gráficas I: Preparação da Estrutura da Biblioteca (Capítulo 1)" - página 2

 
Vasiliy Sokolov:
Excelente. Se possível, mais imagens com exemplos de interfaces gráficas. Em geral, o tópico é muito necessário: há muito tempo, foi necessário começar a documentar a biblioteca padrão.

Talvez eu tenha entendido mal a pergunta anterior.

Ao usar classes da biblioteca padrão, eu me referia apenas a classes desse tipo:

Ou seja, aquelas classes com as quais você pode criar objetos primitivos, obter e alterar suas propriedades.

Mas (deixe-me esclarecer) eu não uso da biblioteca padrão a parte que é oferecida para a criação de interfaces gráficas. Esse é um projeto completamente separado.

P.S. Haverá muitas imagens e exemplos (o máximo de detalhes).

 
Anatoli Kazharski:

Talvez eu tenha entendido mal a pergunta anterior.

Ao usar classes da biblioteca padrão, eu quis dizer apenas classes desse tipo:

Ou seja, aquelas classes com as quais você pode criar objetos primitivos, obter e alterar suas propriedades.

Mas (deixe-me esclarecer) eu não uso da biblioteca padrão a parte que é oferecida para a criação de interfaces gráficas. Esse é um projeto completamente separado.

P.S. Haverá muitas imagens e exemplos (o máximo de detalhes).

Ah, agora estou entendendo.

E por que você decidiu não basear seu projeto na biblioteca GUI do MQ? Talvez fosse mais fácil expandi-la e aprofundá-la?

A propósito, tenho minha própria biblioteca de GUI, seria interessante comparar conceitos.

 
Vasiliy Sokolov:

Ah, entendi.

Por que você decidiu não basear seu projeto na biblioteca GUI do MQ? Talvez fosse mais fácil expandi-la e aprofundá-la?

A propósito, tenho minha própria biblioteca de GUI, seria interessante comparar conceitos.

Descrevi meus pensamentos sobre isso logo no início deste artigo. Em resumo, para acertar (na minha opinião), você deveria ter começado o projeto do zero.

Acredito que os primeiros 14 artigos desta série já permitirão que você faça uma comparação adequada de conceitos. Há muitas nuances aqui, sem a realização das quais seria impossível obter alta qualidade.

 
Sim, é muito provável que 2016 seja o ano das interfaces ))
 

Projeto interessante e útil concebido! Aguardarei ansiosamente a publicação de seus artigos!

Abraços...

 

Boa tarde!

Tenho uma sensação dupla ao me familiarizar com a biblioteca criada. Por um lado, estou impressionado com a flexibilidade e a flexibilidade da biblioteca. O trabalho realizado é enorme, e é claro que você pode dizer um grande OBRIGADO!

Por outro lado, a implementação de alguns pontos é intrigante, pois aumenta a intensidade do trabalho de criação de novos formulários.

Por exemplo, vamos considerar a função para mover o formulário no gráfico.

Na função, é necessário enumerar todos os objetos de formulário criados. Por quê? Porque todos os elementos criados são colocados no contêiner (matriz) do próprio formulário. Por que você precisa enumerar todos os elementos criados na função? Por que não pode simplesmente fazer um loop no contêiner e alterar as coordenadas de todos os elementos?

O mesmo se aplica a outros métodos. Por exemplo, na função Hide(), todos os elementos são ocultos por meio de um loop pelos elementos do formulário, e na função Delete(), todos os elementos são listados discretamente. Não está claro.

Isso faz com que, ao adicionar novos elementos ao formulário, você tenha que se lembrar de todas as funções PADRÃO em que é necessário especificar cada novo elemento. Isso NÃO é muito conveniente. O mesmo se aplica ao foco em um elemento. Se um elemento estiver em foco, sua exibição deverá ser alterada de acordo com o algoritmo QUANDO for criado, por exemplo, para botões baseados em imagens, as imagens "BmpFileOn" e "BmpFileOff" são especificadas. Lá você também pode definir outras propriedades para o foco: cor da moldura, cor do plano de fundo, cor do texto, tamanho do texto e assim por diante. E, nesse caso, não há necessidade de escrever isso na função de definição de foco, basta percorrer a matriz de elementos e definir suas propriedades de acordo com as propriedades "em foco"/"fora de foco".

Colapso...

Inicialmente, a biblioteca foi projetada de forma que o formulário seja recolhido sob o cabeçalho (para cima). Ao mesmo tempo, o cabeçalho permanece onde o formulário está. Estou tentando implementar o comportamento padrão do formulário criado, ou seja, quando a janela é minimizada, a janela é minimizada para baixo e somente o cabeçalho permanece (na parte inferior). Além disso, estou tentando implementar dois modos do formulário: "padrão", "minimizado" e, é claro, minimizado.

Já na fase de criação dos meus botões, enfrentei todos os problemas acima. E o desenvolvimento acabou de começar....

Também acredito que seria mais universal criar não um contêiner (matriz) para armazenar elementos criados e operações sobre eles, mas uma hierarquia de contêineres. Ou seja, um único contêiner é criado para todo o formulário, o que lhe permite executar ações comuns no formulário: mover, excluir, ocultar e assim por diante. Esse contêiner deve incluir dois outros contêineres: o contêiner dos elementos de cabeçalho e o contêiner dos elementos do formulário propriamente dito. Um terceiro contêiner também é possível: o contêiner do porão, se houver um. Por sua vez, o contêiner do próprio formulário pode conter contêineres de blocos para colocar elementos no formulário. Nessa implementação, por exemplo, minimizar o formulário para baixo deve resultar na exclusão dos elementos do próprio contêiner do formulário e na movimentação dos elementos do contêiner do cabeçalho. Ao executar ações gerais, execute operações nos próprios contêineres. Ou seja, se o próprio formulário for movido, o contêiner de elementos de todo o formulário (aplicativo) será movido.

Espero que o autor entenda minha ideia. :)

Mais uma vez, repito: o trabalho realizado é excelente, útil e informativo. Mas qualquer passo que se afaste da representação do autor começa a criar dificuldades. É claro que não há soluções completamente universais. Mas algumas funções padrão comuns da biblioteca poderiam se tornar realmente universais.

Atenciosamente, Alexey.

 
AlexBar3073:

...espero que o autor entenda meu ponto de vista.....

Meu ponto de vista está claro. Obrigado.

A biblioteca ainda está em desenvolvimento. Ela está longe de ser a última versão e muitas partes dela serão otimizadas e desenvolvidas.

Você pode fazer download da versão mais recente (2016.11.20) neste artigo: GUI X: Caixa de entrada de texto, controle deslizante de imagem e controles simples (compilação 5).

 
Anatoli Kazharski:

Entendi seu ponto de vista. Obrigado.

A biblioteca ainda está em desenvolvimento. Ela está longe de ser a versão mais recente e muitas partes dela serão otimizadas e desenvolvidas.

Você pode baixar a versão mais recente (2016.11.20) neste artigo: GUIs X: Caixa de entrada de texto, controle deslizante de imagem e controles simples (compilação 5).

Eu sei que não é a última. :) Baixei a última versão para o mt4 e estou tentando criar a interface com ela. Mas entendo que a biblioteca para o mt5 também funcionará no mt4, se não forem usados mecanismos específicos para o mt5.

Espero que os comentários e sugestões que fiz sejam refletidos nas próximas versões da biblioteca e que ela se torne ainda mais flexível e universal e, ao mesmo tempo, mais simples do ponto de vista da aplicação prática. Durante o desenvolvimento da biblioteca, foi usado o mecanismo "em cascata" de herança de classes, o mesmo que propus para a formação de elementos de formulário, ou seja, herança de contêineres. E o descendente pode usar não apenas as propriedades globais (de todo o aplicativo de formulário), mas também as propriedades do pai: pontos de ancoragem, visibilidade, movimento e assim por diante. :)

Acompanharei o lançamento de novos artigos e o desenvolvimento da biblioteca com grande impaciência.

Atenciosamente, Alexey.

 
AlexBar3073:

Sei que não será a última. :) Baixei a mais recente para o mt4 e estou tentando criar a interface com ela. Mas entendo que a biblioteca para o mt5 também funcionará no mt4, se não forem usados mecanismos específicos para o mt5.

A versão MT4 não será desenvolvida por mim. Somente para o MT5.

AlexBar3073:

Espero que os comentários e sugestões que fiz sejam refletidos nas próximas versões da biblioteca e que ela se torne ainda mais flexível e universal e, ao mesmo tempo, mais simples do ponto de vista da aplicação prática.

Inicialmente, é difícil dizer qualquer coisa. Você pode pensar teoricamente sobre como seria melhor por um longo tempo. Tudo ficará claro em testes reais.

 
Anatoli Kazharski:

A versão para o MT4 não será mais desenvolvida por mim. Somente para o MT5.

Inicialmente, é difícil dizer algo. Você pode pensar teoricamente sobre como seria melhor por um longo tempo. Tudo ficará claro nos testes reais.

Sim, eu já li que a versão para o MT4 não será desenvolvida - isso não é terrível.

Bem, é inegável o fato de que somente os testes podem mostrar como construir uma biblioteca melhor. Mas, do ponto de vista da OOP, o método proposto tem as melhores chances de implementação prática. :)