Discussão do artigo "Melhore os gráficos de negociação com uma interface gráfica interativa baseada em MQL5 (Parte III): Interface de negociação simples e móvel"
Olá, Kalish,
A abordagem interessante e parabéns por terminar sua série. A codificação OnEvent é o que faz tudo acontecer! Como seu primeiro artigo me deixou empolgado, desenvolvi minha própria versão do painel móvel. É uma classe base que é herdada por classes individuais para cada tipo de painel.Em segundo lugar, como eu já havia criado um arquivo de cabeçalho de controles baseado nos exemplos do arquivo de ajuda do MQL, optei por usá-lo em vez de criar uma classe Text para herança, e funcionou bem. Estou planejando criar mais dois métodos para a classe GUI, Save e Initialize. Save lerá e atualizará um arquivo CSV e definirá as posições e os dados do local inicial. Initialize lerá o arquivo CSV e definirá as posições iniciais.
Para sua análise, estou anexando uma captura de tela dos títulos atuais do meu EA e dois painéis: o primeiro é o Active Orders que usarei e o Sample é a versão básica usada como modelo para painéis adicionais.
Boa sorte em seus futuros empreendimentos, estarei observando
Cape Coddah
O artigo foi muito bom. Bem didático e explicado. Gostei muito. 😁👍
Para sua análise, estou anexando uma captura de tela dos títulos atuais do meu EA e dois painéis: o primeiro é o Active Orders que usarei e o Sample é a versão básica usada como modelo para painéis adicionais.
Boa sorte em seus futuros empreendimentos, estarei observando
Cape Coddah
Fico feliz que esteja se beneficiando com meus artigos.
Na verdade, você me motivou a escrever esta parte 3; caso contrário, teria levado mais tempo devido à falta de motivação.
Muito obrigado por isso.
Boa sorte para você também em seus empreendimentos futuros.
Oi Kailash,
Espero que você monitore este artigo, pois não sei como enviar textos privados.
De qualquer forma, eu realmente incorporei seus conceitos em uma maneira muito melhor de organizar um EA. Aqui está uma captura de tela da minha versão antiga e uma que usa seu conceito de painel móvel usando seus conceitos da parte 2 com vários filhos. Embora ainda esteja no estágio de desenvolvimento preliminar, isso me permitirá exibir dados mais pertinentes durante o teste do modelo.
No momento, tenho uma classe filha separada para cada painel, incluindo o Controller.
clsGUI GUI; clsAO AO; clsBOB BOB; clsCTL CTL; clsXO XO; clsATR ATR; clsRSI RSI; clsMM MM; clsTS TS; //clsAO Guis[egElements]; //clsGui GuiS[egElements]; //objeto Guis[egElements];
Embora essa abordagem seja adequada, ela leva a muitas funções separadas para lidar com várias tarefas nos painéis do EA. Uma abordagem melhor seria ter uma matriz dos filhos e usá-la como parâmetro nas chamadas de funções reduzidas. Tentei usar as duas primeiras abordagens, mas não consigo converter os elementos da matriz na classe filha apropriada para chamar suas funções públicas exclusivas.Tive sucesso limitado no acesso a variáveis públicas usando uma classe de cobertura com a declaração de objeto. Essa abordagem parece usar a definição de classe dos elementos do elemento de parâmetro em vez da definição de classe da matriz.
int Wrapper(object &theobject){ return(theobject.aninteger): } int i=Wrapper(Guis[5]);
Essa abordagem não funciona para Guis[5].Create_Controls(......);
A única abordagem que vi que funciona é usar c_array para criar uma matriz de ponteiros de objeto e adicioná-los à matriz e, em seguida, acessá-la por uma função que chama a função c_array AT(location) para atribuir o ponteiro da matriz a um ponteiro local do objeto declarado localmente para acessar as variáveis filho localmente.
Você ou alguém sabe como resolver esse problema ou fornecer uma referência a artigos ou documentação sobre MQL que abordem uma matriz de classes filhas em vez de uma matriz de uma classe?
Muito obrigado e aguardo ansiosamente seus próximos artigos
CapeCoddah
Um bom exemplo de uso de OOP pelo simples fato de ser OOP.
Acabou sendo complicado e não conveniente (IMHO). Mas funciona, o que já é bom :)
Você deve adicionar OBJPROP_ZORDER, caso contrário, os botões serão pressionados de vez em quando.
void Button::Create(string name, int xDis = 0, int yDis = 0, int xSize = 0, int ySize = 0) { ObjectCreate(0, name, OBJ_BUTTON, 0, 0, 0); ObjectSetInteger(0, name, OBJPROP_XDISTANCE, xDis); ObjectSetInteger(0, name, OBJPROP_YDISTANCE, yDis); ObjectSetInteger(0, name, OBJPROP_XSIZE, xSize); ObjectSetInteger(0, name, OBJPROP_YSIZE, ySize); ObjectSetInteger(0, name, OBJPROP_ZORDER, 1); _name = name; } //+------------------------------------------------------------------+
Acabou sendo incômodo e não conveniente (IMHO). Mas funciona, o que já é bom :)
Você precisa adicionar OBJPROP_ZORDER, caso contrário, os botões serão pressionados de vez em quando.
Isso não é OOP de forma alguma. Esses são métodos de terminal recobertos por classes.
Se um programador quiser criar uma GUI diferente (http sofisticado, via WebSocket, abordado em outros artigos), ele não poderá fazer nada. Ele simplesmente jogará fora todo o código do artigo e escreverá outro.
Para alterar radicalmente a parte visual, mas no mesmo ObjectCreate(xx), você terá de reescrever tudo.
Ou como desativar a GUI para que ela não ocupe a CPU no VDS-ka.
Onde está a reutilização? Por que a GUI está intercalada com outros códigos... Não podemos nem falar de estilos, pelo menos de cores.
Usando as bibliotecas do artigo, o código de um EA típico ficou mais curto? Mas de jeito nenhum, ele não foi escrito para isso :-)
não é OOP de forma alguma. Esses são métodos de terminal recobertos por classes.
Se um programador quiser criar uma GUI diferente (http sofisticado, via WebSocket, abordado em outros artigos), ele não poderá fazer nada. Ele simplesmente jogará fora todo o código do artigo e escreverá outro.
Para mudar radicalmente a parte visual, mas no mesmo ObjectCreate(xx), você ainda terá que reescrever tudo.
ou como desativar a GUI para que ela não ocupe a CPU no VDS-ka
Onde está a reutilização? Por que a GUI está intercalada com outros códigos... Não podemos nem falar de estilos, pelo menos de cores.
Usando as bibliotecas do artigo, o código de um EA típico ficou mais curto? Mas de jeito nenhum, ele não foi escrito para isso :-)
Bem, acho que não é muito correto discutir cores aqui.
Mas o fato de os botões de compra e venda serem colocados ao contrário pode induzir o usuário ao erro.
Não está claro por que a GUI deve ser desativada se for um painel para negociação manual. No entanto, se não for um painel de negociação, mas um painel informativo, então, sim, é melhor considerar desativá-lo.
Gosto da forma como as funções RectangleLabel::OnEvent e RectangleLabel::Add estão organizadas, é bonita, clara e legível.
Utilizei o mesmo princípio em meus painéis, mas meu código era um pouco fraco, ou algo assim. Em geral, não era bonito. Então, decidi usar o código do artigo em um novo painel.
O painel acabou ficando pronto, mas gastei mais tempo com ele do que se o tivesse escrito do zero.
Em geral, a conclusão é a seguinte: o artigo é interessante e útil, mas o código do artigo é parcialmente mal planejado.
Bem, discutindo cores, não acho que seja correto discutir cores aqui.
Mas o fato de os botões de compra e venda serem colocados ao contrário pode induzir o usuário ao erro.
Não está claro por que a GUI deve ser desativada se for um painel para negociação manual. No entanto, se não for um painel de negociação, mas um painel informativo, então, sim, é melhor considerar desativá-lo.
Gosto da forma como as funções RectangleLabel::OnEvent e RectangleLabel::Add estão organizadas, elas são bonitas, claras e legíveis.
Utilizei o mesmo princípio em meus painéis, mas meu código era um pouco fraco, ou algo assim. Em geral, não era bonito. Então, decidi usar o código do artigo para um novo painel.
No final, consegui o painel, mas gastei mais tempo com ele do que se o tivesse escrito do zero.
Em geral, a conclusão é a seguinte: o artigo é interessante e útil, mas o código do artigo é parcialmente mal pensado.
Há muitos métodos bem pensados com belas setas "como implementar a interface do usuário de modo que não seja doloroso" :-) MVC e similares. Portanto, o front-end (win, gtk, qt, web) às vezes pode ser alterado com um leve movimento da mão.
Nenhum deles foi implementado em MQL. Tudo é pregado, pior que o TurboVision - embora existam classes do Adam, mas há modelos lá.
Há anos que as pessoas escrevem sobre "fácil e simples" e "interface simples", mas é exatamente o mesmo que neste artigo. Um monte de código que não facilita nada. O único efeito é um bônus na conta do autor.
- 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 Melhore os gráficos de negociação com uma interface gráfica interativa baseada em MQL5 (Parte III): Interface de negociação simples e móvel foi publicado:
Nesta série de artigos, exploramos a integração de interfaces gráficas interativas em painéis de negociação móveis no MQL5. Na terceira parte, usamos os desenvolvimentos das partes anteriores para transformar painéis de negociação estáticos em dinâmicos.
Para começar, vamos relembrar o que examinamos nas duas partes anteriores:
Na terceira parte, nos concentraremos em aprimorar nossos painéis através da integração de interfaces gráficas. Sem uma interface gráfica, os painéis não servirão ao propósito pretendido.
Autor: Kailash Bai Mina