Auguri per MQL5 - pagina 28

 

forse questo è già stato detto....

1) aggiungere la capacità di compilare quando è criptato e con la possibilità di generare un numero di serie legato a un ID del computer (analogo a armandillo packer),

tutto questo dovrebbe essere fatto internamente al traduttore e non dal sorgente

2) Aggiungere la possibilità di lavoro interattivo con programmi esterni che permetterebbe di gestire il terminale da altri programmi, connettersi/disconnettersi al server, controllare la connessione al server, chiedere l'archivio delle quotazioni, fare un ordine... ecc.

3) possibilità di piazzare ordini indipendentemente dai tick in arrivo

4) Supporto del lavoro simultaneo con diversi DT/account

5) Rilanciare il debug della DLL

6) Aggiungere almeno il supporto delle strutture, in generale sarebbe auspicabile ampliare le possibilità, in modo che siano più vicine al c++

 

È necessario aggiungere un link eseguibile all'aiuto che il programma fornisce (per esempio, per aprire una finestra con il testo desiderato) e alla pagina web.

Se l'utente fa qualcosa di incomprensibile, il programma gli dice: ecco una consultazione sulla situazione, leggila bene e non fare più niente di stupido.

 

SK,

Per esempio, si dovrebbe impostare TP=2 e SL=10 una volta e poi solo comprare o vendere, cioè il pipsing sarà molto conveniente. A causa di questo inconveniente, ho recentemente creato un Expert Advisor appositamente per impostare TP e SL con i valori specificati dopo aver cliccato su Compra o Vendi.

 

Tanti auguri per tutto! Già 28 pagine!

Mi piacerebbe sapere dagli sviluppatori quali desideri sono già in sviluppo, quali non saranno mai implementati e quali potrebbero esserlo.

Altrimenti non è chiaro se dobbiamo desiderare qualcos'altro, non vediamo alcun feedback.

Naturalmente, vogliamo anche conoscere i tempi. Capisco che prevedere i termini del lancio di un software a volte non è più facile che prevedere il movimento dei tassi di cambio.

Almeno in questa forma: "La versione beta di MT5 sarà rilasciata non prima di .............". È possibile scrivere una frase del genere?

 
Better:

Altrimenti, non è chiaro se c'è altro da desiderare, non è visibile alcun feedback.


Beh, il fatto che l'argomento sia stato risolto indica che gli sviluppatori lo trovano utile :)
 
Si è parlato di riassegnare Magic in un ordine attivo? L'idea è semplice: nel trading multiperiodale sarà possibile passare l'ordine a un timeframe superiore quando c'è una tendenza lunga.
 
Cronex:
Si è parlato di riassegnare Magic in un ordine attivo? L'idea è semplice: nel trading multiperiodale, sarà possibile passare l'ordine a un timeframe superiore quando il trend è lungo.
Puoi essere un po' più specifico? Cosa vuoi dire?
 
SK. писал (а):
Cronex:
Si è parlato di riassegnare Magic in un ordine attivo? L'idea è semplice: nel trading multiperiodale sarà possibile passare l'ordine a un timeframe superiore quando c'è una tendenza lunga.
Puoi essere un po' più specifico? Cosa vuoi dire?

In breve: uso la stessa strategia di trading per 4 periodi, cioè principi di entrata/uscita/trailing usando un algoritmo (un set di indicatori e tipi di segnali), ma i parametri degli indicatori sono diversi per ogni periodo (in realtà significa 4 EA su un grafico), divisione per Magic. Il risultato è il seguente: a timeframes più bassi ci sono tutte le indicazioni per chiudere le posizioni molto prima di quanto la situazione del mercato meriti realmente (cioè ogni oscillazione verso il lato sbagliato si traduce in un profitto), anche se a timeframes più alti la situazione è molto stabile. Influisce sulla volatilità relativa degli indicatori. Penso che l'idea sia chiara - se si verificano situazioni stabili sui timeframe senior, le posizioni aperte su quelli junior non dovrebbero essere chiuse, ma cambiando Magic dovrebbero essere passate alla logica dei timeframe senior. L'applicazione è effettivamente utilizzata non solo per i tempi, ma per il trasferimento ad altre logiche di elaborazione. Mi sembra che non ci saranno problemi per la società di intermediazione, perché il biglietto rimane, e il profitto può essere trovato.
 
