Thread: Como preservar a vari�vel no indicador ao alternar timeframes?

1. Acabei de receber uma MP com a seguinte pergunta:

Programando um indior personalizado, como posso preservar o valor de uma vari�vel ao alterar o timeframe? Eu tentei v�rias varia��es usando GlobalVariableSet/Get e deinit(). Nenhum deles deu certo. Voc� tem alguma ideia?

Eu n�o sei a resposta. Algu�m pode ajudar?


2. Al�m disso, algu�m sabe como recuperar o nome da fonte usada em um objeto.

Por exemplo, � poss�vel recuperar o tamanho da fonte usando ObjectGet(object_name,OBJPROP_FONTSIZE)

Mas n�o parece haver nenhuma maneira de recuperar o nome da fonte (Arial, Verdana, etc).

Mais uma vez, algu�m pode ajudar?

Muito obrigado,
Davi

Sim, entendo sua inten��o (ainda preciso entender sua sugest�o). S� uma pergunta: O que aconteceria se tiv�ssemos 3 gr�ficos, o EA anexado em cada um, todos do mesmo par. O Mt4 trava e � reiniciado. Agora os 3 EAs tentam encontrar seu pedido (um EA controla apenas 1 pedido que � identificado por um MagicNumber �nico). Com sua solu��o, todos os 3 EAs encontrariam seu pedido? Ou o primeiro EA pegaria o primeiro pedido e o gerenciaria com os valores armazenados (em GlobalVariables ou em um arquivo) e ent�o esse pedido seria bloqueado para...

aqui est� a coisa .... se voc� est� abrindo um novo gr�fico, ent�o esse gr�fico realmente n�o TEM uma ordem que 'pertence' a ele, nem a ordem que estava anteriormente 'vinculada a um gr�fico' est� mais vinculada a qualquer gr�fico. n�o importa se o gr�fico foi previamente configurado com 500 indiors e com uma egy espec�fica em mente para a ordem que estava sendo gerenciada nele, porque uma vez que o gr�fico � fechado, tudo desaparece. abrir um novo gr�fico come�a do zero! portanto, qualquer pedido que n�o esteja sendo gerenciado � um jogo tecnicamente gratuito para qualquer novo EA come�ar a gerenciar. minha 'solu��o' seria apenas para quando n�o estiver no gr�fico um objeto que j� forne�a o n�mero m�gico/ordem. se n�o houver objeto, o gr�fico provavelmente � novo. quanto a qual gr�fico adquire qual ordem, conforme acima, n�o importa qual ordem eles pegam. eles s�o todos justos nesse ponto. como eu disse em meu �ltimo post, eu estava pensando nas linhas do EA voltando exatamente como as ordens 'furtivas' foram configuradas antes do fechamento do gr�fico antigo, em vez de o usu�rio ter que inserir n�meros m�gicos e mover stoplinhas tp ao redor e coloque tudo de volta no lugar. editar: a �nica coisa que n�o tenho certeza � o qu�o thread-safe tudo isso �. se mt4 pula pelo local antes de terminar uma chamada para iniciar em um EA, isso � tudo em v�o.

meu entendimento � que seu gerente 'stealth' EA faz apenas ordens de mercado e n�o envia paradas ou takeprofits para o servidor. se o gr�fico foi fechado por engano, o usu�rio ter� que redefinir esses valores manualmente ap�s abrir o gr�fico e reiniciar o EA. do meu jeito eles n�o fariam. ele simplesmente se levantaria de onde estava e continuaria. isso � onde eu estava indo com ele.

