Funzione OrderSendAsync() - pagina 5

 
Urain:

Se la tua proposta completerebbe solo una funzione esistente allora niente, altrimenti non è chiaro come una semplice struttura MqlPacketTradeRequest ...

... Se la struttura di MqlPacketTradeRequest è la struttura dell'array dinamico di strutture MqlTradeRequest, può rompere l'intera logica del server inondato con strutture di query semplici.

altrimenti, a livello di terminale dovremmo dividere questo pacchetto in richieste separate, il che annullerebbe l'intero scopo di introdurre questo sovraccarico.

Sembra che ci siamo "accordati" su una tale variante a causa della struttura asincrona:

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

Dove,

packet_request includerà tra le altre cose un array di strutture MqlTradeRequest...

Allora tutti questi pensieri sono materia prima per la discussione :-)

 
Urain:

IMHO un lotto di applicazioni identiche è necessario solo a scopo dimostrativo, per il lavoro si useranno applicazioni di simboli diversi, con volumi diversi e naturalmente direzioni diverse. E quindi ogni richiesta dovrà essere controllata separatamente, quindi non ha senso inviarle in blocco.

Beh, qui bisogna scegliere: una tantum della funzione OrderSendPacketAsync(MqTradeRequest& request[], MqlPacketTradeResult& packet_result) che invia un array precompilato request[] di 500 elementi alla volta con un controllo unico di codice di ritorno 10008, o 500 volte avviando la funzione OrderSendAsync() con 500 volte controllando il codice di ritorno 10008.
Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Urain:

...se la struttura MqlPacketTradeRequest è la struttura di un array dinamico di strutture MqlTradeRequest, può rompere l'intera logica di un server che è stato progettato per strutture di query semplici.

Come può una richiesta di commercio che usa un array dinamico "rompere la logica del server"? Se ho un blocco che elabora una variabile di un certo tipo di struttura, cosa mi impedisce di applicare questo blocco a ogni elemento di un array dello stesso tipo? Allo stesso modo, se oggi un server è "orientato verso strutture di query semplici", cosa mi impedisce di aggiungere un ciclo, che quando un server accetta un array dinamico inviato dalla funzione OrderSendPacketAsync(), permetterà di applicare a sua volta un blocco "orientato verso strutture di query semplici" ad ogni elemento di tale array?
 
papaklass:

Secondo me, la funzione OrderSendAsync() dovrebbe essere resa parametrica invece di creare un ciclo per l'invio degli ordini. Per esempio OrderSendAsync(Symbol(), numero, direzione). Come parametri: - simbolo, - numerodi ordini, - direzione degli ordini (comprare, vendere).

Questo è simile a un caso speciale di invio di una richiesta di compravendita di massa usando un array dinamico e la funzione OrderSendPacketAsync(), quando i campi'symbol' e 'type' sono gli stessi perogni elemento dell'array dinamico .
 

Quando si conducono operazioni asincrone, non sappiamo esattamente come una particolare richiesta sia stata innescata. In particolare, non sappiamo quanto volume era in sospeso quando una delle richieste asincrone è stata parzialmente eseguita.

Potete dirmi se ho capito bene che sia nel forex trading che nel trading azionario, l'ordine dalla proprietà storica

VOLUME D'ORDINE CORRENTE

Volume non riempito

ci permette di determinare senza ambiguità come una richiesta asincrona è stata eseguita completamente? Cioè, è corretto che quando un ordine di mercato viene inviato in modo asincrono nel mercato forex, quando appare nella cronologia, possiamo essere sicuri che se ORDER_VOLUME_CURRENT==0.0, l'ordine è stato completamente eseguito, ma se ORDER_VOLUME_CURRENT contiene un valore diverso da zero, allora questo valore dovrebbe essere considerato come il volume non completato per quell'ordine di mercato forex?

La domanda è motivata dal fatto che qui: https://www.mql5.com/ru/forum/3775/page28#comment_84851 sottolinea che la proprietà ORDER_VOLUME_CURRENT si riferisce agli ordini utilizzati nel mercato azionario.

 

Domanda sulla richiesta asincrona che appare nella cronologia.

Quando OrderSendAsync() restituisce true e il campo result.retcode contiene 10008, allora secondo il Riferimento, "significa che la richiesta è stata inviata, ma non garantisce che abbia raggiunto il server di trading".

Domanda: se una richiesta asincrona viene inviata con successo dal terminale, ma non raggiunge il server, tale richiesta finirà sempre nella cronologia? In altre parole, può succedere che una richiesta asincrona sia inviata con successo (secondo tutte le indicazioni) al server, ma le informazioni su di essa non appaiono nella cronologia? Se questo scenario è possibile, a quali condizioni?

Документация по MQL5: Торговые функции / OrderSend
Документация по MQL5: Торговые функции / OrderSend
  • www.mql5.com
Торговые функции / OrderSend - Документация по MQL5
 
Yedelkin:

Domanda: se una richiesta asincrona è stata inviata con successo dal terminale, ma non ha raggiunto il server, le informazioni su tale richiesta appariranno sempre nella storia? In altre parole, può succedere che una richiesta asincrona sia inviata al server con successo (in tutti gli aspetti), ma le informazioni su di essa non appaiono nella storia? Se questo scenario è possibile, a quali condizioni?
Se la richiesta non raggiunge il server, non ha alcuna possibilità di apparire nel terminale del cliente.
 
Renat:
Se la richiesta non raggiunge il server, non ha alcuna possibilità di apparire nel terminale del cliente.
Ops! Si scopre che una richiesta asincrona inviata con successo può facilmente perdersi e non apparire nella storia.
Документация по MQL5: Торговые функции / OrderSendAsync
Документация по MQL5: Торговые функции / OrderSendAsync
  • www.mql5.com
Торговые функции / OrderSendAsync - Документация по MQL5
 
Yedelkin:
Ops! Si scopre che una richiesta asincrona inviata con successo può facilmente perdersi e non entrare nella storia.
no.
 
Yedelkin:
Si scopre che una richiesta asincrona inviata con successo può facilmente perdersi e non entrare nella storia.

Il punto è che una richiesta asincrona non ha praticamente nessuno stato "inviato con successo".

Il completamento riuscito della funzione significa solo che "l'ordine sembra corretto dal punto di vista del cliente ed è stato gettato nel tubo della rete, aspetta una risposta in OnTrade".