como criar objetos de forma dinâmica? (Algumas coisas do OOP) - página 4
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
Absolutamente. Levei meses para criar minha própria estrutura GUI com MQL, não calculando a experiência que eu já tinha do passado criando bibliotecas como estas. A parte mais difícil não são os eventos, é mais a arquitetura e a quase impossibilidade de depurar o código, por causa de todos os ninhos e recursões, mas também por causa dos estados do mouse que já ficam inválidos quando a depuração começa.
A propósito, ofereci uma colaboração à MQ com estas bibliotecas meses atrás e infelizmente nem sequer obtive uma resposta. Mas o fato é que a biblioteca de controle padrão é apenas uma boa, mas também uma má tentativa em comparação com o que é realmente possível. Pode-se fazer muito melhor. Talvez eu devesse oferecer a biblioteca no mercado aqui, mas estou assustando o bando de trabalho para escrever toda a documentação para ela.
Não há dúvida alguma. O OOP é baseado nos prinicipais da natureza. A terra não o alimenta, ela apenas fornece os recursos e depende de você se, quando e onde você precisa do quê.
Você quer dizer, ao criar uma estrutura, apenas se preocupar em fornecer os recursos? Entendo isso, mas de alguma forma tenho dificuldade de praticar porque minha tendência é muito forte.
Por exemplo, se eu criar uma estrutura e agora criar o botão e o botão de rádio que é uma espécie de contentor de botão - quando eu venho a criar o radiobutão, minha tendência é pensar no objeto dependente, o botão neste caso, e como eu me comunico com ele. É um hábito de programação de procedimentos, eu me pergunto se você fez a mudança em algum momento de seu passado de procedimento para OO e você pode me indicar uma visão clara do que eu preciso para me concentrar neste caso. Porque eu tendo a me concentrar mais no botão (objeto dependente) do que no radiobutton.
Não tenho certeza se deixei claro, é apenas uma questão de apontar as coisas importantes em que devo me concentrar ao criar um nível em uma estrutura.
Você pode dizer o que você quer dizer com isso? Eu tenho a sensação geral do que você diz, mas não muito clara.
Você quer dizer, ao criar uma estrutura, apenas se preocupar em fornecer os recursos? Entendo isso, mas de alguma forma tenho dificuldade de praticar porque minha tendência é muito forte.
Por exemplo, se eu criar uma estrutura e agora criar o botão e o botão de rádio que é uma espécie de contentor de botão - quando eu venho a criar o radiobutão, minha tendência é pensar no objeto dependente, o botão neste caso, e como eu me comunico com ele. É um hábito de programação de procedimentos, eu me pergunto se você fez a mudança em algum momento de seu passado de procedimento para OO e pode me indicar uma visão clara do que eu preciso para me concentrar neste caso. Porque eu tendo a me concentrar mais no botão (objeto dependente) do que no radiobutton.
Não tenho certeza se deixei claro, é apenas uma questão de apontar as coisas importantes em que devo me concentrar ao criar um nível em uma estrutura.
Talvez eu não tenha percebido o ponto, mas gostaria de dar minha opinião.
Acho que você está muito na "teoria", e esperando a luz de outra pessoa. Não há uma solução perfeita, há soluções e você precisa encontrá-la a partir de sua experiência e de suas necessidades concretas.
Este tópico partiu de um caso prático, e sabe que se tornou uma discussão obscura sobre o OOP. Há uma série interessante de artigos sobre GUI, você deve dar uma olhada, depois tentar construir uma interface usando a Biblioteca Padrão, e usando a biblioteca a partir destes artigos, e estudar o código... ou não.
Apenas uma sugestão, pois realmente não vejo como você poderia ser ajudado muito melhor.
Talvez eu não tenha percebido o ponto, mas gostaria de dar minha opinião.
Acho que você está muito na "teoria", e esperando a luz de outra pessoa. Não há uma solução perfeita, há soluções e você precisa encontrá-la a partir de sua experiência e de suas necessidades concretas.
Este tópico partiu de um caso prático, e sabe que se tornou uma discussão obscura sobre o OOP. Há uma série interessante de artigos sobre GUI, você deve dar uma olhada, depois tentar construir uma interface usando a Biblioteca Padrão, e usando a biblioteca a partir destes artigos, e estudar o código... ou não.
Apenas uma sugestão, pois realmente não vejo como você poderia ser ajudado muito melhor.
Alain, eu construí uma interface e li os artigos.
Talvez não seja o lugar para discutir OO, talvez você esteja certo.
Comecei a discuti-lo porque Doerk apresentou o tópico como resposta ao tópico iniciante e falou sobre a abordagem correta de OO.
O próprio iniciante do tópico estava interessado na apresentação de Doerk OO, e eu acho natural discutir isso aqui.
Embora você possa estar certo de que talvez seja muito teórico, ainda assim minha opinião é que o OO correto não pode sem envolver alguma teoria e, no final, torna-se prático.
Minha dificuldade é OO pensamento correto, eu só me perguntava se por acaso Doerk poderia saber de sua experiência a dificuldade mental que eu apresentei.
Há uma série interessante de artigos sobre GUI, você deve dar uma olhada, depois tentar construir uma interface usando a Biblioteca Padrão, e usando a biblioteca a partir destes artigos, e estudar o código... ou não.
Acabei de baixá-lo para ver o que ele faz. E a primeira impressão mostra, que eles fizeram os mesmos erros ruins que fizeram com a Biblioteca de Controle Padrão. Já o primeiro exemplo com uma única janela de diálogo eleva o uso da CPU de 10% (sem) para 50-65% (carregada). Esta já é a melhor prova de que os autores não têm a experiência necessária para desenvolver tal biblioteca e que esta não pode ser - uma - forma de fazê-lo corretamente.
Eu não entendo de qualquer forma porque a MQ não fornece uma estrutura profissional de GUI em vez de explicar como ela (não) é feita. A maioria dos programadores da MQL certamente quer desenvolver EAs e Indicadores, mas não quer se preocupar com tais coisas.
Além disso, o painel de seu exemplo está morto no testador de estratégia, e é aqui que todas essas coisas de GUI ficam absurdas de qualquer forma. Isto não é uma crítica contra você ou contra o que você escreveu, eu mesmo sei que simplesmente não há melhor material público disponível para a MQL aqui.
Alain, eu construí uma interface e li os artigos.
Talvez não seja o lugar para discutir OO, talvez você esteja certo.
Comecei a discuti-lo porque Doerk apresentou o tópico como resposta ao tópico iniciante e falou sobre a abordagem OO correta.
O próprio iniciante do tópico estava interessado na apresentação de Doerk OO, e eu acho natural discutir isso aqui.
Embora você possa estar certo de que talvez seja muito teórico, ainda assim minha opinião é que o OO correto não pode sem envolver alguma teoria e, no final, torna-se prático.
Minha dificuldade é OO pensamento correto, eu só me perguntava se por acaso Doerk poderia saber de sua experiência a dificuldade mental que eu apresentei.
Não há nenhum problema para discutir aqui o OOP.
Não concordo com seu "OO não pode sem envolver alguma teoria", mas isso não importa.
Não há nenhum problema para discutir aqui o OOP.
Eu não concordo com seu "OO não pode sem envolver alguma teoria", mas isso não importa.
Acabei de baixá-lo para ver o que ele faz. E a primeira impressão mostra, que eles fizeram os mesmos erros ruins que fizeram com a Biblioteca de Controle Padrão. Já o primeiro exemplo com uma única janela de diálogo eleva o uso da CPU de 10% (sem) para 50-65% (carregada). Esta já é a melhor prova de que os autores não têm a experiência necessária para desenvolver tal biblioteca e que esta não pode ser - uma - forma de fazê-lo corretamente.
Eu não entendo de qualquer forma porque a MQ não fornece uma estrutura profissional de GUI em vez de explicar como ela (não) é feita. A maioria dos programadores da MQL certamente quer desenvolver EAs e Indicadores, mas não quer se preocupar com tais coisas.
Além disso, o painel de seu exemplo está morto no testador de estratégia, e é aqui que todas essas coisas de GUI ficam absurdas de qualquer forma. Isto não é uma crítica contra você ou contra o que você escreveu, eu mesmo sei que simplesmente não há melhor material público disponível para a MQL aqui.
Doerk, você provavelmente tem razão, mas não é isso que eu quero dizer.
Você deveria escrever um exemplo concreto do porquê desta questão da CPU, explicar à Anatoli (autora dos artigos) qual é o problema. Lamento dizer que, até agora, tudo o que você disse é quase inútil, mesmo que você esteja 100% certo. É apenas muito geral e teórico. Sem ofensa.
O problema é que esta questão é muito complexa para dar instruções exatas. E é por isso que estou tentando fornecer algumas idéias e maneiras possíveis para aqueles que estão interessados. Infelizmente, não tenho tempo para escrever um artigo nem para publicar uma biblioteca totalmente documentada. Desculpe.