Sim, entendo sua inten��o (ainda preciso entender sua sugest�o). S� uma pergunta: O que aconteceria se tiv�ssemos 3 gr�ficos, o EA anexado em cada um, todos do mesmo par. O Mt4 trava e � reiniciado. Agora os 3 EAs tentam encontrar seu pedido (um EA controla apenas 1 pedido que � identificado por um MagicNumber �nico). Com sua solu��o, todos os 3 EAs encontrariam seu pedido? Ou o primeiro EA pegaria o primeiro pedido e o gerenciaria com os valores armazenados (em GlobalVariables ou em um arquivo) e ent�o esse pedido seria bloqueado para os outros 2 EAs e o segundo EA encontraria um dos pedidos ativos restantes e ent�o o terceiro EA no terceiro gr�fico n�o teria acesso aos 2 pedidos bloqueados e pegaria o �ltimo e tudo ficaria bem? Se for esse o caso, voc� tem uma solu��o que outros n�o encontramos.

Desculpe, . Quando um gr�fico � fechado, meu EA est� limpando todas as GlobalVariables porque n�o adianta gerenciar algo em um gr�fico fechado = n�o h� ordem para gerenciar, caso contr�rio o gr�fico n�o seria fechado. Ele n�o fecha sozinho, o usu�rio tem um motivo para fech�-lo. Se houver uma ordem ativa que foi iniciada e controlada naquele gr�fico que agora est� fechado, a ordem ainda existe e pode ser identificada por seu MagicNumber. Assim, caso o usu�rio sinta a necessidade de anexar o EA a um novo gr�fico daquele par, a fim de obter o...

bem, nesse caso, foda-se. derrubar um objeto. os globais... eu s� estava dizendo para ter globais como um sinalizador que pode ser testado. � apenas algu�m levantando a m�o constantemente para dizer que ainda est� vivo, e se voc� empurrar a m�o para baixo e ela permanecer abaixada, ent�o voc� sabe que eles n�o est�o vivos e voc� deve assumir esse trabalho. o que eu estava falando era realmente acompanhar quais pedidos precisam ser gerenciados no caso de algo dar errado, como o gr�fico sendo fechado por engano. nessa situa��o, ele pode readquirir automaticamente o pedido que deve ser gerenciado e manter o transporte por caminh�o. meu entendimento � que seu gerente 'stealth' EA faz apenas ordens de mercado e n�o envia paradas ou takeprofits para o servidor. se o gr�fico foi fechado por engano, o usu�rio ter� que redefinir esses valores manualmente ap�s abrir o gr�fico e reiniciar o EA. do meu jeito eles n�o fariam. ele simplesmente se levantaria de onde estava e continuaria. isso � onde eu estava indo com ele.

voc� est� esquecendo a parte sobre 'e se o gr�fico estiver fechado'. os EAs precisam individualmente readquirir um com�rcio adequadamente n�o tratado e partir da�, o que eu suspeito que meu �ltimo post resolva.

Desculpe, . Quando um gr�fico � fechado, meu EA est� limpando todas as GlobalVariables porque n�o adianta gerenciar algo em um gr�fico fechado = n�o h� ordem para gerenciar, caso contr�rio o gr�fico n�o seria fechado. Ele n�o fecha sozinho, o usu�rio tem um motivo para fech�-lo. Se houver uma ordem ativa que foi iniciada e controlada naquele gr�fico que agora est� fechado, a ordem ainda existe e pode ser identificada por seu MagicNumber. Assim, caso o usu�rio sinta a necessidade de anexar o EA a um novo gr�fico daquele par, a fim de obter novamente a ordem gerenciada pelo EA, ele insere o MagicNumber no par�metro e define o bool Use automatic MagicNumber = false. Em seguida, o EA assume o controle com o MagicNumber adequado, marca o gr�fico novamente e redesenha as linhas de ordem de acordo com as configura��es do EA.

A �nica solu��o atualmente conhecida � marcar o gr�fico com o n�mero do ticket ou n�mero m�gico por meio de objetos do gr�fico. Qualquer pessoa que escreva um gerente comercial gen�rico e flex�vel provavelmente se deparar� com esse problema. .

Obrigado, Xafod. Concordo. @, n�o sei se sua sugest�o funcionaria. Parece muito cumprido para mim e prefiro usar o objeto gr�fico para vincular o EA ao gr�fico. � simples e um programador de hobby como eu pode lidar com isso.

Sobre o problema fxtr51 assumiu:

voc� est� esquecendo a parte sobre 'e se o gr�fico estiver fechado'. os EAs precisam individualmente readquirir um com�rcio adequadamente n�o tratado e partir da�, o que eu suspeito que meu �ltimo post resolva.

Sobre o problema, fxtr51 assumiu: digamos que voc� tenha 3 negocia��es abertas em 3 gr�ficos, todos no mesmo par/per�odo de tempo, mas sistemas de negocia��o diferentes, cada um sendo gerenciado por sua pr�pria inst�ncia de EA (o mesmo EA em cada gr�fico). Quando o MT4 � reiniciado, n�o h� como o EA saber qual negocia��o pertence a qual gr�fico. Na inicializa��o, o EA pode obter as informa��es salvas para as negocia��es (arquivo/globalvars/registro/qualquer coisa), mas ainda n�o sabe a qual dos 3 gr�ficos a negocia��o pertence, pois todos t�m o mesmo TF/Par/EA. O MT4 pode/ir� inicializar os gr�ficos na ordem que achar melhor. A �nica solu��o atualmente conhecida � marcar o gr�fico com o n�mero do ticket ou n�mero m�gico por meio de objetos do gr�fico. Qualquer pessoa que escreva um gerente comercial gen�rico e flex�vel provavelmente se deparar� com esse problema. Antes do rein�cio: Chart1: EU, M15, sistema RSI, TicketNr 10 Chart2: EU, M15, sistema CCI, TicketNr 20 Chart3: EU, M15, sistema Pivot, TicketNr 30 Ap�s o rein�cio: Chart?: EU, M15, ? sistema, Carta TicketNr 30?: EU, M15, ? sistema, TicketNr 10 Chart?: EU, M15, ? sistema, TicketNr 20 Solu��o: Marque cada gr�fico com um objeto gr�fico contendo o TicketNr/MagicNr.

Entendo (voc� esqueceu nossa discuss�o no meu t�pico, mas n�o tem problema, estou esquecendo as coisas tamb�m).

sim. a f�brica n�o fica comprometida com a mem�ria de longo prazo.

Meu EA atribui um novo MagicNumber automaticamente quando ele � anexado a um gr�fico. Isso � conveniente. Preciso de MagicNumbers exclusivos para controlar a ordem e as linhas de ordem no gr�fico e ter o MagicNumber atribu�do automaticamente me salva para verificar todos os MagicNumbers de negocia��es existentes. Agora imagine que eu troco de timeframe. MagicNumber nesse gr�fico � 2 . Ap�s a troca, o EA atribuiu a si mesmo MagicNumber = 3 porque � �nico. Ele apenas perdeu o controle sobre seu pr�prio pedido que tem MagicNumber = 2 . Isso � o que quero dizer com a EA est� ligada ao gr�fico. O EA deve preservar o MagicNumber da ordem que controla de alguma forma, caso contr�rio, ele atribuir� um novo MagicNumber exclusivo toda vez que executar a inicializa��o. A verifica��o de ordens ativas do par, ao qual o EA est� anexado, n�o ajuda se houver mais de 1 ordem para esse par. Como o EA deve saber qual ordem deve controlar? N�o encontra o MagicNumber que controlava antes do rein�cio e assim nunca saber� qual das 2 ou 4 ordens desse par deve gerir. Se...