Cronex:
In breve: uso una singola strategia di trading per 4 periodi, cioè principi di entrata/uscita/trailing usando lo stesso algoritmo (un set di indicatori e tipi di segnali), ma i parametri degli indicatori sono diversi per ogni periodo (in realtà sono 4 Expert Advisors su un grafico), divisione per Magic. Il risultato è il seguente: a timeframes più bassi ci sono tutte le indicazioni per chiudere le posizioni molto prima di quanto la situazione del mercato meriti realmente (cioè ogni oscillazione verso il lato sbagliato si traduce in una presa di profitto), anche se a timeframes più alti la situazione è molto stabile. Influisce sulla volatilità relativa degli indicatori. Penso che l'idea sia chiara - se si verificano situazioni stabili sui timeframe senior, le posizioni aperte su quelli junior non dovrebbero essere chiuse, ma cambiando Magic dovrebbero essere passate alla logica dei timeframe senior. L'applicazione è effettivamente utilizzata non solo per i tempi, ma per il trasferimento ad altre logiche di elaborazione. Mi sembra che non ci sarà un problema per DC, perché il biglietto rimane, e potremmo ottenere qualche profitto.


Il significato è chiaro.

Ma non credo che ci sia bisogno di cambiare il linguaggio e la tecnologia di comunicazione tra il terminale e il server per il bene di questa idea. Dopo tutto, tutto ciò di cui avete bisogno può essere contabilizzato nel programma sul lato del terminale. Inoltre, l'idea stessa di cambiare il majik è una prova eloquente della strategia sottosviluppata, dei suoi criteri. La magia (come mostra chiaramente il tuo esempio) non sopporta e non può sopportare un criterio fisso per chiudere o aprire un ordine. Semplicemente perché un majik non è legato al mercato in alcun modo.

Secondo me, questo è uno dei punti chiave del trading. Ci è capitato di avere una magia tra le mani e ci siamo legati ad essa. In effetti, dovremmo considerare la situazione su ogni nuovo tick come una nuova situazione senza alcuna preistoria (storia degli eventi sul conto di gioco, compresi il tempo e il prezzo degli ordini di mercato di apertura ).

E la magia è, anche se in parte utile, ma secondo me, non un meccanismo molto comodo per tenere traccia di... chissà cosa. Credo che se un ordine potesse essere identificato in modo univoco (alla riapertura e alla chiusura parziale), la magia non avrebbe più senso.

 
SK. писал (а):


Il punto è chiaro.....

Cercherò di fare degli argomenti, comincerò dalla fine...

Secondo me, se accettiamo l'ordine come un oggetto, allora la magia al momento è una proprietà completamente variabile di questo oggetto dal punto di vista della programmazione, così come i livelli SL o TP. Potrei sbagliarmi, ma attualmente è impossibile identificare chiaramente l'ordine in MQL in relazione al codice eseguito nel terminale in tutte le possibili fasi della sua vita (alla riapertura e alla chiusura parziale) e la magia compensa in gran parte questa situazione. La magia non dovrebbe essere attaccata al mercato - ha semplicemente un'altra applicazione e non ha senso se non per il suo significato.

Non sono d'accordo con lei nel considerare la situazione del mercato come una situazione senza storia... Ma questa è la mia opinione personale. Se l'ordine è redditizio dovremmo guardare il timeframe più alto per prendere una decisione e aspettare un piccolo pullback e continuare a lavorare con l'ordine a un timeframe più alto o semplicemente chiuderlo perché non pagherà.

Non ho intenzione di discutere sulla solidità e la povertà della strategia - sono totalmente d'accordo... Ma ci sto lavorando :-)

Cambiare la lingua e il protocollo di scambio tra il server e il terminale, beh, non so... Al momento il valore majic è già presente e viene accettato dal server quando si effettua un ordine. Non conosco il formato del protocollo di scambio, ma sospetto che sia una trasmissione in batch di qualche struttura di dati tramite trasporto con successiva verifica di coerenza. Penso che non sia troppo difficile aggiungere un altro parametro opzionale alla struttura dei dati trasmessa da OrderModify. Dubito profondamente che gli sviluppatori abbiano preso la strada del protocollo di scambio atomico e si siano così impantanati nel pesante processo di supporto delle versioni.

Ma in generale ho solo chiesto dei piani :-) No quindi no.