Errori, bug, domande - pagina 2342

 
fxsaber:
Le risorse sono limitate a queste dimensioni?

Quindi ha ancora più senso condensare i dati che vengono trasmessi.

 
fxsaber:

In questo senso MT4 era molto più saggio di MT5 - non c'era nessun crash del programma e si poteva analizzare il LastError.

In primo luogo: continuare ad eseguire il programma dopo un errore critico irrecuperabile non è saggezza, ma stupidità.

In secondo luogo: non sono arrivato a PrintError() in MetaTrader 4 765x32 dopo averlo eseguito

Terzo: se si rimuove strict, lo ha raggiunto, ma GetLastError() restituisce 0, quindi non è chiaro cosa analizzare

 
fxsaber:
Come notificare all'utente l'arresto dell'EA?

In questo senso MT4 era molto più saggio di MT5 - non c'era nessun crash del programma e si poteva analizzare il LastError.

E quando si accede a un array, non è logico controllare l'indice di accesso?

 
A100:

In primo luogo: è stupidità, non saggezza, continuare l'esecuzione del programma dopo un errore critico irrecuperabile.

In secondo luogo, dopo aver eseguito questo in MetaTrader 4 765x32, PrintError() non è mai successo.

In terzo luogo, se si rimuove strict, restituirà 0, ma GetLastError(), quindi non è chiaro cosa analizzare.

Non c'era nessun compito per dimostrare che MT4 è meglio di MT5. Dovevo risolvere un problema pratico.

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

Biblioteche: HistoryTicks

fxsaber, 2018.12.10 13:55

Ricevi un messaggio che l'EA si è fermato a causa di un array fuori portata(non è colpa dell'autore dell'EA). Per esempio, a causa della mancanza di memoria o di altri guasti. Ciò significa che saprete subito che l'EA si è fermato in modo anomalo, piuttosto che notarlo accidentalmente qualche ora dopo.


È spiacevole quando l'Expert Advisor si è fermato, ma non viene segnalato in alcun modo.

Georgiy Merts:

E quando si accede a un array, non sarebbe logico controllare l'indice di accesso?

Non è logico.

 
Nikolai Semko:

Quindi è tanto più ragionevole condensare i dati che vengono trasmessi.

Controllato, 60Mb viene scritto facilmente (MT4/5) su Resources. Quindi, se c'è un limite, è più alto.

 

Un piccolo punto, ma comunque.

Quando si invia allo Storage - il primo pannello "Fixing" - funziona bene, e il secondo, la conferma, nel mio primo caso, non aspetta il tasto OK, ma esce immediatamente, e in secondo luogo - non mostra tutti i file inviati. Ho controllato però - i file vengono inviati normalmente.

Sono solo io?

Sembra essere corretto - quando dopo l'invio viene visualizzato un elenco di file inviati con una conferma che tutto è andato bene.

 
fxsaber:

Non ha senso.

E perché?

Mi sembra che non abbiamo bisogno di controllare l'indice in quei posti dove, a rigor di logica, non c'è modo che un indice che va oltre i limiti dell'array possa apparire. E anche in questo caso dovreste usare ASSERT, per sicurezza.

E in quei posti dove l'indice dipende da azioni precedenti relative a parametri esterni, citazioni e azioni dell'utente, il controllo del riferimento all'indice dovrebbe essere obbligatorio.

Secondo voi, non è così?

 
Georgiy Merts:

E perché?

Mi sembra che non ci sia bisogno di controllare l'indice dove, in base alla logica del programma - non c'è modo che un indice possa apparire fuori dall'array.

Sono d'accordo.

E anche in questo caso dovrete usare ASSERT per sicurezza.

Non sono d'accordo perché la leggibilità del codice ne soffrirà molto.

In quei posti dove l'indice dipende da azioni precedenti relative a parametri esterni, citazioni e azioni dell'utente, il controllo dell'indice di riferimento deve essere obbligatorio.

Non capisco cosa si intende qui per parametri esterni. Ogni volta che si controlla che ArrayResize o ArrayCopy abbiano completato normalmente e non banalmente la memoria in esaurimento, si gonfia il codice attraverso ASSERT, e questo è davvero un casino. Se non lo controlli, avrai un arresto impercettibile dell'Expert Advisor. Finora ho trovato solo una soluzione: sostituire ArrayResize e ArrayCopy.

 
Slava:

Chi è in mezzo?

ChartSaveTemplate(chart_id,"\\Files\\MyPreferredTemplates\\cewl.tpl");

La funzione non crea una cartella, scrive solo un modello se esiste già una cartella .... Se la cartella non esiste, errore 4112

Quindi, le cartelle devono essere preparate in anticipo...

È interessante, la funzione FileOpen non può creare una cartella nella cartella del modello e la funzione ChartSaveTemplate non crea directory...

Cioè, se volete salvare i modelli nelle sottocartelle, allora create le cartelle manualmente....

 

fuori dalla memoria

durante la ricerca di GlobalVariables

può sorgere?