Errori, bug, domande - pagina 2342
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Le risorse sono limitate a queste dimensioni?
Quindi ha ancora più senso condensare i dati che vengono trasmessi.
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
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?
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.
E quando si accede a un array, non sarebbe logico controllare l'indice di accesso?
Non è logico.
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.
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ì?
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.
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?