Il mio approccio. Il nucleo è il motore. - pagina 145
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
Presumo che ogni flusso da e verso il motore dovrebbe avere una specie di tratto di flusso, una specie di numero magico, e un tratto di flusso che funziona con il tester (è invariabilmente unico). Il motore reagisce al flusso attualmente impostato e ai consiglieri, gli indicatori reagiscono al loro attributo (numero pseudo-magico) dell'infostream.
Tutto funziona bene nel tester ora, sto controllando l'Expert Advisor nel tester da un'altra finestra. È in modalità simulatore.
Attualmente, i messaggi tra l'EA e il motore non sono legati a un certo mago o nome dell'EA. Significa che se il motore scrive informazioni in una risorsa, queste saranno lette da qualsiasi Expert Advisor che è stato impostato per la comunicazione. Per separare i flussi di comunicazione, ogni EA deve definire un'etichetta speciale nell'intestazione del messaggio. E poi, o leggere e seguire le istruzioni o ignorarle. Ci dovrebbe essere un'etichetta separata per gli Expert Advisors nel tester.
Ma qui vediamo la necessità di una GUI universale per il motore attraverso la quale possiamo configurare e commutare la comunicazione. Anche per ricevere informazioni sugli Expert Advisors.
Quindi, dobbiamo cambiare il concetto di EAs. Per essere più precisi, dobbiamo aggiornarlo.
Ecco il problema.
Dobbiamo avere una GUI personalizzata per ogni EA o una GUI comune per tutti. Se è comune, allora dovrebbe essere invariante. Deve essere ben pensato in anticipo. Ogni Expert Advisor (anche senza la GUI), deve avere delle leve interne che fornirà al motore.
Qualcosa a cui pensare...
Ma qui arriviamo alla necessità di una GUI universale per il motore, attraverso la quale configurare e commutare la comunicazione. Inoltre, per ricevere informazioni sugli EA.
Ci deve essere semplicemente una parte amministrativa necessaria e sufficiente progettata e configurata in modo permanente nel motore, che si occupa dell'amministrazione del controllo e la parte personalizzata più varia, costruita secondo il progetto del cliente.
È sufficiente che ci sia una parte amministrativa necessaria e sufficiente progettata e configurata in modo permanente nel motore, che si occupa dell'amministrazione della gestione e una grande varietà di parti personalizzate, costruite secondo il progetto del cliente.
Questa parte amministrativa non è comprensibile. Cosa dovrebbe essere?
Se il motore funziona con un solo Expert Advisor, è una cosa. E se funziona con diversi, è un'altra cosa.
Manca ancora un quadro concettuale...
Questa è la parte amministrativa che non è chiara. Cosa dovrebbe essere?
Se il motore funziona con una EA, è una cosa. Se funziona con diversi, è un altro.
Finora, manca un quadro concettuale...
Diciamo qualcosa del genere.
E nell'Expert Advisor o indicatore nelle impostazioni di partenza, lo stesso campo "Oggetto 1", ecc.
Diciamo qualcosa del genere.
E nell'EA o indicatore nelle impostazioni di partenza lo stesso campo "Oggetto 1" ecc.
Mi chiedo. Vuoi dire che dovremmo cambiare la connessione con questi pulsanti? Ma, in questo caso, tutti gli Expert Advisors devono essere copie di un EA in esecuzione su coppie diverse.
E se gli Expert Advisors sono diversi?
Diciamo qualcosa del genere.
E nell'EA o indicatore nelle impostazioni di partenza lo stesso campo "Oggetto 1", ecc.
Lo implementerò per primo. Con un EA su coppie diverse. E poi capirò come affrontare i diversi EA.
A proposito, ecco una buona dimostrazione del lavoro con il costruttore. Dinamico, senza parole e in musica. :)
CREAZIONE DI VISUAL STUDIO
https://www.mql5.com/ru/blogs/post/712102
A proposito, ecco una buona dimostrazione del lavoro con il costruttore. Dinamico, senza parole e in musica. :)
STUDIO VISIVO
Originale.
Supponiamo qualcosa del genere.
E nell'EA o indicatore nelle impostazioni di partenza lo stesso campo "Oggetto 1", ecc.
Questi sono contrassegnati come collegati al controllo. E c'è solo un oggetto che è controllato. Quindi c'è un interruttore a levetta da qualche parte con una grande indicazione.
Questi sono contrassegnati come collegati al controllo. Ma c'è un controllo che è specificamente controllato. Quindi c'è un interruttore a levetta da qualche parte con una grande indicazione.
Ogni EA ha la sua copia del kernel dei parametri. Può essere temporaneamente scollegato dalla GUI comune e collegato al motore da un altro EA. È importante che siano copie dello stesso EA.
Tuttavia, ci sono alcune difficoltà qui che io stesso non capisco ancora del tutto.
In teoria, la domanda suona così:
Perché abbiamo bisogno di aggiungere un motore con GUI per ogni grafico di una copia di EA se possiamo fare un motore con la GUI comune e collegarlo a tutte le copie dell'EA?
In pratica, incontreremo alcune difficoltà tecniche.
La copia di Expert Advisor può scrivere nuovi valori nella sua copia del kernel dei parametri. Se una delle copie non si collega al motore, il kernel cambierà solo sul lato della copia. Così, quando ci ricolleghiamo, dobbiamo passare l'intero kernel al motore e il motore ridisegnerà tutti gli elementi in tutte le finestre dove richiesto. Questo è possibile in linea di principio.
O rifare il kernel dei parametri stesso rendendolo una risorsa. In questo caso, il motore riceverà tutte le modifiche in una volta sola e ridisegnerà semplicemente gli elementi. Questa non è una cattiva idea.
Ma cosa ci dà?
Forse riduciamo il carico della CPU e liberiamo i thread. Se abbiamo 10 copie di EA in esecuzione su 10 coppie e carichiamo ogni motore con la GUI, il carico totale della CPU potrebbe essere eccessivo. Perché ogni GUI richiede il ridisegno degli elementi e questo è un carico pesante per la CPU. Ma in realtà possiamo vedere solo una GUI concreta di una copia. Gli altri sono nascosti.
Quindi è probabilmente la strada giusta da percorrere. Fare un motore comune.