Errori, bug, domande - pagina 2541

Nuovo commento
 
Ilyas:
Quindi non hai riportato il controllo al terminale, ti sei "impiccato" in un ciclo "infinito" all'interno del Fn nella DLL.
Di che tipo di licenziamento normale stiamo parlando!

Se avete bisogno di tale comportamento, dovreste eseguire un thread separato con un ciclo all'interno di Fn nella DLL, che dovrebbe essere fermato da un flag, che è impostato in una funzione separata FnStop e in DLL_PROCESS_DETACH

Il fatto che non ottengo il controllo indietro, è fatto per esempio, è chiaro che mentre dovrebbe essere eseguito in un thread separato, in modo da non bloccare il thread mql.
Ma ottengo lo stesso comportamento quando eseguo mentre in un altro thread, il problema è in DLL_PROCESS_DETACH, questo identificatore non funziona, per la bandiera esistente Detach.
Sì, abbiamo già scritto che dobbiamo creare una funzione esportata separata e usarla per controllare questa bandiera.
Ma come mostrato in questo esempio, il flag in DLL_PROCESS_DETACH non funziona.
Forse c'è un errore nel terminale, è logico che DLL_PROCESS_DETACH debba trasferire il flag in un altro stato.
Il ciclo while ottiene questo stato, esce dal ciclo, qualsiasi cosa incontrata lungo il percorso viene eseguita e termina la funzione Fn() stessa.
Solo dopo che la dll dovrebbe essere scaricata!
Ma questo non accade, otteniamo una sorta di scaricamento anticipato di dll da meccanismi terminali nascosti, quindi otteniamo un crash.

 
TheXpert:

Non voglio che persone incompetenti come te, Fedoseyev, ecc. si mettano a discutere di bug e costrutti.

in modo che le costruzioni e i meccanismi presi in MQL dal C++ nella loro interezza e con lo stesso aspetto del C++ funzionino come in C++.

È una stronzata e tu lo sai, ma devi buttarla lì.

Sei tu quello che si lamenta di quanto sia fastidioso, di una lingua separata e di un thread separato.

Apri un thread separato per te e i tuoi simpatizzanti e lamentati lì.

Avevo un'opinione migliore di te. Errore mio. Succede. Sei cafone e ... non intelligente.

 
Roman:

È fatto per esempio, mentre dovrebbe essere eseguito in un thread separato, in modo da non bloccare il thread mql.
Ottengo lo stesso comportamento quando inizio mentre sono in un altro thread, il problema è in DLL_PROCESS_DETACH, questo identificatore non funziona, per la bandiera esistente Detach.
Sì, abbiamo già scritto che dobbiamo creare una funzione esportata separata e usarla per controllare questa bandiera.
Ma come mostrato in questo esempio, il flag in DLL_PROCESS_DETACH non funziona.
Forse c'è un errore nel terminale, è logico che DLL_PROCESS_DETACH debba trasferire il flag in un altro stato.
Il ciclo while ottiene questo stato, esce dal ciclo, qualsiasi cosa incontrata lungo il percorso viene eseguita e termina la funzione Fn() stessa.
Solo dopo che la dll dovrebbe essere scaricata!
Ma questo non accade, otteniamo una sorta di scaricamento anticipato di dll da meccanismi terminali nascosti, quindi otteniamo un crash.

Fammi indovinare. Se si avvia un ciclo in un thread del terminale da dll, si blocca, e se lo si esegue in un thread separato, al quale si stacca(), allora il terminale si blocca con un errore?
 
Roman:

Non riprendere il controllo è solo un esempio, è chiaro che while dovrebbe essere eseguito in un thread separato per non bloccare il thread

Quindi dacci un esempio adeguato e lascia stare gli allegati. gestisci la creazione/cancellazione delle discussioni esplicitamente da solo.
 

Forum sul trading, sistemi di trading automatico e test di strategie di trading

Bug, bug, domande

Sergey Dzyublik, 2019.05.26 15:12

Sfortunatamente, al momento i tipi di puntatori a funzione in MT4/MT5 sono molto limitati e non pratici a causa di alcuni difetti:
#(non corretto in MT5(build 2118))"Errore di compilazione quando si usa la stessa firma di funzione ripetutamente all'interno di typedef".
#(non corretto in MT5(build2118))"Quando si lavora con typedef, usare una funzione template con specializzazione esplicita non genera codice per quella funzione template".


In vista dell'implementazione dello spazio dei nomi in sospeso, si prega di considerare l'implementazione del supporto per questo comportamento come parte delle correzioni dei difetti nel prossimo 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 ancora possiamo aspettare per le correzioni di bug nella funzionalitàtypedef?
Qualche sciocchezza - un passo a sinistra di un esempio primitivo sull'uso ditypedef e questo è tutto -un mucchio di bug che bloccano un ulteriore sviluppo.

 
Vladimir Simakov:
Fammi indovinare. Se si esegue un ciclo da dll in un thread del terminale, si blocca, ma se lo si esegue in un thread separato a cui si stacca(), il terminale si blocca con un errore?

