Erros, bugs, perguntas - página 249

Novo comentário
 


alexluek:

Não houve perda de comunicação, o sobredesenho de carraças, e quanto maior for a TF, mais raro será.

E o método de cálculo desde a data inicial até à data final (descobri que são 3) sem

Provavelmente acontece (recalcula todas as barras), mas ainda não é exacto e não sei como o verificar.

mas é apenas um pensamento - vamos verificar...

Talvez haja outra abordagem para o evitar...


Yedelkin:

É claro que existe uma abordagem. Se(prev_calculated==0), efectuamos o cálculo inicial para todas as barras. Subsequentemente, para cada novo tick (se 0 < pré-cálculo < taxas_total) efectuamos cálculos como for(int i=prev_calculado-1;i< taxas_total;i++) apenas para as últimas barras aparecidas.


Ainda se retira. Implementado desta forma:


int calculado1=BarsCalculado(StdDev1Handle);

...................

if(CopyBuffer(StdDev1Handle,0,0,to_copy,ExtStdDev1Buffer)<to_copy)return(0);

......................

int data1=CopyOpen(Symbol1,0,0,rates_total,Open1Buffer);

.....................

for(int i=rates_total-2; i>=0; i--)
{
if(time[i]>=DateStart)

{


Então, não é, mas talvez se trate da correcção do trabalho do código

mas não no terminal (mas pelo menos não é tão distinto agora...)

As carraças ou nenhumas carraças podem ainda ser redesenhadas.

A impressão é que não há coerência (relação de causa-e-efeito).

A única coisa que me vem à mente é um processador fraco ou um desligamento

A única coisa que me vem à mente é um processador fraco ou um congelamento do terminal (MT5).

 

alexluek:

...................

Volta atrás e não o faz, mas é tudo uma questão de correcção de código

e não no terminal (pelo menos não é tão distinto agora...)

Por favor, envie um pedido para o serviço de recepção com o código-fonte, nós descobriremos.
 

Alguém já trabalhou com a segunda versão da função ChartGetInteger:

2. Возвращает true или false в зависимости от успешности выполнения функции.
В случае успеха значение свойства помещается в приемную переменную, 
передаваемую по ссылке последним параметром.

bool  ChartGetInteger(
   long    chart_id,        // идентификатор графика
   int     prop_id,         // идентификатор свойства
   int     sub_window,      // номер подокна
   long&   long_var         // сюда примем значение свойства
   );

? Parece que o valor do imóvel não é passado para a variável receptora. Pelo menos, este comportamento é notado quando se utiliza a construção

if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,windows))
A função retorna verdadeiro, mas as janelas da variável contêm o valor obtido durante a inicialização desta variável. Neste caso, a primeira versão da função produz um valor correcto. (E mais uma coisa trivial: se a variável de busca for declarada do tipo longo, o compilador gera um aviso).
 
Yedelkin:

Alguém já trabalhou com a segunda versão da função ChartGetInteger:

? Parece que o valor do imóvel não é passado para a variável receptora. Pelo menos, este comportamento é notado quando se utiliza a construção

A função retorna verdadeiro, mas as janelas da variável contêm o valor obtido durante a inicialização desta variável. Neste caso, a primeira versão da função produz um valor correcto. (E mais uma coisa trivial: se a variável de busca for declarada do tipo longo, o compilador gera um aviso).
Sim, existe tal coisa. Só eu estava a tentar pedir a cor de fundo. Eu queria escrever ao Servicedesk, mas esqueci-me.
 
Lizar:
Sim, existe tal coisa. Só eu tentei pedir a cor de fundo. Ia escrever para o Servicedesk, mas esqueci-me.
Está bem, eu vou.
 
Yedelkin:

Alguém já trabalhou com a segunda versão da função ChartGetInteger:

? Parece que o valor do imóvel não é passado para a variável receptora. Pelo menos este comportamento é observado quando se utiliza a construção

A função retorna verdadeiro, mas a variável de janelas receptoras contém o valor obtido durante a inicialização desta variável. Neste caso, a primeira versão da função produz o valor correcto. (E mais uma pequena coisa: se a variável receptora for declarada com o tipo longo, o compilador irá gerar um aviso).

Parece que está a usar uma função errada. Esta é a primeira variante da função (com três parâmetros). Não retorna verdadeiro (como você pensa), mas o valor do parâmetro

if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,windows))

Não vejo o seu código, mas parece estar correcto:

long Chart=0,windows;
if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,0,windows))
  {
   //--- всё плохо
  }
 
uncleVic:

Parece estar a usar a função errada. Esta é a primeira versão da função (com três parâmetros). Não retorna verdadeiro (como você pensa), mas o valor do parâmetro

Não vejo o seu código, mas parece estar correcto:

Hmmm..., sim, eu tinha exactamente este bug - olhei para o meu antigo código onde eu estava a tentar usar esta função.
 
uncleVic:

Parece estar a usar a função errada. Esta é a primeira versão da função (com três parâmetros). Não retorna verdadeiro (como você pensa), mas o valor do parâmetro

OK. Vamos analisar o assunto.

1. A função é usada "isso", porque se cita uma função com o mesmo nome que o seu exemplo. Só pode ser uma questão de qual versão dessa função (primeira ou segunda) está a ser utilizada.

