Funzione OrderSendAsync() - pagina 4

[Denis Kirichenko]

Colleghi, cosa ne pensate di questa idea? In tale struttura(MqlPacketTradeResult) si può scrivere un campo che indica il numero di ordini completati, ecc.

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   MqlPacketTradeResult&   packet_result        // пакетная структура ответа
   );

[Yedelkin]

denkir:

Colleghi, cosa ne pensate di questa idea? In tale struttura(MqlPacketTradeResult) si può scrivere un campo che indica il numero di ordini completati , ecc.

Ma per fare questo, dovremmo aspettare una risposta dal server nella funzione OrderSendAsync(). E l'asincronicità della funzione OrderSendAsync() verrà meno. Renat ha già promesso che ci saranno altre funzioni che possono essere usate per provare a fare casino dopo che OrderSendAsync() è stato attivato.

[Denis Kirichenko]

Yedelkin:
Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().

Sì, non avevo pensato all'asincronia...

Questo è tutto, allora:

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   );

bool  OrderReceiveAsync(
   MqlPacketTradeResult&   packet_result        // пакетная структура ответа
   );

[Rashid Umarov]

denkir:

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.

[Yedelkin]

denkir:

Sì, non avevo pensato all'asincronia...

Questo è tutto, allora:

Bene, allora già OrderSendPacketAsync(), OrderReceivePacketAsync :) In modo che sia ancora possibile inviare una singola richiesta in modalità asincrona già esistente, e cercare informazioni su di essa dopo.

[Yedelkin]

Rosh:

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.)

Quindi, suggerisce di usare in OnTrade() qualche funzione OrderReceiveXXX() per permetterci di reagire non a tutti gli eventi Trade in arrivo ma solo a quelli che appartengono alle code asincrone.

[hrenfx]

Rosh:

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à.

[Mykola Demko]

denkir:

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.

[Denis Kirichenko]

Urain:

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.

E che cosa vi impedisce di riempire ciclicamente ogni regresso ? E poi altrettanto ciclicamente elaborare ogni risultato?

[Mykola Demko]

denkir:
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 ...

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   MqlPacketTradeResult&   packet_result        // пакетная структура ответа
   );

... 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.