Domande da un "manichino" - pagina 12
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
SI PREGA DI CONSIGLIARE IL TERMINALE DI TELEFONIA MOBILE.
QUANDO E QUANDO SARÀ REALIZZATO QUALSIASI SUPPORTO PER GLI INDICATORI UTENTE (NON STANDARD) O ADVISORI SU mql4 O mql5?????????????????????????????
SU QUALI PIATTAFORME (ANDROID PER ESEMPIO) QUESTO SARÀ IMPLEMENTATO????????????????? E PER QUANTO TEMPO ?????????????
in attesa di risposta, grazie per l'avviso
Interesting:
Beh, non sono d'accordo con questa conclusione. OCO == "uno annulla l'altro". Beh, non c'è una cosa del genere in MT5 dove un ordine annulla l'altro. L'ho rimpianto per un anno.Caratteristiche come SL e TP chiudono davvero una posizione aperta, ma la questione della "cancellazione" degli ordini pendenti non ha nulla a che fare con questo.
Lo fanno, ma questi ordini sono implementati sul server. E sono gli unici effettivamente integrati nello schema OCO finora (e non ci sogneremmo mai di implementare gli ordini "If Done" direttamente nel terminale e sul server).
Quando si apre una posizione e si impostano TP e SL in MT5 si usa essenzialmente la stessa forma (ma il risultato qui è una posizione + 2 ordini di cancellazione).
Dopo il tuo messaggio, ho già commentato questa situazione prendendo in considerazione il SL e il TP annullati in modo intercambiabile. Tuttavia, vorrei aggiungere quanto segue.
Se agli autori degli ordini OCO fosse stato detto che nel 21° secolo la loro invenzione sarà applicata solo ai livelli di SL e TP, sarebbero stati molto sorpresi di vedere così tanto limitata l'area di applicazione della loro invenzione :) .In effetti, tutto è al contrario: tutti i materiali che leggete si riferiscono alla stessa cosa: gli ordini CCA sono ordini intercambiabili i cui tipi sono ora specificati nell'enumerazione MQL5 ENUM_ORDER_TYPE. Non ho mai incontrato alcuna menzione della connessione tra gli ordini CCA e i livelli SL-TP. Quindi, il meccanismo di esecuzione può essere lo stesso ma sono gli ordini ENUM_ORDER_TYPE che il cliente esegue ma non i livelli SL-TP (secondo MQ).
Quindi quando scrivo di ordini pendenti intendo ordini dalla lista ENUM_ORDER_TYPE e non ordini "derivati" basati su livelli SL-TP.
______________
* Il "derivato" perché ognuno degli ordini OCO può avere diversi livelli di SL-TP.
Signori, la radice della comprensione sta nella semplicità della piattaforma. Semplicità per il 99% degli utenti e rifiuto consapevole delle complicazioni che la restante percentuale di utenti può comprendere.
Fatevi la domanda "cosa ci vorrebbe per attirare X milioni di utenti sui mercati finanziari? Con abbastanza esperienza, la risposta sarà vicina a "fare un sistema semplice, eliminando la complessità e unendo i commercianti in un unico ecosistema".
Invece di accumulare le impostazioni degli ordini OCO (il pannello non è davvero per la mente media) abbiamo offerto uno schema di gestione degli ordini molto semplice e diretto con SL/TP integrato. La stragrande maggioranza degli ordini OCO sono solo SL/TP per le posizioni correnti. Mettendo SL/TP all'interno abbiamo ridotto al minimo il numero di ordini aggiuntivi e semplificato notevolmente la gestione degli affari.
ps: il problema del sistema degli ordini è chiuso
ps: il problema del sistema degli ordini è chiuso
ps: il problema del sistema degli ordini è chiuso.
È un peccato che non sarà possibile fare SLs/TPs normali (affidabili) per singoli trade (non posizioni totali).
Questo elimina immediatamente la possibilità di negoziare (in modo affidabile) strategie multiple sullo stesso strumento/conto.
Hali-vor non dovrebbe essere ripreso, ricordo il parere degli sviluppatori (uno strumento = una posizione = uno SL e un TP)...
A quale tipo (long o ulong) appartiene effettivamente ORDER_MAGIC?
ENUM_ORDER_PROPERTY_INTEGER
ORDINE_MAGICO
Identificatore dell'Expert Advisor che ha piazzato l'ordine (destinato a ogni esperto per mettere il proprio numero unico)
lungo
A quale tipo (long o ulong) appartiene effettivamente ORDER_MAGIC?
ENUM_ORDER_PROPERTY_INTEGER
ORDINE_MAGICO
Identificatore dell'Expert Advisor che ha piazzato l'ordine (destinato a ogni esperto per mettere il proprio numero unico)
lungo
Penso che il risultato dovrebbe essere convertito al tipo dichiarato nel codice (ci può essere un errore di stampa nella documentazione).
Se stiamo parlando di MqlTradeRequest, in questo caso è molto probabilmente (ulong).
Secondo me, il risultato dovrebbe essere convertito al tipo dichiarato nel codice (potrebbe esserci un errore di stampa nella documentazione).
Per quanto riguarda MqlTradeRequest, in questo caso è più probabile (ulong), ma probabilmente long andrà bene senza problemi.
In generale, la risposta non è nel merito. La domanda era molto chiara: "a quale tipo (long o ulong) appartiene effettivamente ORDER_MAGIC?".
Cerchiamo di essere concreti:
1. Entrambi questi tipi possono essere dichiarati senza trasformazioni.
2. Se usate solo valori positivi di magik, è più vantaggioso specificare il suo valore come ulong (perché c'è una gamma di valori possibili da 0 a 18 446 744 073 709 551 615).
3. D'altra parte, la classe CExpert della Standard Library applica il valore lungo nell'inizializzazione (che permette di specificare valori negativi, ma sposta la gamma di valori possibili). Così, quando si inizializza questa classe, il valore di magik può già essere da -9 223 372 036 854 775 808 a 9 223 372 036 854 775 808.
Questa dichiarazione dovrebbe essere controllata.
4. Ma la classe CTrade (della stessa libreria standard) ha già un valore ulong come dovrebbe essere basato sulla struttura della query.
Facciamo alcune conclusioni preliminari:
a) Il lavoro con magik nelle classi CExpert e CTrade non è coerente, poiché nel primo caso viene specificato long, mentre nell'altro ulong;
b) Le classi in questione sono state sviluppate da persone diverse, o l'insieme e la struttura dei parametri per certe funzioni in CExpert sono stati scritti con CTrade in mente (che può essere esistito o meno in passato).
c) Il lavoro degli esperti associati allo sviluppo e alla documentazione della libreria standard non è completamente coerente (anche se per lo più si è visto uno studio abbastanza buono delle questioni chiave).
d) Se ho capito bene, l'interazione di queste due classi limita il valore del mago a un intervallo da 0 a 9 223 372 036 854 775 808. Questa dichiarazione deve essere verificata.
5. La struttura MqlTradeRequest ha il tipo ulong per lavorare con magik. Tutto è pienamente coerente con la classe CTrade, ecco perché è più logico specificare la gamma di valori possibili di mago da 0 a 18 446 744 073 709 551 615 se usiamo solo questa classe. Questa dichiarazione dovrebbe esserecontrollata.
PS
Credo che gli sviluppatori abbiano intenzionalmente "bloccato" i possibili valori di un mago nella gamma da 0 a 9 223 372 036 854 775 808.
Gli sviluppatori sembrano aver deliberatamente "stipato" i possibili valori di un magik in una gamma da 0 a 9 223 372 036 854 775 808.
In realtà, ci sono ben 8 byte di informazioni date alla magia, che possono essere interpretate come si vuole. Può essere datetime, double, 4 short, 8 char, o 64 bit bit per bit.
Con i quattro, 4 byte di magia erano sufficienti per codificare qualsiasi cosa, ma ora ne abbiamo 8. Tutto ciò che serve è la volontà.