Erros, bugs, perguntas - página 2541

Novo comentário
 
Ilyas:
Assim, não conseguiu o controlo de volta ao terminal, "desligou-se" num laço "infinito" dentro da Fn na DLL.
De que tipo de rescisão normal estamos a falar!

Se precisar desse comportamento, deve executar um fio separado com um laço dentro de Fn em DLL, que deve ser parado por uma bandeira, que é colocada numa função separada FnStop e com DLL_PROCESS_DETACH

O facto de eu não recuperar o controlo, é feito, por exemplo, é claro que embora deva ser executado num fio separado, de modo a não bloquear o fio mql.
Mas tenho o mesmo comportamento quando corro noutro fio, o problema está em DLL_PROCESS_DETACH, este identificador não funciona, para o Destacador de bandeira existente.
Sim, já escrevemos, que precisamos de criar uma função separada exportada e usá-la para controlar esta bandeira.
Mas como se mostra neste exemplo, a bandeira em DLL_PROCESS_DETACH não funciona.
Talvez haja um erro no terminal, é lógico que a DLL_PROCESS_DETACH deve transferir a bandeira para outro estado.
Enquanto o laço recebe este estado, sai do laço, qualquer coisa encontrada ao longo do caminho é executada e termina a própria função Fn().
Só depois disso é que o dll deve ser descarregado!
Mas isto não acontece, recebemos algum tipo de descarga antecipada de dll por mecanismos terminais ocultos, por isso temos um acidente.

 
TheXpert:

Não quero que pessoas incompetentes como você, Fedoseyev, etc. interfiram na discussão de insectos e desenhos.

para que as construções e mecanismos tomados em MQL de C++ na sua totalidade e com o mesmo aspecto que em C++ funcionassem da mesma forma que em C++.

é uma treta e você sabe disso, mas tem de o atirar para lá.

És tu quem se queixa de quão irritante é, de uma língua separada e de um fio à parte.

Abra um fio separado para si e para os seus simpatizantes e lamente-se lá.

Tive uma opinião melhor a seu respeito. O meu erro. Acontece. És um rústico e ... não inteligente.

 
Roman:

É feito, por exemplo, enquanto deve ser executado num fio separado, de modo a não bloquear o fio mql.
Tenho o mesmo comportamento quando começo noutro tópico, o problema está em DLL_PROCESS_DETACH, este identificador não funciona, para o Destacador de bandeira existente.
Sim, já escrevemos, que precisamos de criar uma função separada exportada e usá-la para controlar esta bandeira.
Mas como se mostra neste exemplo, a bandeira em DLL_PROCESS_DETACH não funciona.
Talvez haja um erro no terminal, é lógico que a DLL_PROCESS_DETACH deve transferir a bandeira para outro estado.
Enquanto o laço recebe este estado, sai do laço, qualquer coisa encontrada ao longo do caminho é executada e termina a própria função Fn().
Só depois disso é que o dll deve ser descarregado!
Mas isto não acontece, recebemos algum tipo de descarga antecipada de dll por mecanismos terminais ocultos, por isso temos um acidente.

Deixem-me adivinhar. Se iniciar um laço numa thread terminal a partir da dll, esta fica pendurada, e se a executar numa thread separada, à qual se desprende(), então o terminal trava com um erro?
 
Roman:

Não retomar o controlo é apenas um exemplo, é claro que embora deva ser executado num fio separado para não bloquear o fio

Portanto, dê-nos um exemplo adequado e deixe os anexos em paz. administre a criação/eliminação de fios explicitamente por si próprio.
 

Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial

Insectos, insectos, perguntas

Sergey Dzyublik, 2019.05.26 15:12

Infelizmente, neste momento os tipos de apontadores de funções em MT4/MT5 são muito limitados e não são práticos devido a alguns defeitos:
#(não fixado em MT5(build 2118))"Erro de compilação quando se utiliza a mesma assinatura de função repetidamente dentro do typedef".
#(não fixo em MT5(build2118))"Quando se trabalha com typedef, a utilização de uma função modelo com especialização explícita não gera código para essa função modelo".


Tendo em conta a implementação do namespace pendente, por favor considere a implementação de apoio a este comportamento como parte da reparação de defeitos no próximo C++:
//#include <iostream>

template<typename T>
class A{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
    T data;
};

template<typename T>
class B{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
};

template<typename T>
void func(T& value){
    ++value;
}


void OnStart(){
//int main(){
    A<int> a;
    B<int> b;
    
    a.f_ptr = func<int>;      // automatic code generation of templates functions
    b.f_ptr = a.f_ptr;        // assignment operation for function pointers with the same function signatures and different function pointer types.
    
    int x = 1;
    b.f_ptr(x);
    printf("%d\r\n", x);                  //2
    printf("%d\r\n", b.f_ptr == a.f_ptr); //1     // equal operation for function pointers with the same function signatures and different function pointer types.
}

MT5 (build 2118), Quanto tempo mais podemos esperar por correcções de bugs na funcionalidade dotypedef?
Alguns disparates - um passo à esquerda de um exemplo primitivo sobre a utilização dotypedef e mais nada -um bando de insectos a bloquear o desenvolvimento futuro.

 
Vladimir Simakov:
Deixem-me adivinhar. Se executar um laço de dll numa thread terminal, ele pendura, mas se o executar numa thread separada para a qual se separa(), o terminal trava com um erro?