ent�o o problema n�o � armazenar em arquivo... seu problema � decidir quem controla o qu� quando voc� abre um gr�fico. mastigue isso e veja o que sai do outro lado: se voc� atualizar uma de suas linhas ou o que quer que voc� fa�a com seu EA (eu s� tenho um vago conceito do que ele deve fazer), voc� atualiza o arquivo, ou melhor ainda, voc� pode faz�-lo enviar apenas as informa��es atualizadas para o arquivo um minuto ou o que for depois de fazer uma altera��o em algo desde a �ltima vez que voc� atualizou o arquivo. dessa forma, voc� est� definitivamente atualizando o arquivo em algum ponto, mas n�o imediatamente e, portanto, est� se dando tempo para fazer ajustes e tudo mais, em vez de debulhar o arquivo repetidamente toda vez que fizer algo. se voc� tiver um gr�fico cuidando de um pedido espec�fico, digite uma var global para o n�mero do pedido e defina o valor para algo como 10,0 a cada tick. quando voc� inicia um novo EA, tudo o que ele precisa fazer � encontrar todos os pedidos e definir a var global chaveada como zero ... espere dois ticks (apenas no caso de esta nova inst�ncia do EA de alguma forma conseguir executar antes de qualquer outro EA, e para que eles tenham a chance de atualizar os globais antes de voc� fazer o pr�ximo bit) e, em seguida, passar por todos os pedidos e descobrir quais t�m um var global definido com um valor menor que 5. qualquer coisa com um valor definido menor que 5 significa n�o outro EA atualizou a var global para um valor de 10 no tick anterior... ou seja, voc� encontrou um n�mero de pedido com o qual ningu�m parece se importar. se voc� encontrar um n�mero de pedido com o qual ningu�m se importa, verifique o arquivo para esse n�mero de pedido e, se estiver l�, extraia todos os outros dados relevantes, al�m de saber qual n�mero m�gico esse EA deve usar. se n�o houver pedidos para coleta, voc� far� o que fizer para atribuir automaticamente um n�mero m�gico para todos os pedidos iniciados nesse gr�fico. isso tudo pode ser uma besteira total, ou pode estar correto. eu n�o sei.

Eu obviamente estou perdendo alguma coisa. por que um arquivo n�o pode ser usado para um ea que est� 'vinculado a um gr�fico'?

Entendo (voc� esqueceu nossa discuss�o no meu t�pico, mas n�o tem problema, estou esquecendo as coisas tamb�m). Meu EA atribui um novo MagicNumber automaticamente quando ele � anexado a um gr�fico. Isso � conveniente. Preciso de MagicNumbers exclusivos para controlar a ordem e as linhas de ordem no gr�fico e ter o MagicNumber atribu�do automaticamente me salva para verificar todos os MagicNumbers de negocia��es existentes. Agora imagine que eu troco de timeframe. MagicNumber nesse gr�fico � 2 . Ap�s a troca, o EA atribuiu a si mesmo MagicNumber = 3 porque � �nico. Ele apenas perdeu o controle sobre seu pr�prio pedido que tem MagicNumber = 2 . Isso � o que quero dizer com a EA est� ligada ao gr�fico. O EA deve preservar o MagicNumber da ordem que controla de alguma forma, caso contr�rio, ele atribuir� um novo MagicNumber exclusivo toda vez que executar a inicializa��o. A verifica��o de ordens ativas do par, ao qual o EA est� anexado, n�o ajuda se houver mais de 1 ordem para esse par. Como o EA deve saber qual ordem deve controlar? N�o encontra o MagicNumber que controlava antes do rein�cio e assim nunca saber� qual das 2 ou 4 ordens desse par deve gerir. Se o EA gravar o MagicNumber em um arquivo, como isso deve ajudar? Haveria v�rios arquivos nos quais MagicNumbers foram gravados, mas como o EA poderia identificar de qual arquivo ele deveria ler? Isso exigiria diferentes vers�es do EA. EA-1 cria e l� arquivo-EA1, EA-2 cria e l� apenas arquivo-EA2. Para EAs que controlam v�rios pedidos, n�o h� problema. Eles n�o precisam de uma identifica��o �nica. Basta anex�-los a qualquer gr�fico e eles passar�o por todos os pedidos e far�o o que quiserem. Espero ter me expressado de forma compreens�vel. Claro que tamb�m tenho a op��o de um MagicNumber definido manualmente no meu EA. O usu�rio insere 3 no par�metro MagicNumber e quando ele alterna os timeframes ou Mt4 � reiniciado, o EA verifica MagicNumber = 3 e encontra todas as GlobalVariables que pertencem a MagicNumber = 3 e n�o h� absolutamente nenhum problema. O problema surge apenas para MagicNumbers exclusivos atribu�dos automaticamente.