como criar objetos de forma dinâmica? (Algumas coisas do OOP) - página 5
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
2. Framework from scratch.
Similar here. When I started to go a bit deeper into the standard libraries I found many things, which I did not like. Not only the bad performance of those, but also lack of flexibility and also because of an incomplete architecture. I am missing for example a global CMouse class/object as well as a class between CWnd and CObject, because CWnd objects are childs of the chart as well as lines are, and there is no connection to such and no final implementation of any such objects at all like I described it above. And, there is no master object, which holds all such chart objects which makes it possible to show/hide all of them with one command, destroy them, whatever. CCanvas, same thing, a nice class but where is the implementation with CWnd which allows me to create interactive objects based on bitmaps that inherit from CWnd? And so on.
Qual é o papel de um CMouse global? Serve ao usuário final apenas como uma classe autônoma, para ter fácil acesso ao gerenciamento do mouse? Como ele se relaciona com a estrutura?
Sobre a classe entre CWnd e CObject, eu não sigo sua explicação sobre a razão pela qual você os achou necessários. Os objetos CWnd são filhos da tabela, assim como as linhas - eu não entendo o problema nisso, e por que não há conexão?
Você também diz que não há nenhuma implementação final de tais objetos, como você descreveu acima? (onde você descreveu?)
A oportunidade de um objeto global do mouse é, pelo menos em minha GUI, salvar qualquer informação sobre o mouse (posição, posição de imprensa, preço da posição etc.) acessível para cada classe que lida também com informações. Além disso, o objeto do mouse guarda informações sobre o uso exclusivo do mouse, por exemplo, ao arrastá-lo. Isso economiza muito tempo da CPU enquanto algo é arrastado ou está prestes a ser clicado, etc.
Por último, mas não menos importante: Nada da biblioteca padrão funciona no testador de estratégias quando usado em EAs porque não há eventos com o mouse. E se você quiser implementar o suporte do mouse no testador de estratégia, você ficará grato por tal classe de mouse também, porque a classe não se importa de onde vem a informação sobre movimentos do mouse, mas os objetos que precisam da informação ainda sabem de onde devem procurar.
---
Não é apenas a classe entre CWnd e CObject I que está faltando, é na verdade mais o objeto mestre/contentor que está faltando, que contém objetos baseados em pixels, assim como objetos baseados em tempo/preço. Como você também mencionou, todos eles são objetos do gráfico, portanto o mestre lógico deve ser um objeto que represente o gráfico e que contenha todos os objetos. E para realizar isto, deve haver uma classe entre CWnd e CObject.
O pano de fundo para esta idéia não é apenas a lógica, é também uma questão de desempenho. No meu caso, quando o gráfico muda de alguma forma, o objeto mestre detecta isto, ele loops todos os objetos contidos que podem ser recipientes de linhas, recipientes do CWnd, bem como quaisquer objetos individuais de qualquer um destes tipos, e "informa" qualquer objeto que queira ser informado por isso. Isto significa apenas que há um único laço em exatamente um ponto do código, e devido ao uso com containers e sub containers, isto é extremamente eficiente.
Eu também uso este mestre para congelar todos os objetos de uma vez e para evitar qualquer atualização física por apenas uma linha de código. A diferença no desempenho é drástica. Exemplo: Quando crio todos os objetos visuais que preciso para minha EA, e em alguns casos as teses são mais de 1000, congelo este objeto mestre antecipadamente, crio os outros objetos e o "descongelo" depois, o que resulta em uma atualização física do gráfico. Sem congelamento, este processo pode levar um minuto inteiro. Com o congelamento, são menos de 2 segundos.
Antes de começar a criar a GUI sozinho, eu realmente o experimentei com as bibliotecas padrão. Mais tarde, tentei manter pelo menos algumas partes. Mas o problema era que era simplesmente impossível perceber o que eu tinha em mente por causa de uma implementação incompleta e de uma arquitetura que é meio que ... Vamos fazer algo que funcione de alguma forma para nós não sabermos. O desempenho visual é alcançado com uma hierarquia clara, mas as bibliotecas padrão são de alguma forma anárquicas.
De qualquer forma, não sou a primeira pessoa a reconhecer isto. E, como Alain já mencionou, não tenho certeza se isto realmente ajuda, porque é muito teórico. Posso apenas falar sobre minha experiência com todas essas coisas que não se baseiam apenas no MQL, mas meu opionion é, no entanto, apenas minha opinião e, claro, não a lei.
Mas para o segundo tipo, o modo de pensar e as considerações aqui discutidas são muito valiosos e muito práticos também. É claro que um artigo seria melhor, mas mesmo assim.
Não acho que as pessoas construirão estruturas depois de ler apenas este tópico, mas ainda assim ele tem bons pedaços de informação e insights, o que parece faltar até mesmo para as pessoas que já construíram estruturas MQL públicas.
Portanto, para o mouse e o testador, se eu acertei você usa o ::OnTester() para chamar seu mouse em vez de uma entrada do usuário, se eu o seguir.
Mais uma vez obrigado, Doerk.
A oportunidade de um objeto global do mouse é, pelo menos em minha GUI, salvar qualquer informação sobre o mouse (posição, posição de imprensa, preço da posição etc.) acessível para cada classe que lida também com informações. Além disso, o objeto do mouse guarda informações sobre o uso exclusivo do mouse, por exemplo, ao arrastá-lo. Isso economiza muito tempo da CPU enquanto algo é arrastado ou está prestes a ser clicado, etc.
Por último, mas não menos importante: Nada da biblioteca padrão funciona no testador de estratégias quando usado em EAs, porque não há eventos do mouse. E se você quiser implementar o suporte do mouse no testador de estratégias, você ficará grato por tal classe de mouse também, porque a classe não se importa de onde vem a informação sobre movimentos do mouse, mas os objetos que precisam da informação ainda sabem de onde devem procurar.
Ou está me faltando algo?
O objeto do mouse não se parece se estiver sobre um objeto ou se estiver em uso por um objeto no momento, isto é feito pelos próprios objetos. Mas o objeto do mouse é o "lugar" central onde tais informações podem ser armazenadas.
As classes de controle padrão funcionam assim, que em cada movimento do mouse todos os objetos são em loop para descobrir, se este movimento tem algo a ver com eles, isto leva muito tempo de CPU que pode ser visto facilmente quando você inicia o gerenciador de tarefas e apenas move o mouse quando EA ou Indicador é carregado e um objeto CDialog é parte da EA ou indicador. Quanto mais complexo o diálogo, maior é o uso da CPU.
Em minha GUI, com a existência de um objeto global do mouse, isto é feito de forma diferente. Você pode ter 10000 objetos e o uso da CPU não cresce em nada quando o mouse é movido. É feito dessa forma, que somente assim que o botão do mouse desce sobre um objeto específico, este objeto específico informa o objeto do mouse, que ele tem o foco, e assim que o mouse se move após este evento de botão para baixo, nenhum outro objeto precisa cuidar dele, e qualquer movimento adicional do mouse / qualquer outro evento de movimento do mouse é direcionado diretamente para o objeto que tem o foco - que é sempre exclusivo - usando seu ponteiro.
E devido à circunstância de que todos os objetos gráficos, não importa se são baseados em tempo/preço (linhas de tendência etc.) ou em coordenadas de pixels (painéis etc.) têm uma classe base comum, todos esses objetos podem usar um conjunto comum de funções sobrecarregadas para lidar com isso. Esta é também uma razão pela qual mencionei que falta uma classe entre CWnd e CObject, porque esta classe base entre é a mesma classe base que é usada pelos objetos baseados em tempo/preço também e somente isto torna possível comunicar efetivamente e lidar com tais eventos de forma eficaz.
Sim.
No entanto, tenho a opção de capturar qualquer movimento se clicado ou não, e também com melhor desempenho da CPU e sem usar os nomes dos objetos, mas essa não foi a questão aqui.