Imparare e scrivere insieme in MQL5 - pagina 18
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
Beh, avete capito bene. Te lo dico meticolosamente, puoi controllare: la funzione OrderSend() restituisce un valore booleano. In questo caso, se la richiesta viene controllata con successo, il biglietto d'ordine viene scritto nella variabile della struttura MqlResult. Io lo chiamo "ritorno della funzione del biglietto d'ordine" per me. Ecco il link alla fonte:"Quando si invia una richiesta di acquisto utilizzando la funzione OrderSend(), è possibile scoprire immediatamente il ticket dell'ordine che è stato creato se la richiesta viene controllata con successo.
E se hai intenzione di divagare dal soggetto su iniziativa del moderatore, hai una risposta simile: non c'è e non ci sarà mai un tutorial MQL5, quindi non è chiaro, quale tutorial stai guardando attraverso. ... Forse, possiamo discutere la sostanza della discussione, o niente del tutto? :)
Grazie per la risposta sul 'divieto', l'ho capito.
Non è proprio una comprensione corretta di ciò che accadrà quando si riceve una risposta dal server.
OrderSend() restituisce davvero un valore booleano, ma non è la cosa più importante - la cosa principale è la struttura, che viene riempita quando si riceve una risposta dal server.
Sì, scriviamo un biglietto nella struttura (non solo ordini, ma anche offerte), ma è più importante del resto delle informazioni nella struttura?
Analizziamo la struttura della risposta. A mio parere, il quadro è approssimativamente il seguente
PS
Il nome corretto per una struttura è MqlTradeResult e non MqlResult (anche se non ha molta importanza secondo me).
Se la richiesta è corretta ed eseguita, allora il volume e il prezzo sono importanti nel caso in cui il server "aveva il diritto" di ridurre i parametri dei dati della transazione e può richiedere una reazione di Expert Advisor sulle azioni del server.
Sfortunatamente, continuo a non capirlo.
è necessario avere un campo "tempo" nella struttura di ritorno per qualche motivo. utilizzare il tempo nell'ordine in cui appare. Questo è sufficiente per controllare una piccola storia.
La struttura dovrebbe essere chiamata MqlTradeResult , non MqlResult (anche se non ha molta importanza secondo me).
Non è esattamente una comprensione corretta di ciò che accade quando si riceve una risposta dal server.
OrderSend() restituisce effettivamente un valore booleano, ma non è la cosa più importante. La cosa principale è la struttura che viene riempita ricevendo una risposta dal server.
Sì, effettivamente, un biglietto viene scritto nella struttura (non solo ordini, ma anche affari), ma è più importante del resto delle informazioni nella struttura?
"Quando si invia una richiesta di acquisto utilizzando la funzione OrderSend(), possiamo conoscere immediatamente il ticket dell'ordine che è stato creato quando la richiesta è stata controllata con successo. Ma allo stesso tempo, l'ordine stesso potrebbe non apparire ancora nel terminale del cliente e un tentativo di selezionarlo usando la funzione OrderSelect fallirà. Dalla seconda frase segue che non è sempre possibile lavorare con le proprietà dell'ordine (tempo dell'ordine), anche se il suo biglietto è noto. Quindi "usare il tempo nell'ordine in cui è apparso" non è una soluzione ideale. Inoltre, l'ordine potrebbe "non aprirsi" affatto. Il mio approccio risolverebbe il problema di controllare una piccola storia indipendentemente da ciò che è successo all'ordine prima che entrasse nella storia.
Non so, se è così importante chiedere agli sviluppatori di fare aggiunte alla struttura di MqlTradeResult (sotto forma di tempo per il quale viene eseguito un trade o viene impostato un ordine).
Anche se non capisco perché sia necessario, preferirei aggiungere parametri a OnTrade().
Non so, se è così importante, chiedete agli sviluppatori di fare delle aggiunte nella struttura MqlTradeResult(come tempo dell'affare eseguito o dell'ordine piazzato).
Beh, è quello che chiedevo fin dall'inizio :) C'era un precedente, per così dire :)
Aggiunta: se qualcuno avesse fatto questa domanda sei mesi fa, potremmo sperare in un'apparizione relativamente veloce di questa caratteristica, mentre aspettiamo il prossimo anno - è più facile inserire una variabile per la data. Anche se non sarà completamente accurata, ma comunque.
Anche se non capisco perché sia necessario, preferirei aggiungere dei parametri a OnTrade().
Personalmente non posso più aspettare che la struttura/parametri del commercio appaiano. Lo sto aspettando già da 9 mesi. Dovrò accontentarmi di quello che ho.
Ho scritto "a memoria", in risposta al consiglio di studiare un libro di testo Beh, non discutiamo, chi ha una migliore comprensione :) Guarda la mia risposta a Sergeev. E qui ripeto: secondo la logica della strategia ho bisogno solo di un biglietto e del tempo di portare l'ordine alla produzione. Quello che lei ha sottolineato non è nessuno dei due. "Informazioni molto importanti" come il retcode non aiutano affatto a ottimizzare il caricamento della storia, che è quello di cui sto parlando in generale.
1. OrderSend() e il caricamento della storia, e da questo punto, per favore, elaborate (non so di cosa si tratti, e penso che siamo senza erba).
2. Logicamente, se l'analisi si basa solo sul risultato di OrderSend(), la sequenza di azioni è la seguente
a) Controlla il retcode, dobbiamo sapere cosa è successo veramente;
b) Se il risultato è positivo, ottenere il biglietto, il volume e il prezzo. Se un requote, otteniamo i nuovi prezzi (e controlliamo se ci soddisfano).
c) Se la risposta è soddisfacente e non ci sono errori, ottenere un biglietto e un orario. Puoi usare l'ora del server o provare a tirarla fuori dalla storia (per il calcolo approssimativo al momento, è meglio conoscere l'ora del server);
d) Se non siamo soddisfatti della risposta (o soddisfatti solo in parte) - non corrisponde al volume o abbiamo un requote, decidiamo i prossimi passi.
PS
In breve, non importa come lo guardi, il retcode dovrebbe essere guardato.
Non so di cosa stai parlando, e penso che abbiamo finito l'erba).
Guardate la discussione dall'inizio. ...Nessuno nega l'importanza del retcode, ma per soluzioni semplici se ne può fare a meno.
Quanto è critica questa opzione per voi?
c) Se la risposta è soddisfacente e non ci sono errori, otteniamo un biglietto. Si può usare l'ora corrente;
Quanto è critica questa opzione per te?
Questa è l'opzione standard (che ha i suoi svantaggi, menzionati sopra) + il tempo di risparmio di sé. Dato che non ho bisogno del controllo del retcode, l'unica domanda che rimane è sul risparmio di tempo: o da solo, o esteticamente con MqlTradeResult. In realtà, questo è il motivo della mia domanda :)
Se la richiesta ha successo, prima o poi il trade sarà nella storia e l'ordine apparirà nella lista. Di conseguenza, sarete in grado di scoprire esattamente cosa è successo e come è successo.
E la variante suggerita è per così dire "a breve termine", per coloro che vogliono ottenere tutti i dati necessari in una volta sola e non preoccuparsi di azioni inutili.
Naturalmente forse aggiungere qualcos'altro nel server di risposta, ma ci sono una serie di caratteristiche e ragioni per cui gli sviluppatori potrebbero non essere d'accordo con questa opzione (e la richiesta, scusa poco giustificata e confermata da argomenti convincenti).
PS
Anche se forse mi sono perso qualcosa e gli sviluppatori hanno deciso che è abbastanza ragionevole.