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
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...)
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).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 tentei pedir a cor de fundo. Ia escrever para o Servicedesk, mas esqueci-me.
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
Não vejo o seu código, mas parece estar correcto:
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:
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):
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.
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.
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.
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!!!