Come controllare se un ordine è selezionato - pagina 4
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
In effetti, c'è stata molta demagogia.
Tutto ciò di cui abbiamo bisogno per sapere se un ordine è selezionato o no.
L'ho spiegato all'inizio del topic, non è chiaro?
Abbiamo una funzione che potenzialmente gestisce gli ordini, cioè li seleziona e li analizza. Può essere chiamato da diversi frammenti di codice, compresi quelli che hanno già un ordine selezionato con cui lavorare. Se questa funzione separata non salva l'ordine già selezionato e ripristina la sua selezione, questo porterà ad errori nella logica dell'EA, dato che quando torniamo da questa funzione, l'ordine selezionato prima che sia chiamata sarà sbagliato. Quindi, per evitare questi errori, dobbiamo ricordare l'ordine attualmente selezionato dal luogo della sua chiamata in ogni funzione ausiliaria che gestisce gli ordini da sola e restituire la sua selezione quando ha finito. Come realizzare questo compito facilmente e senza generare errori - questa è la domanda del tema attuale
// Implica che un ordine è selezionato tramite OrderSelect (o c'è un errore).
Perché un errore? Se l'ordine non è selezionato, questa azione semplicemente non è necessaria, ma sembra che sia impossibile scoprire in anticipo se l'ordine è selezionato o meno senza trucchi speciali
// Allora perché dovrebbe essere selezionato di nuovo?
Ecco perché dopo il ritorno da questa funzione nella parte di codice chiamante, l'ordine selezionato in questa parte di codice prima della chiamata della funzione rimane selezionato - in modo che le operazioni che vengono eseguite con l'ordine attualmente selezionato non portino a errori
No, è davvero nel serbatoio.
Ho spiegato tutto all'inizio del thread, è così poco chiaro?
Abbiamo una funzione che potenzialmente lavora con gli ordini, cioè li seleziona e li analizza. Può essere chiamato da diversi frammenti di codice, compresi quelli che hanno già un ordine selezionato con cui lavorare. Se questa funzione separata non salva l'ordine già selezionato e ripristina la sua selezione, questo porterà ad errori nella logica dell'EA, dato che quando torniamo da questa funzione, l'ordine selezionato prima che sia chiamata sarà sbagliato. Quindi, per evitare questi errori, dobbiamo ricordare l'ordine attualmente selezionato dal luogo della sua chiamata in ogni funzione ausiliaria che gestisce gli ordini da sola e restituire la sua selezione quando ha finito. Come realizzare questo compito facilmente e senza generare errori è la questione di questo stesso argomento
1. Per passare alla funzione il numero dell'ordine selezionato prima della sua chiamata.
2. Quando la funzione finisce, riseleziona lo stesso ordine.
Come faccio a sapere cosa vuoi ottenere? Dovrai essere più specifico :(
1. Invia il numero dell'ordine selezionato prima che la funzione venga chiamata.
2. Quando la funzione finisce, riseleziona lo stesso ordine.
Come faccio a sapere cosa vuoi ottenere? Dovresti essere più chiaro :(
Sì, lo capisco, però vorrei scrivere funzioni informative, come il profitto totale o gli ordini aperti, che possono essere chiamate senza pensare che cambieranno qualcosa nella logica di esecuzione del programma. Questo ha senso, credo.
Non è sempre banale passare l'ordine selezionato nella funzione chiamante, immaginate che l'annidamento delle chiamate >1, dovremmo passare un biglietto ad ogni funzione in modo che qualche funzione informativa minore possa usarlo?
Sarebbe più logico dare un wrapper a OrderSelect e OrderTicket, che memorizzerebbe e otterrebbe informazioni sull'ordine attualmente selezionato da una variabile separata, ma qui finiamo con il raddoppiare le informazioni (il terminale sa già se l'ordine è scelto, ma non possiamo passare questa informazione senza un potenziale errore). In altre parole, o otteniamo una duplicazione di informazioni o un'eccessiva complicazione delle funzioni (passiamo anche l'ordine selezionato dall'alto in ogni parametro), o dobbiamo generare errori di esecuzione del programma.
Sì, lo capisco, ma vorrei scrivere funzioni informative, come il profitto totale o il numero di ordini aperti, che possono essere chiamate senza pensare che cambieranno la logica di esecuzione del programma. Questo ha senso, credo.
Ha senso, ma in questo caso dovremmo almeno dividere le funzioni in "bianche" e "nere". Il numero d'ordine selezionato nel primo viene salvato, e quando viene violato nel secondo, viene ripristinato.
Sembra essere così semplice.
Sì, lo capisco, ma vorrei scrivere funzioni informative, come il profitto totale o il numero di ordini aperti, che possono essere chiamate senza pensare che cambieranno la logica di esecuzione del programma. Questo è abbastanza logico, credo.
Non è sempre banale passare l'ordine selezionato nella funzione chiamante; immaginate che l'annidamento delle chiamate >1, non dovremmo passare un biglietto ad ogni funzione in modo che qualche funzione informativa minore possa usarlo?
Guardate la libreria di funzioni di Kim e vedrete che ogni funzione enumera, seleziona e controlla il biglietto, e poi quello che dovete sapere. La vostra "logica" non vi permette di imparare le regole di base della programmazione.
Hai un anziano in un campo e uno zio a Kiev.
Guardate la libreria di funzioni di Kim e vedete che ogni funzione fa l'enumerazione, la selezione e il controllo del biglietto, e poi ciò che deve essere appreso. La vostra "logica" non vi permette di imparare le regole alfabetiche della programmazione.
Un piccolo anziano in un giardino e uno zio a Kiev.
Boris, non è necessario. Sto parlando dell'ABC.