Erros, bugs, perguntas - página 527

 
Swan:

View-Tools-Experts.

A divisão por zero é um erro crítico. Os programas mql recusam-se categoricamente a fazer isto)

se não o entender, pode fazer algo do género:

Mostrei que a divisão por zero só ocorre num caso particular, este zero não deveria existir, e não existe se se tomar o divisor e o divisível separadamente, isto é o que não é claro,

OK, obrigado por isso, eu próprio analisarei o assunto. Talvez haja alguma verdade na sua resposta, obrigado mais uma vez.

 
Im_hungry:

Infelizmente, é preciso tempo para entrar nela. E tempo é dinheiro.

O problema não se resolverá por si só,

Existe um conceito de ajuda desinteressada. Em mql4.com e noutras circunstâncias, também ajudo de vez em quando, se puder. Poderia simplesmente ter ficado calado.
 
Olegts:
Existe algo como ajuda desinteressada, em mql4.com e noutras circunstâncias, por vezes também ajudo se puder. Poderia simplesmente ter ficado calado.
Mútuo, meu amigo - mútuo.
 
papaklass:

É suposto ser assim?

Uma posição é fechada, e o pedido PositionGetDouble(POSITION_PRICE_OPEN) devolve o valor da posição fechada. Até que uma nova posição seja aberta, o valor da posição antiga (já fechada) não é alterado. É suposto ser assim?

Deixem-me ver se percebi bem isto. A consulta PositionGetDouble(POSITION_PRICE_OPEN) é feita após a consulta de disponibilidade de posição?
 

ponto interessante, isto é

para evitar isto, utilizo o seguinte

double open = 0.0;
if (PositionSelect(Symbol_1))
 {
  open = PositionGetDouble(POSITION_PRICE_OPEN);
 }

e será zero, como desejado.

 
papaklass:

Pedir PosiçõesTotal() = 0. Agora faço uma consulta PositionGetDouble(POSITION_PRICE_OPEN) e obtenho em resposta o preço de abertura de uma posição já fechada. Idealmente, deveria obter zero, uma vez que não há nenhuma posição aberta. Sim, depois de solicitar sobre a existência da posição.

Na minha opinião, tudo está dentro das regras:

A função PositionSelect() copia os dados de posição para o ambiente de software, e chamadas subsequentes para PositionGetDouble(), PositionGetInteger() e PositionGetString() devolvem os dados previamente copiados. Isto significa que a posição em si pode já não existir (ou pode ter mudado em volume, direcção, etc.), mas os dados desta posição ainda podem ser recuperados. A fim de garantir a recepção de novos dados de posição, recomenda-se chamar a função PositionSelect() imediatamente antes de os chamar.

Contudo, não compreendo porque é que os dados da posição devem ser solicitados se a selecção da posição falhar. Mas não importa.

 

Caros programadores. Não o tome como uma imposição, tenho uma pergunta: o que pensa da possibilidade de cancelar uma ordem pendente se o preço tiver atingido um valor?

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
Diubakin:

Após a actualização para Build 507, estou a ter dois problemas no testador:

1. Durante a optimização ao trocar as tabulações de teste, o terminal ocasionalmente (nem sempre) trava;

2. Se uma enumeração foi seleccionada como parâmetro optimizado, então ao tentar executar um dos resultados da optimização, o Expert Advisor não vê o valor desta enumeração, ou seja, é sempre igual a zero.

Parece que encontrámos um problema com as enumerações durante a optimização e as falhas do terminal. Terá de esperar pela próxima construção.
 
stringo:
Parece ter encontrado um problema com a enumeração durante a optimização e o abandono do terminal. Terá de esperar pela próxima construção.

Óptimo. Não se consegue reproduzir o problema com agentes remotos pendurados?
Já me cansei deles. Raramente se consegue uma optimização sem congelação.
Tenho de desligar os agentes congelados, depois ligá-los e assim sucessivamente até ao próximo congelamento.
E depende tanto de agentes que estão na rede local como de agentes nebulosos (menos frequentemente).

 
crOss:

Isso é óptimo. Não se consegue reproduzir o problema com os agentes remotos desligados?
Estou a ficar farto e cansado deles. Raramente se consegue uma optimização sem congelação.
Tenho de desligar os agentes pendurados, depois ligá-los e assim sucessivamente até ao próximo enforcamento.
E depende tanto de agentes que estão na rede local como de agentes nebulosos (menos frequentemente).

Muitas coisas foram corrigidas nos agentes. E não tem de esperar pela próxima construção. Tem de esperar que os agentes remotos actualizem para a construção actualmente lançada