Discussão do artigo "Interfaces Gráficas I: Preparação da Estrutura da Biblioteca (Capítulo 1)" - página 3
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
...Mas, do ponto de vista da OOP, o método proposto tem a melhor chance de implementação prática. :)
É mais fácil falar do que fazer.
...
Vamos considerar, por exemplo, a função de mover um formulário no gráfico.
Na função, precisamos enumerar todos os objetos criados do formulário. 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 você não pode simplesmente fazer um loop no contêiner e alterar as coordenadas de todos os elementos?
...
Preste atenção ao tipo(CChartObject) da matriz(m_objects), que armazena ponteiros de todos os objetos gráficos deste ou daquele elemento(CElement). Você pode tentar usar a conversão dinâmica de tipos nesse caso, mas o código se tornará ainda mais complicado e voraz em termos de consumo de recursos, pois será necessário fazer verificações adicionais do tipo de ponteiro.
Quanto aos métodos Delete() e similares, você pode fazer um loop entre eles (só não cheguei a fazer isso ainda), já que todos os objetos têm o tipo CChartObject.
Presumo, cautelosamente, que tudo se tornará muito mais fácil após a transição para o segundo estágio de desenvolvimento da biblioteca, quando todos os elementos serão desenhados. Ou seja, haverá um elemento - um objeto(bmp).
verificações adicionais do tipo de ponteiro.
E como fazer uma verificação do tipo de ponteiro em MQL?
De acordo com meus dados, a linguagem não tem nenhum meio para isso. Eu gostaria de verificar se um objeto é uma instância de uma determinada classe ou se é um descendente de uma classe na hierarquia.
Por exemplo, estou implementando um padrão MVC e, para determinados modelos com propriedades editáveis (com um ancestral comum), inscrevo um objeto de visualização. Para exibir a tabela de propriedades desse objeto. Após as alterações no modelo, o ouvinte (visualização) é redesenhado e o objeto do modelo é passado.
Aqui temos que converter o modelo em um dos tipos de hierarquia de modelo (que pode retornar propriedades). Mas é impossível verificar se um objeto do tipo correto foi recebido.
Teoricamente, um programador de terceiros que esteja criando um aplicativo para uma interface pode cometer um erro e assinar essa visualização em outro modelo (de outra hierarquia, que não tenha um ancestral com propriedades editáveis). Isso não pode ser resolvido em tempo de execução e o aplicativo falhará.
Presumo cautelosamente que tudo se tornará muito mais fácil após a transição para o segundo estágio de desenvolvimento da biblioteca, quando todos os elementos serão desenhados. Ou seja, haverá um elemento - um objeto(bmp).
Eu segui esse caminho há alguns anos. Primeiro, criei um modelo DOM para a interface, desenhando primitivas, agregando exibições, passando eventos (popup, stop). Tudo foi desenhado em objetos gráficos MQL e, em princípio, funcionou. Mas quando o número de objetos ultrapassou 200, começou a ficar lento devido à sobrecarga de redesenho de cada objeto. Por isso, tudo foi abandonado por mais um ano, até o surgimento do Canvas. Então, tudo foi rapidamente transferido para ele, substituindo os métodos básicos de desenho da visualização e atualizando a lógica sem alterar mais nada. E agora, mesmo vários milhares de exibições na tela não causam atrasos no desenho, porque tudo é desenhado e comparado muito rapidamente na memória, e a saída é apenas uma imagem, ou seja, apenas um elemento dos objetos no gráfico.
No entanto, no último ano, por falta de tempo livre, o desenvolvimento da biblioteca UI praticamente parou.
Para não ser infundado, darei um exemplo de uma interface criada com base na IU em um único elemento do Canvas
Para não ser infundado, darei um exemplo de uma interface criada com base na IU em um elemento Canvas
Como posso verificar o tipo de ponteiro em MQL?
De acordo com meus dados, a linguagem não tem nenhum meio para isso. Eu gostaria de verificar se um objeto é uma instância de uma determinada classe ou se é um descendente de uma classe na hierarquia.
Por exemplo, estou implementando um padrão MVC e, para determinados modelos com propriedades editáveis (com um ancestral comum), inscrevo um objeto de visualização. Para exibir a tabela de propriedades desse objeto. Após as alterações no modelo, o ouvinte (visualização) é redesenhado e o objeto do modelo é passado.
Aqui temos que converter o modelo em um dos tipos de hierarquia de modelo (que pode retornar propriedades). Mas é impossível verificar se um objeto do tipo correto foi recebido.
Teoricamente, um programador de terceiros que esteja criando um aplicativo para uma interface pode cometer um erro e assinar essa visualização em outro modelo (de outra hierarquia, que não tenha um ancestral com propriedades editáveis). Isso não pode ser tratado em tempo de execução e o aplicativo falhará.
...
Talvez via dynamic_cast? Quando comecei a desenvolver a biblioteca, o dynamic_cast ainda não estava disponível.
Algo como isto (exemplo daqui) :
class CBar { };
//+------------------------------------------------------------------+
//| Função de início do programa de script|
//+------------------------------------------------------------------+
void OnStart()
{
void *vptr[2];
vptr[0]=new CFoo();
vptr[1]=new CBar();
//---
for(int i=0;i<ArraySize(vptr);i++)
{
if(dynamic_cast<CFoo *>(vptr[i])!=NULL)
Print("CFoo * object at index ",i);
if(dynamic_cast<CBar *>(vptr[i])!=NULL)
Print("CBar * object at index ",i);
}
CFoo *fptr=vptr[1]; // erro de conversão de ponteiro, vptr[1] não é um objeto CFoo
}
//+------------------------------------------------------------------+
//---
Eu segui esse caminho há alguns anos. Primeiro, criei um modelo DOM para a interface, desenhando primitivas, agregando visualizações, passando eventos (popup, stop). Tudo foi desenhado em objetos gráficos MQL e, em princípio, funcionou. Mas quando o número de objetos ultrapassou 200, começou a ficar lento devido à sobrecarga de redesenho de cada objeto. Por isso, tudo foi abandonado por mais um ano, até o surgimento do Canvas. Então, tudo foi rapidamente transferido para ele, substituindo os métodos básicos de desenho da visualização e atualizando a lógica sem alterar mais nada. E agora, mesmo vários milhares de exibições na tela não causam atrasos no desenho, porque tudo é desenhado e comparado muito rapidamente na memória, e a saída é apenas uma imagem, ou seja, apenas um elemento dos objetos no gráfico.
É verdade que, no último ano, por falta de tempo livre, o desenvolvimento da biblioteca da interface do usuário praticamente parou.
Isso é muito interessante. Você também implementou seus próprios campos de entrada?
Para não ser infundado, darei um exemplo de uma interface criada com base na UI em um elemento Bitmap
Parece legal. Obrigado pelo exemplo. )
Houve um tópico em que suas recomendações seriam muito úteis: Fazendo um projeto de crowdsource no Canvas
Talvez por meio do dynamic_cast? Quando comecei a desenvolver a biblioteca, o dynamic_cast ainda não estava disponível.
Ah, eu não vi isso. Oh, obrigado. Acontece que eles o adicionaram em agosto. Se ele retornar NULL e não ocorrer nenhum erro crítico, já está muito bom. Podemos trabalhar )
Você também implementou seus próprios campos de entrada?
Com os campos de entrada, isso é feito da seguinte forma:
No evento de foco no objeto do campo editável, um objeto gráfico do campo editável da configuração necessária com o valor atual é inserido na interface do usuário, com o qual você pode trabalhar, usando também o buffer de entrada (não há como ficar sem ele na interface),
no evento de desfoque , o valor do campo é salvo (e o objeto do gráfico do sistema - Edit é excluído). E o valor é exibido no bmp com texto.
Igor Volodin:
...
Com os campos de entrada, isso é feito da seguinte maneira:
No evento de foco no objeto do campo editável, um objeto gráfico do campo editável da configuração necessária com o valor atual é inserido na interface do usuário, com o qual você pode trabalhar usando, entre outras coisas, o buffer de entrada (não há como trabalhar sem ele na interface),
no evento de desfoque , o valor do campo é salvo (e o objeto gráfico do sistema - Edit é excluído). E o valor é exibido no bmp como texto.
Aha, entendi. Obrigado pelo esclarecimento.
Acho que essa é a melhor opção, mas quero tentar realizar tudo de forma que tudo seja desenhado em um único objeto. Isso permitiria obter total independência e experiência quando não importa em que ambiente você cria uma GUI. Digamos que haja apenas uma tela e nada mais. )
Parece legal. Obrigado pelo exemplo. )
Havia um tópico aqui em que suas recomendações seriam úteis: Fazendo um projeto de Canvas com crowdsourcing
Obrigado. Observando a quantidade de trabalho que você fez na interface, é um grande elogio para você. Eu não teria sido capaz de fazer isso. Em primeiro lugar, a publicidade e, em segundo, a consistência.
Com crowdsourcing? Arriscado. É claro que, se você tiver uma renda estável e tempo livre, é possível trabalhar para o benefício da sociedade. Mas a sociedade MQL o usará para produtos comerciais, não para produtos gratuitos. E a licença GPL, por si só, não o proibirá.
Em resumo, não vejo nenhum lucro para mim.
Mas, por fim, eu gostaria de tentar realizar tudo de forma que tudo seja desenhado em um único objeto. Isso permitiria obter total independência e experiência quando não importa em que ambiente você cria uma interface gráfica. Digamos que haja apenas uma tela e nada mais. )