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
Colleghi, cosa ne pensate di questa idea? In tale struttura(MqlPacketTradeResult) si può scrivere un campo che indica il numero di ordini completati, ecc.
Colleghi, cosa ne pensate di questa idea? In tale struttura(MqlPacketTradeResult) si può scrivere un campo che indica il numero di ordini completati , ecc.
Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().
Sì, non avevo pensato all'asincronia...
Questo è tutto, allora:
Sì, non avevo pensato all'asincronia...
Bene, ecco qui:
Asincrono significa lavorare senza aspettare una risposta. Spara (OrderSenAsync) ed esegue, senza provare a vedere se il bersaglio viene colpito. Perché non c'è tempo.
Una risposta indiretta sarebbe un suono che arriva dopo (OnTrade) - forse il colpo ha colpito il bersaglio, o forse qualcosa è appena caduto. Questo è il luogo in cui puoi guardare fuori e vedere (controllare tutti gli ordini, le compravendite, le posizioni, ecc.) se lo desideri.
Sì, non avevo pensato all'asincronia...
Questo è tutto, allora:
Una risposta indiretta è un suono che arriva dopo (OnTrade) - forse il colpo ha raggiunto il bersaglio, o forse qualcosa è appena caduto. Qui è dove si può guardare fuori se lo si desidera (controllare tutti gli ordini, le compravendite, le posizioni, ecc.)
Asincrono significa lavorare senza aspettare una risposta. Spara (OrderSenAsync) ed esegue senza provare a vedere se il bersaglio viene colpito. Perché non c'è tempo.
Una risposta indiretta è un suono successivo (OnTrade) - può essere che il colpo abbia colpito il bersaglio o che qualcosa sia semplicemente caduto. Qui è dove si può guardare fuori se si vuole (controllare tutti gli ordini, compravendite, posizioni, ecc.).
Ti sbagli o a causa della tua poca esperienza nel trading in modalità asincrona o a causa della debole funzionalità di MT5 per questo tipo di operazioni.
Non avete bisogno dell'asincronia per il gusto dell'asincronia. E si usa solo quando è redditizio. Per esempio, nel trading di un portafoglio, quando il portafoglio ha bisogno di essere comprato o ribilanciato qui e ora. In altre parole, una dozzina di ordini di trading per diversi simboli ai prezzi correnti.
E nessuno lo farà, se si tratta l'asincronia nel modo che hai descritto - spara e dimentica. E le reazioni ai colpi dovrebbero essere valutate sulla base delle posizioni nette attuali. Le reazioni dovrebbero essere specifiche per ogni ordine di compravendita.
Se c'è stato un reindirizzamento, dovremmo esserne informati, o dovremmo ricevere un'altra risposta. Non dobbiamo chiederci se c'è stata o meno una nuova offerta, dato che la posizione netta non è cambiata per un secondo o due.
Nella prima pagina di questa discussione ci sono diagrammi e messaggi-eventi in arrivo. Non sono apparsi dal nulla, ma con anni di esperienza asincrona. Quindi vale la pena prestare attenzione a tale architettura senza schizzinosità.
Colleghi, cosa ne pensate di questa idea? In tale struttura(MqlPacketTradeResult) si può scrivere un campo che indica il numero di ordini completati, ecc.
Si presume che il lotto di ordini abbia sempre gli stessi campi?
IMHO un lotto delle stesse richieste è necessario solo a scopo dimostrativo, per il lavoro saranno utilizzate richieste di caratteri diversi, con volumi diversi e naturalmente direzioni diverse. E di conseguenza ogni richiedente dovrà essere controllato separatamente, quindi non ha senso mandargli un lotto.
E quello che supponi è solo un legame del ciclo for.
Sta suggerendo che una pila di domande ha sempre gli stessi campi compilati?
IMHO un lotto di applicazioni identiche è necessario solo a scopo dimostrativo, applicazioni con caratteri diversi, volumi diversi e naturalmente direzioni diverse saranno utilizzate per il lavoro. E di conseguenza ogni richiedente dovrà essere controllato separatamente, quindi non ha senso mandargli un lotto.
E quello che supponi è solo un legame del ciclo for.
Che cosa gli impedisce di riempire ciclicamente ogni registro ? E poi altrettanto ciclicamente elaborare ogni risultato?
Se la tua proposta sarà solo complimentarmi con la funzione esistente, niente, altrimenti non è chiaro come struttura semplice MqlPacketTradeRequest ...
... Se la struttura MqlPacketTradeRequest è la struttura di un array dinamico di strutture MqlTradeRequest, può rompere tutta la logica del server che è progettato per strutture di query semplici.
Altrimenti, a livello di terminale dovremmo dividere questo batch in richieste separate, il che annulla l'intero scopo di introdurre questo sovraccarico.