Errori, bug, domande - pagina 989

Nuovo commento
 

No, tutte le macchine sono individuali. Anche gli assi sono autorizzati, da grusha a WS. Ho un senso di presunzione di colpa... Dovrò trovare delle scuse... Giustificarmi... Registri, questo e quello...

Vendere più agenti di blocco che nuclei dovrebbe essere vietato e basta!

 
muallch:

...

E mettere più agenti di blocco che nuclei dovrebbe essere vietato per legge, tutto qui!

È logico in generale.
 

Buon pomeriggio. Ho una domanda per gli sviluppatori. Il ciclo ideale di generazione delle transazioni consiste nei seguenti passi:

1.Invio di una richiesta tramite OrderSend() seguito dal controllo che il metodo ha restituito true e retcode corretto.

2.Successivamente, è necessario tracciare il passaggio della richiesta sul server tramite OnTradeTransaction(). Questo gestore è molto comodo e dà il pieno controllo del processo.

Ma noi viviamo nel mondo reale e per esempio a causa di un errore di connessione o semplicemente perché la transazione è stata "persa alla consegna" potremmo non aspettare una transazione come TRADE_TRANSACTION_REQUEST. Così, il ciclo di attesa diventerà infinito e sarà impossibile determinare se la transazione ha completato la richiesta o no.

Esiste una procedura di BACKGROUND per gestire tali emergenze con l'ottenimento inequivocabile di un completamento del processo logicamente corretto per qualsiasi forza maggiore? Per esempio, se non aspettiamo TRADE_TRANSACTION_REQUEST entro 20 (o 30 o 40) secondi, allora passiamo a un algoritmo più lento ma corretto, cioè: confrontiamo il volume attuale del simbolo con il volume prima di OrderSend(), cerchiamo la cronologia degli ordini e calcoliamo il suo stato e decidiamo se fare un'altra richiesta di apertura o saltare il segnale. Il compito diventa ancora più complicato per il metodo OrderSendAsync(): dobbiamo avere un criterio preciso di quando un certo ordine non è scattato e sapere quando iniziare ad applicare tale criterio. Se ho capito qualcosa di sbagliato, per favore correggetemi.


 
M24:

Per il metodo OrderSendAsync(), il compito è ancora più complicato - dobbiamo avere un criterio esatto per non far scattare un ordine specifico e sapere quando iniziare ad applicare tale criterio. Se ho capito qualcosa di sbagliato, per favore correggetemi.

HistorySelectByPosition - in teoria, dovrebbe aiutare, l'id è dato quando l'ordine viene inviato.

 
Perché l'asse verticale in un indicatore può scomparire insieme alla visualizzazione dell'indicatore? Questo non succede negli indicatori di base, ma c'è un tale problema in quello creato. Ad alcuni valori di scorrimento orizzontale, per così dire, e di ingrandimento della lente, l'immagine scompare.
 

VanHelsing:

I sistemi Win7 32x hanno problemi con le operazioni con i numeri reali, su XP si rifiuta di funzionare quando si passano valori alla libreria"wininet.dll".

dove si passano i numeri reali in wininet?
 
papaklass:

1. Fate in modo che la regola sia quella di inviare gli ordini di compravendita sul tick corrente e controllare la loro esecuzione sul tick successivo. Allora non avrete loop infiniti.

2. Quando si controlla l'esecuzione di ordini dati durante il tick precedente, non ci si preoccupa di OnTrade()/ OnTradeTransaction(). Controlla i cambiamenti nello stato del tuo account, cioè lavora con la fonte. Dopotutto, qualsiasi accordo commerciale ha lo scopo di cambiare uno stato del vostro conto di trading. Quindi controlla il cambiamento dello stato.

3. A seconda dei risultati dei test e fare ulteriore logica del vostro robot.

Prima di usare funzioni come OnTrade()/OnTradeTransaction(), decidete cosa è più importante per voi:

a). per ottenere l'apertura/chiusura/modifica di una posizione a determinate condizioni di mercato;

b) Sprecare il tuo tempo cercando di capire il motivo per cui il tuo ordine di trading non è stato eseguito, e cercando qualcuno da incolpare.

Eppure, mi rimane un po' di incomprensione. Se i risultati del controllo al prossimo tick NON mostrano alcun cambiamento nella posizione, allora cosa dovremmo fare in questo caso. Le ragioni dell'assenza di cambiamenti possono essere molto diverse. In alternativa:

un ordine su richiesta è stato formato sul server, ma è stato rifiutato per qualche motivo,

il server è sovraccarico - l'esecuzione è ritardata,

la connessione viene persa per qualche tempo.

Vorremmo avere un criterio preciso per la mancata esecuzione dell'ordine. Legarsi al tempo in un sistema asincrono non mi sembra molto accurato e quindi permette l'incertezza. Forse ha senso selezionare l'ordine dalla cronologia e controllare il suo stato, o, come suggerito da sion, usare HistorySelectByPosition. Presumo che se gli sviluppatori hanno progettato questo sistema in questo modo, allora ci dovrebbero essere metodi "corretti" per gestire tali operazioni con le chiavi.

 
M24:

Vogliamo avere un criterio preciso per l'ordine da non eseguire

Vi è già stato spiegato che


non preoccupatevi di OnTrade()/ OnTradeTransaction().

Lavorare con il codice sorgente.

quindi seleziona l'ordine e controlla il suo stato
 

Ciao a tutti!

Come posso fare in modo che tutto il contenuto della scheda "Esperti" sia sovrascritto all'avvio dello script? (Come il comando cls), perché può essere difficile distinguere dove è finito l'output di stampa dall'inizio precedente dello script e quello attuale.

Grazie!!!

 
ns_k:

Ciao a tutti!

Come posso fare in modo che tutto il contenuto della scheda "Esperti" sia sovrascritto all'avvio dello script? (Come un comando cls), perché può essere difficile distinguere dove è finito l'output di stampa dall'inizio precedente dello script e quello attuale.

Grazie!!!

Aggiungere la seguente linea allo script deinit

Print("===================== La fine ===================")

1...982983984985986987988989990991992993994995996...3184
Nuovo commento