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
Faz sentido
substituir tarifas_total por BarsCalculated(ich)?
Não me parece. É mais como um toco de serviço para garantir que o tampão está pronto...
Além disso, Copy devolverá tantos dados como os calculados, não o tamanho solicitado.
E de que cidade é, se não de um segredo?
A propósito, tem a certeza de que não precisa de chamar nenhuma função adicional?
A biblioteca tem tanto o Refresh como o BufferResize. Parece-me que eles são necessários para um funcionamento normal.
E onde está escrito que eles devem estar?
Experimentei diferentes variantes.
Não tive qualquer efeito.
Continuação....
O indicador iIchimoku está a sofrer uma falha. O meu indicador apenas desenha setas dependendo de if(tenkan[i]>kijun[i]). Como pode ver na imagem do ecrã, as setas não são desenhadas correctamente
O código completo está no ficheiro Ich_1_f.mq5
No entanto, se os calcular manualmente, tudo é apresentado correctamente
Código completo no ficheiro Ich_1_ok.mq5
Escreva a dll :
ligue-o :
chamada :
obtemos isto:
embora ambas as linhas devam devolver o mesmo valor 153,25.
Porquê?
Porquê?
Isto está na versão de 32 ou 64 bits?
É muito simples - na função GetPtrVar(duplo a), pega-se no endereço de uma cópia da variável na pilha e depois tenta-se ler o pedaço de memória da pilha.
A primeira vez, por causa de uma chamada de proximidade de GetValuePtr conseguimos ler a partir da pilha não contaminada, enquanto que as chamadas de funções subsequentes danificaram a pilha de forma irrevogável.
Não há erro.
É muito simples - na função GetPtrVar(duplo a) pegue no endereço de uma cópia da variável na pilha, e depois tente ler o pedaço de memória da pilha.
Exactamente, senti que devia cavar ali algures.
tem de escrever na dll
É muito simples - na função GetPtrVar(duplo a), pega-se no endereço de uma cópia da variável na pilha e depois tenta-se ler o pedaço de memória da pilha.
A primeira vez, por causa de uma chamada de proximidade de GetValuePtr conseguimos ler a partir da pilha não contaminada, enquanto que as chamadas de funções subsequentes danificaram a pilha de forma irrevogável.
Não há erro.
Eu também reparei nisso. Penso que esta é a forma correcta de o fazer:
ligação :