Non esattamente.
Il lancio di un ciclo funziona bene.
Il problema è quando si ferma forzatamente il programma e si passa un flag al ciclo per uscire dal ciclo e terminare una funzione in esecuzione.
Ma il terminale non permette di uscire dal ciclo e terminare correttamente la funzione in esecuzione, perché lo scarico anticipato della dll è già attivato. Abbiamo un blocco.
La dll viene scaricata prima che lo stato della bandiera sia passato e la funzione Fn non termina, lo scaricamento anticipato rompe tutto.

L'ho fatto in thread terminale per esempio, per evitare di scrivere tutto il codice, perché in modalità bloccante il problema si vede meglio.
Ho creato una funzione separata per la bandiera del ciclo e il ciclo in esecuzione viene eseguito in un altro thread, ma lo stesso comportamento.
E quando provo a passare la bandiera ad un altro stato dal codice mql non bloccato, attraverso una funzione per uscire dal ciclo,
il terminale non aspetta che il ciclo in esecuzione finisca, e non lascia che la funzione Fn finisca dove il ciclo è in esecuzione.
Il terminale esegue immediatamente uno scaricamento anticipato del dll senza attendere il completamento della funzione Fn. Questo è il problema.

TheXpert:
quindi dai subito un esempio adeguato. e lascia stare gli attachi detachi. controlla la creazione/cancellazione dei thread esplicitamente tu stesso.

Si può vedere meglio il problema in modalità bloccata. Non ha molta importanza cosa cambia lo stato della bandiera. Con un punto di ingresso o una funzione separata.
Il punto d'ingresso è migliore per la modalità bloccata poiché il controllo non viene passato indietro e la funzione di cambio della bandiera non può essere chiamata. Questo è il motivo per cui atachi detechi è usato come esempio.
Atachi staccabile lasciato solo, fatto una funzione separata come hai consigliato, nessuna fortuna, su un progetto funzionante in modalità non bloccante, lo stesso comportamento.
La dll viene scaricata in anticipo, la funzione in esecuzione con il ciclo while non ha il tempo di completare e si blocca.

 
Roman:

La DLL viene scaricata in anticipo, una funzione in esecuzione con un ciclo while non ha il tempo di terminare e si verifica un blocco.

non ci può essere alcun blocco in una normale implementazione

 

Qualcuno ha incontrato il seguente problema con i simboli personalizzati? La funzione CustomRatesUpdate riceve quotazioni normali, ma in realtà il grafico e la finestra dei dati contengono qualcosa di strano (in questo caso i valori di close e low sono 100 volte inferiori a quelli passati):

Inoltre, in parallelo, i singoli tick sono emulati con CustomTicksAdd con gli stessi valori del prezzo di chiusura come nel log (immediatamente prima di CustomRatesUpdate), cioè non è chiaro da dove vengano i valori ridotti nelle virgolette.

UPD:

Ho una situazione "inversa" su USDCAD - le quotazioni aumentano di 10 volte dopo la scrittura. Questo è il registro che ricevo:

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

Il primo ArrayPrint è ciò che è stato scritto in CustomRatesUpdate, e il secondo ArrayPrint è ciò che è stato letto usando CopyRates dall'ultima barra più recente subito dopo la scrittura. In primo luogo, la differenza è l'ultima cifra in open, ma, cosa più importante, high e close sono aumentati di un fattore 10.

 
Stanislav Korotky:

Qualcuno ha incontrato il seguente problema con i simboli personalizzati? La funzione CustomRatesUpdate riceve quotazioni normali, ma in realtà il grafico e la finestra dei dati contengono qualcosa di strano (in questo caso i valori di close e low sono 100 volte inferiori a quelli passati):

Inoltre, i singoli tick sono emulati in parallelo usando CustomTicksAdd con gli stessi valori del prezzo di chiusura come nel log (immediatamente prima di CustomRatesUpdate), cioè non è chiaro da dove vengono i valori ridotti nelle quotazioni.

Sì, l'ho incontrato, solo che il mio nulla non era chiaro. Hai 100 volte il numero di picchi.
Ho fatto un controllo supplementare dello zero, non è servito, funzionava tutto sbagliato, poi disegnava tali picchi.
Per lo più questo comportamento è stato osservato al primo avvio del programma, e al primo avvio i file della cronologia sono stati creati con una data inesistente.
Pulito cartella zecche, codice corretto, al fine di trovare dove il bug, annoiato, rinviato per ora, ma hanno anche di tornare a questo problema ((
Controlla anche la cronologia personalizzata della cartella, ci possono essere file con una data che non esiste )))
In generale, l'insetto vive lì specifico.

Si prega di duplicare il problema in questo thread
Credo che Slava si occupi dei personaggi personalizzati lì.
Per ricordare il problema.
 

Questo errore è già stato menzionato prima? Non riesco a trovarlo. Morale della favola: quando si caricano i risultati dell'ottimizzazione dal file di cache, i risultati in avanti vengono visualizzati in modo errato. I valori dei parametri hanno cifre sbagliate.

Vai alla scheda di ottimizzazione. Selezionate l'Expert Advisor. Seleziona una delle precedenti ottimizzazioni. I backtest vengono caricati normalmente. Gli attaccanti danno questo:



MT5, ultima build. x64.

1...253425352536253725382539254025412542254325442545254625472548...3184
Nuovo commento