Não exactamente.
O lançamento de um laço funciona bem.
O problema é quando se pára o programa à força e se passa uma bandeira para o laço para sair do laço e terminar uma função em execução.
Mas o terminal não permite sair do laço e terminar correctamente a função em execução, porque a descarga antecipada do dll já está activada. Temos um problema.
O dll é descarregado antes do estado de bandeira ser passado e a função Fn não termina, o descarregamento precoce quebra tudo.

Fi-lo no fio terminal, por exemplo, para evitar escrever todo o código, porque no modo de bloqueio o problema é melhor visto.
Criei uma função separada para a bandeira do laço e o laço está a correr noutro fio, mas o mesmo comportamento.
E quando tento mudar a bandeira para outro estado a partir de um código mql não bloqueado, através de uma função para sair do laço,
o terminal não espera que o laço em funcionamento termine, e não deixa que a função Fn termine onde o laço está em funcionamento.
O terminal executa imediatamente uma descarga dll antecipada sem esperar que a função Fn seja concluída. Este é o problema.

TheXpert:
portanto dê um exemplo adequado imediatamente. e deixe o attachi detachi em paz. controle você mesmo explicitamente a criação/eliminação de fios.

Pode ver melhor o problema no modo bloqueado. Não importa realmente o que muda o estado da bandeira. Com um ponto de entrada ou uma função separada.
O ponto de entrada é melhor para o modo bloqueado, uma vez que o controlo não é passado para trás e a função de mudança de bandeira não pode ser chamada. É por isso que atachi detechi é utilizado como exemplo.
Atachi destacável sozinho, fez uma função separada como aconselhou, sem sorte, num projecto de trabalho em modo não-bloqueio, o mesmo comportamento.
O dll é descarregado cedo, a função de correr com o laço não tem tempo para completar e fica pendurado.

 
Roman:

O dll é descarregado cedo, uma função em execução com um loop while não tem tempo para terminar e ocorre um hangup.

não pode haver pendências numa implementação normal

 

Alguém encontrou o seguinte problema com símbolos personalizados? A função CustomRatesUpdate recebe citações normais, mas de facto o gráfico e a janela de dados contém algo estranho (neste caso, os valores próximos e baixos são 100 vezes menos do que passados):

Além disso, em paralelo, os carrapatos simples são emulados com CustomTicksAdd com os mesmos valores de preços próximos que no registo (imediatamente antes de CustomRatesUpdate), ou seja, não é claro de onde vêm os valores reduzidos nas cotações.

UPD:

Tenho situação "inversa" no USDCAD - as citações aumentam 10 vezes depois de escritas. Este é o diário de bordo que estou a receber:

2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]  [high]   [low] [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32987 1.32987 1.32980 1.32987           457       48             0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) Retry: 1 0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]   [high]   [low]  [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32980 13.29730 1.32980 13.29730           457       52             0

O primeiro ArrayPrint é o que foi escrito em CustomRatesUpdate, e o segundo ArrayPrint é o que foi lido usando CopyRates do último bar imediatamente após a escrita. Em primeiro lugar, a diferença é o último dígito em aberto, mas mais importante, alto e fechado são aumentados por um factor de 10.

 
Stanislav Korotky:

Alguém encontrou o seguinte problema com símbolos personalizados? A função CustomRatesUpdate recebe citações normais, mas de facto o gráfico e a janela de dados contém algo estranho (neste caso, os valores próximos e baixos são 100 vezes menos do que passados):

Além disso, os tiques simples são emulados em paralelo usando CustomTicksAdd com os mesmos valores de preço fechado que no registo (imediatamente antes de CustomRatesUpdate), ou seja, não é claro de onde vêm os valores reduzidos nas cotações.

Sim, já o encontrei, mas o meu nulo não era claro. Tem 100 vezes o número de espigões.
Fiz uma verificação zero extra, não ajudou, estava a funcionar mal, estava a desenhar espigões assim.
Este comportamento foi sobretudo observado na primeira vez que comecei o programa, e na primeira vez que criou ficheiros de história com uma data inexistente.
Carrapatos de pastas limpas, código corrigido, a fim de encontrar onde o bug, aborrecido, adiado por agora, mas também tem de voltar a este problema ((
Verifique também o histórico personalizado da pasta, pode haver ficheiros com uma data que não existe ))))
Em geral, o insecto vive lá especificamente.

Por favor duplique o problema neste tópico
Penso que Slava é o responsável pelos caracteres personalizados.
Para lembrar o problema.
 

Este erro já foi mencionado anteriormente? Não o consigo encontrar. Conclusão: ao carregar resultados de optimização a partir do ficheiro cache, os resultados para a frente são apresentados incorrectamente. Os valores dos parâmetros têm os dígitos errados.

Vai para o separador da optimização. Seleccionar o Expert Advisor. Seleccione uma das antigas optimizações. Os testes de fundo são carregados normalmente. Os adiantados dão isto:



MT5, última construção. x64.

1...253425352536253725382539254025412542254325442545254625472548...3184
Novo comentário