Discussão do artigo "Interfaces Gráficas X: Gestão avançada de listas e tabelas. Otimização do código (build 7)"
Artigo publicado Graphical Interfaces X: Gerenciamento avançado de listas e tabelas. Otimização de código (build 7):
Autor: Anatoli Kazharski
O que acessar para fazer o mesmo com a lista de combobox, não funciona assim:
if(id==CHARTEVENT_CUSTOM+..){
m_combobox_sm.Clear();
m_combobox_sm.ItemsTotal(4);
m_combobox_sm.VisibleItemsTotal(4);
string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};
for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}
}
O que acessar para fazer o mesmo com a lista da caixa de combinação não funciona assim:
if(id==CHARTEVENT_CUSTOM+..){
m_combobox_sm.Clear();
m_combobox_sm.ItemsTotal(4);
m_combobox_sm.VisibleItemsTotal(4);
string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};
for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}
}
A classe CComboBox tem métodos que retornam ponteiros para a lista e a barra de rolagem. Ao obter ponteiros para esses elementos, você pode chamar seus métodos.
CListView *GetListViewPointer(void) { return(::GetPointer(m_listview)); }
CScrollV *GetScrollVPointer(void) { return(m_listview.GetScrollVPointer()); }
1. O estilo zebra agora será definido como padrão para todas as tabelas, ou eu entendi errado?
1. O estilo zebra é um modo ativado. Ele é desativado por padrão. Se você precisar dele, basta chamar o método correspondente, especificando a segunda cor. Na verdade, o artigo explica isso em detalhes.
2. será possível.
3. pensarei nisso como parte da otimização adicional do código.
1. Modo habilitado para o estilo Zebra. Desativado por padrão. Se você precisar dele, basta chamar o método correspondente, especificando a segunda cor. Na verdade, o artigo fala sobre isso em detalhes.
2. será possível.
3. pensarei nisso como parte de uma otimização adicional do código.
3. Para ser sincero, estou um pouco surpreso com a presença de métodos repetitivos em seu programa. Gostaria de tê-lo estudado com mais cuidado... Você pode considerar meu código uma "pilha não otimizada", mas não tenho nenhum mecanismo que se repete duas vezes. Não há funções semelhantes. Gostaria que você fizesse o mesmo. )
Hoje em dia, quando os elementos são, em sua maioria, compostos de vários objetos gráficos, você não pode prescindir de métodos virtuais comuns. Por otimização, nesta parte, eu me referi ao estágio de desenvolvimento em que todos os elementos serão desenhados. Então, suponho que esses métodos virtuais padrão possam ser reduzidos a uma única declaração e implementação na classe base de um elemento.
Não quero discutir seu código aqui. Ele é privado, portanto, guarde-o para você. Minha opinião sobre o que vi em seu código não mudou.
1. Atualmente, quando os elementos são, em sua maioria, montados a partir de vários objetos gráficos, é impossível prescindir de métodos virtuais comuns. Por otimização, nesta parte, quero dizer o estágio de desenvolvimento em que todos os elementos serão desenhados. Então, suponho que esses métodos virtuais padrão possam ser reduzidos a uma única declaração e implementação na classe base de um elemento.
2) Não quero discutir seu código aqui. Ele é privado, portanto, guarde-o para você. Minha opinião sobre o que vi em seu código não mudou.
1. Talvez, quando começar a implementar a tecnologia de controles "desenhados", você consiga se livrar da duplicação de métodos. Entretanto, como você mesmo observou, você supõe que isso ajudará. Ou seja, talvez não ajude... Minha opinião é que essas coisas não estão relacionadas.
Um elemento de controle "desenhado" não é funcionalmente diferente de um elemento construído a partir de vários objetos, mas sua criação requer uma tecnologia completamente diferente. Ou seja, uma tecnologia diferente da que é usada para criar elementos feitos de vários objetos.
É interessante que o elemento desenhado consiste em vários objetos, mas esses objetos, por um lado, não são objetos MT (mas apenas detalhes de desenho) e, por outro lado, dentro do programa, os detalhes de desenho são os mesmos objetos funcionais com suas próprias propriedades.
Ou seja, o número de objetos não diminui. Apenas a partir dos objetos MT, os detalhes dos elementos (e os próprios elementos) tornam-se objetos internos do programa. E o programa (diferentemente da função OnChartEvent()) os vê, define e trabalha com eles.
A tecnologia é muito complexa e exige uma otimização muito alta do código...
2. Sem ter ideia de como todo o mecanismo funciona, você se apressou em dar sua opinião. Você não poderia mudá-lo porque viu uma pequena parte do código até agora. Bem, terei que aturar essa sua opinião. Infelizmente).
P.S . Não vamos discutir isso. Não estou ofendido. :)
1. Talvez, ao implementar a tecnologia de controles "desenhados", você consiga se livrar da duplicação de métodos. Entretanto, como você mesmo observou, você supõe que isso ajudará. Ou seja, talvez não ajude... Minha opinião é que essas coisas não estão relacionadas.
Presumo isso, pois ainda não implementei e testei.
Um elemento de controle "desenhado" não é funcionalmente diferente de um elemento construído a partir de vários objetos, mas sua criação requer uma tecnologia completamente diferente. Ou seja, uma tecnologia diferente da que é usada para criar elementos feitos de vários objetos.
É interessante que o elemento desenhado consiste em vários objetos, mas esses objetos, por um lado, não são objetos MT (mas apenas detalhes de desenho) e, por outro lado, dentro do programa, os detalhes de desenho são os mesmos objetos funcionais com suas próprias propriedades.
Ou seja, o número de objetos não diminui. Apenas a partir dos objetos MT, os detalhes dos elementos (e os próprios elementos) tornam-se objetos internos do programa. E o programa (diferentemente da função OnChartEvent()) os vê, define e trabalha com eles.
Você escreve coisas tão óbvias que nem sequer é interessante discutir isso com você. Eu vejo as coisas de forma um pouco diferente. Expressarei minha opinião em um dos próximos artigos da segunda etapa do desenvolvimento da biblioteca.
Presumo que sim, pois ainda não o implementei e testei.
Você escreve coisas tão óbvias que nem é interessante discutir com você. Eu vejo as coisas de forma um pouco diferente. Expressarei minha opinião em um dos próximos artigos da segunda etapa do desenvolvimento da biblioteca.
Bem, não sei por que essas coisas são óbvias para você. Você já implementou isso?
A tecnologia de que falamos não está descrita em nenhum artigo sobre MQL. Ou estou errado e você pode me fornecer um link?
O principal é que é impossível chegar a essa tecnologia por meio da otimização cosmética - você precisa"substituir a base".
Mudar a base é o processo mais difícil. Normalmente, tudo entra em colapso - esquemas, interconexões, mecanismos.... TUDO. Depois, tudo é restaurado de novo.
Em geral, não se pode desejar que seu inimigo passe por isso (e, além disso, é preciso passar por isso muitas vezes...). E, no final, o código será bem diferente do que era no início.
H.Y. Imagine se alguém lhe disser, depois de todos os seus esforços: "Seu código é um amontoado não otimizado". Você se sentiria ofendido? :)
Bem, não sei por que essas coisas são óbvias para você. Você já implementou isso?
A tecnologia da qual estávamos falando não está descrita em nenhum artigo sobre MQL. Ou estou errado e você pode me fornecer um link?
Se eu ainda não implementei algo, isso não significa que eu não tenha pensado sobre isso e não saiba como vou implementá-lo. Eu só não tenho as mãos na massa. Apenas ainda não coloquei minhas mãos nisso. Ao contrário de você, eu descrevo tudo o que faço em detalhes. Isso também leva tempo.
Não preciso ler artigos para implementar algo. Se não houver uma solução pronta, procuro meus próprios métodos. Mas você tem a oportunidade de ler artigos. E, em vez de ler e não fazer perguntas que são explicadas no artigo, você fica "atirando" aleatoriamente.
O principal é que é impossível chegar a essa tecnologia por meio da otimização cosmética - você precisa"mudar a base".
Mudar a base é o processo mais difícil. Normalmente, tudo entra em colapso - esquemas, interconexões, mecanismos.... TUDO.
E, no final, o código será bem diferente do que era no início.
É diferente com a OOP. Você simplesmente tem uma lacuna absoluta nessa esfera de conhecimento. O que você considera "o processo mais difícil" pode ser resolvido de forma bastante simples com a OOP.
H.I. Imagine se alguém lhe disser, depois de todos os seus esforços: "Seu código é um heap não otimizado". Você se sentiria ofendido? :)
A ofensa não é peculiar a mim. Lembro-me de que um dos participantes do fórum em inglês sugeriu uma solução (sem implementação) para aprimorar o esquema. Eu a utilizei. O processo mais difícil não surgiu. Com sua abordagem, você se torturará por muito tempo se gabando da má implementação e brigando com moinhos de vento.
- 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 Interfaces Gráficas X: Gestão avançada de listas e tabelas. Otimização do código (build 7) foi publicado:
O código da biblioteca precisa ser otimizado: ele deve ser mais regularizado, o que é - mais legível e compreensível para estudar. Além disso, nós vamos continuar a desenvolver os controles criados anteriormente: listas, tabelas e barras de rolagem.
Por isso, decidiu-se criar uma classe intermediária herdada adicional para colocar o código e os métodos frequentemente repetidos para trabalhar com o ponteiro do formulário, ao qual os controles estão ligados. Parte do esquema da biblioteca quanto à relação entre o formulário e os controles aparentam a seguir:
Fig. 3. Parte do esquema da biblioteca quanto à relação entre o formulário e os controles.
Autor: Anatoli Kazharski