Organizzazione del ciclo dell'ordine - pagina 11
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
Tuttavia, è meglio non farlo - ogni cosa dovrebbe essere al suo posto.
Nel timer EA, prendiamo una lista secondo i criteri richiesti e a list.Total()>xxx facciamo quello che vogliamo.
Si scopre che nel vecchio MQL4, dove non c'era il timer, il problema non aveva soluzione? Perché preoccuparsi del timer, quando può essere risolto in poche righe?
È esattamente quello che stavo guardando.
E il mio post
E che senso ha, nel trading reale, inseguire continuamente il ciclo degli ordini? Soprattutto, è una perdita di tempo...
Avere sempre informazioni aggiornate sull'ambiente di trading, e non cercare ogni volta che è necessario, ma fare riferimento alle liste disponibili. E siccome le liste devono essere sempre aggiornate, vale la pena fare attenzione ad aggiornarle costantemente, ma efficacemente.
Dopo tutto, se non avete liste, dovrete cercare le informazioni quando ne avete bisogno. E non solo una volta per zecca. Ed è lì che tutti i freni del caricamento ripetuto dell'ambiente si manifesteranno.
Anche se è possibile ottimizzare anche qui - se rinunciamo al controllo sui cambiamenti dell'ambiente e riempiamo le liste solo quando è necessario. Ma poi si perderebbe la capacità dell'EA di reagire alle azioni manuali di chiusura/modifica/apertura dell'utente.
Si scopre che nel vecchio MQL4, dove non c'era il timer, il problema non aveva soluzione? Perché preoccuparsi di un timer quando può essere risolto in poche righe?
Quando è stato impossibile farlo, abbiamo dovuto pensare a come risolverlo. Ma ora è possibile ;)
Avere sempre informazioni aggiornate sull'ambiente di trading, e non dover cercare ogni volta quando necessario, ma fare riferimento alle liste esistenti. Dato che le liste dovrebbero essere sempre aggiornate, vale la pena fare attenzione a mantenerle sempre aggiornate, ma in modo efficiente.
Dopo tutto, se non avete liste, dovrete cercare le informazioni quando ne avete bisogno. E non solo una volta per zecca. E qui tutti i rallentamenti appariranno al caricamento ripetuto dell'ambiente.
Anche se, anche qui può essere ottimizzato - se si rifiuta di controllare i cambiamenti dell'ambiente e riempire le liste solo quando necessario. Ma poi, si perde la capacità dell'EA di reagire alle azioni dell'utente sulla chiusura/modifica/apertura manuale.
Questa è la parola chiave"ma efficace". E qual è il significato profondo di aggiornare la lista ogni millisecondo se la lista può cambiare solo quando arriva il prossimo tick? E perché non solo una volta per zecca? Un ordine può essere chiuso fuori da un tick? Per come la vedo io, anche se non c'è nessun tick e l'EA invia un comando di apertura/chiusura, cioè di cambiamento dell'ambiente, cioè della lista, questa azione causerà un tick. O se non lo è, allora senza un tick causato da qualcos'altro, la lista non sarà cambiata. Non è così?
Ecco la parola chiave"ma efficacemente". E che senso ha aggiornare la lista ogni millisecondo, se la lista può cambiare solo alla ricezione del prossimo tick? E perché non solo una volta per zecca? Un ordine può essere chiuso fuori da un tick? Per come la vedo io, anche se non c'è nessun tick e l'EA invia un comando di apertura/chiusura, cioè di cambiamento dell'ambiente, cioè della lista, questa azione causerà un tick. O se non lo è, allora senza un tick causato da qualcos'altro, la lista non sarà cambiata. Non è così?
Nel tester eseguo OnTimer(), che crea liste solo da OnTick(), ma nella vita reale non si fa differenza...
Ma lì un timer è necessario non solo per la creazione di liste. Tutto sommato - tutto ciò di cui abbiamo bisogno in una volta sola. Per ora. Ulteriori profili mostreranno i colli di bottiglia.
Questa è la parola chiave"ma efficacemente". E qual è il significato più profondo dell'aggiornamento della lista ogni millisecondo, se la lista può essere cambiata solo con l'arrivo di un altro tick? E perché non solo una volta per zecca? Un ordine può essere chiuso fuori da un tick? Per come la vedo io, anche se non c'è nessun tick e l'EA invia un comando di apertura/chiusura, cioè di cambiamento dell'ambiente, cioè della lista, questa azione causerà un tick. O se non lo è, allora senza un tick causato da qualcos'altro, la lista non sarà cambiata. Non è così?
C'è un senso nel bruteforcing del timer se il programma lavora con molti simboli - i tick arrivano in tempi diversi.
Ma non ha senso cercare "non la tua" lista di ordini, ma quella creata dal terminale, che è la ragione dei problemi che la lista viene modificata da qualcun altro.
C'è un senso nel bruteforcing del timer se il programma lavora con molti simboli - i tick arrivano in tempi diversi.
Ma non ha senso cercare "non la propria" lista di ordini, ma la lista creata dal terminale, che è la ragione dei problemi quando la lista viene modificata da qualcun altro.
Nel caso della lista "non tua", c'è una quantità totale di ordini che può essere memorizzata in una variabile statica ed eseguire il ciclo per enumerare l'ambiente mentre cambia. Ma non ogni millisecondo...
Nel caso in cui la lista non sia "propria" c'è un numero totale di ordini che può essere memorizzato in una variabile statica ed eseguire un ciclo per rieseguire l'ambiente quando cambia. Ma non ogni millisecondo...
Non è possibile catturare l'attivazione di un ordine pendente in questo modo.
Non è possibile catturare l'attivazione di un ordine pendente in questo modo.
Quindi non stiamo parlando di catturare le pulci, cioè l'ordine pendente, stiamo parlando di provare tutti gli ordini ogni millisecondo.
Quindi non si tratta di catturare le pulci, cioè gli ordini in sospeso, ma di passare attraverso tutti gli ordini ogni millisecondo.
- A cosa ti serve una padella?
- Per esempio, per friggere le uova.
- Non si tratta di uova strapazzate, ma della padella...