2. De facto, formalmente, a primeira variante da função tem três parâmetros, enquanto que a segunda tem quatro. No entanto, na descrição do parâmetro sub_janela, que está presente em ambas as variantes da chamada, afirma-se claramente que "a maioria das propriedades não requer o número da subjanela". Levanta-se uma questão: é necessário ou não indicar o número da janela para bens como CHART_WINDOWS_TOTAL (número total de janelas do gráfico incluindo as subjanelas indicadoras)?

3 É lógico assumir que a especificação do número de janelas/subjanelas do gráfico separadamente não é necessária para obter o número total de janelas/subjanelas. Esta conclusão é apoiada pelo exemplo directamente do próprio Manual ( secção de Propriedades dos Gráficos):

   int windows=ChartGetInteger(0,CHART_WINDOWS_TOTAL);
   Print("CHART_WINDOWS_TOTAL = ",windows);

Uma abordagem semelhante é delineada na secção Operações do Gráfico / ChartWindowOnDropped.

A partir destes exemplos, pode-se ver que a posição dos autores do Manual é que não é necessário especificar um número de subjanela separado para obter o número total de janelas/subjanelas num gráfico. Claro que os exemplos utilizam a primeira variante da função, mas como estamos a falar da mesma propriedade (ou seja, CHART_WINDOWS_TOTAL), seria lógico supor que a mesma conclusão é válida para a segunda variante da função. Especialmente se tiver em conta que o Manual não contém quaisquer reservas sobre a necessidade de especificar um número de subjanela zero para a segunda variante da função.

4. o seu exemplo sugere que o terceiro parâmetro(sub_janela) deve ser sempre especificado para a segunda variante da função, mesmo que a propriedade em si não necessite de especificar um número de subjanela. Ou seja, ao contrário da primeira variante da função (que pode ser usada tanto com dois como com três parâmetros), a segunda variante da função requer sempre os quatro parâmetros. Certo?

5. Se correcto, estabelecemos duas coisas. Primeiro, a minha versão original do problema acabou por se revelar errada. Em segundo lugar, a razão para esta versão errónea é que a informação no Manual está incompleta. Assim, proponho um esclarecimento no Manual que "Não há valor por defeito para a segunda opção, pelo que o número da subjanela deve ser sempre especificado. Para a maioria das propriedades que não requerem um número de subjanela, é necessário especificar 0 (janela do gráfico principal)". Ou algo do género.

Obrigado pelo exemplo. É curta e directa ao assunto.

 
Yedelkin:
Na primeira variante da função intsub_janela=0 tem um valor por defeito, pelo que pode ser omitido; na segunda variante não existe tal valor por defeito, pelo que deve ser especificado.

 
Yedelkin:

OK. Vamos resolver isto.

1. A função utilizada é "aquilo", porque cita uma função com o mesmo nome que o seu exemplo. Só pode ser uma questão de qual versão dessa função (primeira ou segunda) está a ser utilizada.

2. De facto, formalmente, a primeira variante da função tem três parâmetros, enquanto que a segunda tem quatro. No entanto, na descrição do parâmetro sub_janela, que está presente em ambas as variantes da chamada, afirma-se claramente que "a maioria das propriedades não requer o número da subjanela". Levanta-se uma questão: é necessário ou não indicar o número da janela para bens como CHART_WINDOWS_TOTAL (Número total de janelas de gráficos incluindo as subjanelas de indicadores)?

3 É lógico assumir que a especificação do número de janelas/subjanelas do gráfico separadamente não é necessária para obter o número total de janelas/subjanelas. Esta conclusão é apoiada pelo exemplo directamente do próprio Manual de Referência (secção Propriedades do Quadro):


1. Considerando o facto de a função estar de facto sobrecarregada, podemos argumentar que não está (embora, como pode imaginar, seja discutível);

2. é essa a questão. Se eu compreender correctamente a lógica de sobrecarga de funções no MQL5, a primeira opção pode ser usada com 2 ou 3 parâmetros, enquanto que a segunda só pode ser usada com 4 parâmetros.

Ou seja, se uma função recebe dois ou três parâmetros, a MQL5 utilizará a primeira opção, enquanto que utilizará sempre a segunda se receber 4.

A questão é que o compilador fica confuso nas suas chamadas se utilizarmos a segunda variante com um número de parâmetro não igual a 4.

3. Há uma pequena imprecisão na Referência (ou melhor, uma redacção ligeiramente errada). O sentido geral é o seguinte - a maioria das propriedades não requer um número de janela, e na primeira opção para tais propriedades, o número da janela pode ser omitido(na segunda opção deve ser especificado, mas será ignorado).

4. do acima exposto, segue-se que para este exemplo o compilador irá escolher a primeira variante da função.

   int windows=ChartGetInteger(0,CHART_WINDOWS_TOTAL);
   Print("CHART_WINDOWS_TOTAL = ",windows);
O compilador fará tal conclusão com base no facto de o terceiro parâmetro na primeira variante poder ser omitido, enquanto na segunda variante deve necessariamente estar presente!!!
1...242243244245246247248249250251252253254255256...3184
Novo comentário
Razão: