Discussão do artigo "Controles gráficos personalizados. Parte 3. Formas"
Um trabalho bom e útil, Dimitri. Há uma sugestão para a quarta parte: "Assistente de formulário" ou "Editor de formulário visual". O que você acha disso?
Respeito, Dimitri. Você fez um ótimo trabalho.
Por favor, aceite algumas críticas para a próxima versão das classes v4.
1. Não há abstração suficiente no projeto básico. Descobriu-se que cada controle que você tem atua como uma unidade independente. Como resultado, não é possível combiná-los em uma matriz, por exemplo.
2. Cada classe de um elemento agora tem, em geral, seu próprio conjunto exclusivo de funções. Isso não é bom. Deveria haver um ancestral comum cujas funções fossem simplesmente substituídas nos descendentes. Especialmente porque há muitas funções com o mesmo nome nas classes atuais. O que o impede de criar um ancestral comum?
3. se uma classe base aparecer, será possível ocultar o tratamento de eventos dentro dos descendentes, em vez de colocá-los todos do lado de fora do formulário. para fazer uma cascata de eventos dentro dos objetos (semelhante ao CSS na Web).
Mas, em geral, todas as três partes do artigo são dignas de prêmio, especialmente as "cutucadas" ao pressionar botões e suas respostas interativas aos pressionamentos, dependendo do estado do elemento.
PS.
E o menu multinível que você ainda está terminando, um artigo separado sobre ele não é necessário, muito gordo para uma tarefa tão pequena para escrever um novo artigo. Que seja apenas uma atualização na versão v4.
A classe de árvore CTreeCtrl pode ser obtida no artigo https://www.mql5.com/pt/articles/272 ou CTreeNode oferecido no kit MT.
- 2011.03.16
- o_O
- www.mql5.com
Um trabalho bom e útil, Dimitri. Há uma sugestão para a quarta parte: "Assistente de formulário" ou "Editor de formulário visual". O que você acha disso?
Pessoalmente, vejo isso de forma positiva. Mas será que é necessário? O Visual apenas simplifica o posicionamento dos objetos. Se você fizer isso corretamente, precisará vincular a geração de código para objetos criados, vincular variáveis ou classes ao objeto. E, o mais importante, o tratamento de eventos.
Mas, nessas classes não abstratas, isso não pode ser feito. Elas são muito manuais. Em muitos lugares, é necessário escrever objetos recém-criados e seu processamento.
Para eventos, por exemplo, não há essa divisão em sistema e usuário - como Draw (sistema básico) e OnDraw - além do usuário com seu próprio desenho.
Em outras estruturas (por exemplo, Joomla!), não há apenas uma função personalizada OnDraw. E ela é dividida em duas: BeforDraw e AfterDraw. Ou seja, o programador pode manipular o evento do sistema EVENT_DRAW - tanto antes do início do desenho do sistema quanto depois de seu término.
Respeito, Dimitri. Você fez um ótimo trabalho.
Por favor, aceite algumas críticas para a próxima versão das classes v4.
1. Não há abstração suficiente no projeto básico. Descobriu-se que cada controle que você tem atua como uma unidade independente. Como resultado, não é possível combiná-los em uma matriz, por exemplo.
2. Cada classe de um elemento agora tem, em geral, seu próprio conjunto exclusivo de funções. Isso não é bom. Deveria haver um ancestral comum cujas funções fossem simplesmente substituídas nos descendentes. Especialmente porque há muitas funções com o mesmo nome nas classes atuais. O que o impede de criar um ancestral comum?
3. se uma classe base aparecer, será possível ocultar o tratamento de eventos dentro dos descendentes, em vez de colocá-los todos do lado de fora do formulário. para fazer uma cascata de eventos dentro dos objetos (semelhante ao CSS na Web).
Mas, em geral, todas as três partes do artigo são dignas de prêmio, especialmente as "cutucadas" ao pressionar botões e suas respostas interativas aos pressionamentos, dependendo do estado do elemento.
PS.
4. Um menu multinível que você ainda está terminando, um artigo separado sobre ele não é necessário, muito gordo para uma tarefa tão pequena para escrever um novo artigo. Que seja apenas uma atualização na versão v4.
A classe de árvore CTreeCtrl pode ser obtida no artigo https://www.mql5.com/pt/articles/272 ou CTreeNode oferecido no kit MT.
1- É possível montar controles de tipo único em uma matriz. Por que você gostaria de reunir controles diferentes em uma única matriz?
2. Se você usar uma classe base (uma para todos os controles), isso significa que ela deve ter todos os métodos que qualquer uma das subclasses pode ter. Com classes independentes, na lista suspensa de métodos (durante o desenvolvimento), temos apenas os métodos que realmente existem na classe. Na minha opinião, esse é um ponto muito importante. Posso imaginar alguém sentado e tentando chamar o método SetWidth() para uma barra de rolagem vertical.
O segundo argumento - todas as classes são comentadas para o doxygen; se houver uma classe base e subclasses, não haverá uma estruturação tão óbvia na documentação.
Eu tento criar soluções prontas para que possam ser usadas de "olhos fechados". Para acelerar o processo de criação de um novo controle, você pode usar um modelo com todos os métodos obrigatórios.
3. não entendi muito bem. Se um controle tiver outro controle dentro dele, seu tratamento de eventos ficará oculto. De qualquer forma, você terá de chamar Event() para cada controle.
4. Não sei, talvez... Tenho minha própria classe especialmente projetada para a criação de menus, não é necessário chamar AddNode(), AddItem() é chamado, e o nível é determinado pelo número de espaços com os quais o nome do item começa. O processo de criação de uma árvore é muito claro. Até agora, ele funciona com a exibição no comentário e no controle de teclas. Em geral, você pode criar vários menus em árvore: 1) como um menu principal normal com guias suspensas, 2) exibir itens de uma guia e o caminho para o topo, 3) com exibição em árvore (como o Windos Explorer).
1) Pessoalmente, vejo isso de forma positiva. Mas será que é necessário? A visualização apenas simplifica o posicionamento dos objetos. Se você fizer isso corretamente, precisará vincular a geração de código para objetos criados, vincular variáveis ou classes ao objeto. E, o mais importante, o processamento de eventos.
2. Mas, nessas classes não abstratas, isso não pode ser feito. Elas são muito manuais. É necessário escrever em muitos lugares os objetos recém-criados e seu processamento.
Para eventos, por exemplo, não há essa divisão em sistema e usuário - como Draw (sistema básico) e OnDraw - uma adição do usuário com seu próprio desenho.
Em outras estruturas (por exemplo, Joomla!), não há apenas uma função personalizada OnDraw. E ela é dividida em duas: BeforDraw e AfterDraw. Ou seja, o programador pode manipular o evento do sistema EVENT_DRAW - tanto antes do início do desenho do sistema quanto depois de seu término.
1. Será possível gerar automaticamente o código para lidar com eventos de controles e obter funções de eventos para todos os controles, como HScrollBar1_OnChange()....
2. Ainda não há eventos, por exemplo, quando os valores são definidos programaticamente, os eventos são gerados somente quando os valores são inseridos pelo usuário. Esse é um mínimo suficiente, nada a mais. Caso contrário, alguém que esteja aprendendo a programar por conta própria será inundado com eventos.
Um trabalho bom e útil, Dimitri. Há uma sugestão para a quarta parte: "Form Wizard" ou "Visual Form Editor". Como você vê isso?
... Há uma sugestão para a parte 4: "Assistente de formulário" ou "Editor de formulário visual". O que você acha disso?
1. Controles de tipo único podem ser montados em uma matriz. Por que reunir diferentes tipos de controles em uma única matriz?
Para colocar tudo em um loop e se livrar de tipos específicos no serviço de eventos.
2. Se você usar uma classe base (uma para todos os controles), isso significa que ela deve ter todos os métodos que qualquer uma das subclasses pode ter. Com classes independentes, na lista suspensa de métodos (durante o desenvolvimento), temos apenas os métodos que realmente existem na classe. Na minha opinião, esse é um ponto muito importante. Posso imaginar alguém tentando chamar o método SetWidth() de uma barra de rolagem vertical.
Todas as funções da classe base são rolhas vazias com funcionalidade geral mínima. Mesmo que alguém, sem saber, chame uma função não relacionada para um elemento, absolutamente nada de ruim acontecerá. Polimorfismo.
O segundo argumento - todas as classes são comentadas para o doxygen, se houver uma classe base e subclasses, não haverá uma estruturação tão óbvia na documentação.
Haverá. Só que será diferente... :)
- 2010.03.25
- MetaQuotes Software Corp.
- www.mql5.com
1. colocar tudo em um único loop e livrar-se de tipos específicos no serviço de eventos.
2. a questão é que a classe base não tem nenhuma implementação de funções de ações específicas. todas as funções da classe base são rolhas vazias com funcionalidade geral mínima. Mesmo que alguém, sem saber, chame uma função não relacionada para um elemento, absolutamente nada de ruim acontecerá. Polimorfismo, no entanto.
3. acontecerá. só que será diferente.... :)
1. isso é tudo? Para que possamos mexer no ponto 2 - despejo de método?
Alternativas:
1) A necessidade de adicionar manualmente uma chamada Event() para cada classe (que consiste em copiar com o mouse uma linha e alterar algumas letras à esquerda do ponto) e, ao mesmo tempo, na lista de métodos de cada classe, temos apenas métodos de trabalho correspondentes a essa classe, clicamos no ponto, a lista apareceu e tudo ficou claro.
2) Processamento automático de Event() de todas as classes, enquanto uma função ainda precisará ser chamada de OnChartEvent() e, por outro lado: um despejo de métodos na lista. Além disso, você teria que destruir os ponteiros no deinit.
Veja um pouco mais a fundo por que todos os Event() devem ser processados em um loop, cada controle deve ter suas próprias ações para seu Event(), os controles não servem apenas para inserir um valor e não apenas para fazer com que tudo se mova e pisque na tela, mas também (principalmente) para usar os valores inseridos no programa.
3. Você terá de ler cerca de metade dos métodos de um controle em um local da documentação e a outra metade em outro.
1. é só isso? Para isso, mexer no ponto 2 - o descarte de métodos?
Alternativas:
1) A necessidade de adicionar manualmente uma chamada Event() para cada classe (que consiste em copiar com o mouse uma linha e alterar algumas letras à esquerda do ponto) e, ao mesmo tempo, na lista de métodos de cada classe, temos apenas métodos de trabalho correspondentes a essa classe, clicamos no ponto, a lista caiu e tudo ficou claro.
2) Processamento automático de Event() de todas as classes, enquanto uma função ainda precisará ser chamada a partir de OnChartEvent() e, por outro lado: um despejo de métodos na lista. Além disso, teremos que destruir os ponteiros no deinit.
Veja um pouco mais a fundo por que todos os Event() devem ser processados em um loop, cada controle deve ter suas próprias ações para seu Event(), os controles não servem apenas para inserir um valor e não apenas para fazer tudo se mover e piscar na tela, mas também (principalmente) para usar os valores inseridos no programa.
3. Você terá de ler cerca de metade dos métodos de um controle em um local da documentação e a outra metade em outro.
Você fez tudo certo.
Dadas as possibilidades do ME, é bastante conveniente, o minimalismo japonês na era do kitsch total, tudo está lá, nada supérfluo.
Quem quiser fazer um loop pelos objetos pode implementar um shell postfix no qual poderá escrever o que quiser.
- 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 Controles gráficos personalizados. Parte 3. Formas foi publicado:
Este é o último dos três artigos dedicados a controles gráficos. Ele cobre a criação do principal componente da interface gráfica - a forma - e seu uso em combinação com outros controles. Além das classes de forma, as classes CFrame, CButton, CLabel foram adicionadas à biblioteca de controle.
Autor: Dmitry Fedoseev