Creazione di una GUI per MQL in modalità grafica. - pagina 14
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
Ho un TS esterno, non ho bisogno di un feedback GUI dal terminale.
Quindi non usate un terminale? Stai commerciando telepaticamente?
Quindi non usate un terminale? Commerciare telepaticamente?
Onestamente non ho sentito il bisogno di allegare moduli ai grafici.
C'è un grafico attivo che è direttamente collegato al grafico (tutti i tipi di linee, didascalie, scritte e così via).
Ma ci sono controlli GUI - impostazioni, rapporti, statistiche. E sono abbastanza grandi ed è un crimine contro l'utente metterli dentro un grafico :-)
Basta posizionare il modulo sopra il grafico. Sarà necessario rimuovere il modulo dal gestore delle finestre e tenere traccia dei cambiamenti nella geometria del grafico e del focus.
aggiornamento/per mettere il modulo - per mettere RectLabel sul grafico e nel grafico-eventi per tracciare il cambiamento delle coordinate. Quando lo cambiate, mettete il vostro modulo rigorosamente sopra :-) Avete bisogno di un po' di tamburello quando cambiate scheda, minimizzate la finestra, per nascondere il vostro modulo in tempoUn tale "tramonto a mano" :-) Almeno non entrerete nelle viscere di MetaTrader e non imporrete nuovi brividi e ganci alle sue finestre - cioè vi comporterete decentemente
Qualsiasi GUI chiamata dalla DLL ha la caratteristica più sgradevole - gli Expert Advisors/indicatori che la chiamano si riavviano periodicamente a causa del minimo starnuto. Il che porta alla riapertura dei moduli e a cascate di linguaggio scurrile...
Forse i "servizi" (o come si chiamano) annunciati da tempo saranno privi di questo inconveniente.
Non sono d'accordo. Se gli ordini vengono aperti tramite GUI, come nel tuo primo esempio, il modulo corrispondente dovrebbe appartenere al grafico corrispondente. Per esempio, avete 5 grafici aperti e di questi 5, si aprono i moduli di gestione degli ordini (non i rapporti o le impostazioni). 5 moduli gratuiti "appartenenti" a diversi grafici confondono e confondono gli utenti. E quando solo il modulo che appartiene al grafico attivo è davanti ai loro occhi, è una questione diversa.
Non sono d'accordo. Se la GUI è usata per aprire ordini, come nel tuo primo esempio, allora il modulo corrispondente deve appartenere al grafico corrispondente. Per esempio, avete 5 grafici aperti e di questi cinque, i moduli di gestione degli ordini sono in esecuzione (non i rapporti o le impostazioni). 5 moduli gratuiti "appartenenti" a diversi grafici confondono e confondono gli utenti. E quando solo il modulo che appartiene al grafico attivo è davanti ai loro occhi, è una questione diversa.
A proposito, c'è anche una tabella (albero) degli ordini, ma è solo un esempio...
La domanda principale degli utenti è "come posizionare i grafici/le forme" su 3 monitor :-) Nessuna scheda durante lo scambio - tutto deve essere visibile
)) il terminale è il fornitore di dati e il ricevitore che esegue l'applicazione. Questo è tutto. Non c'è niente da impostare in esso.
Mi prendi in giro o è una specie di trucco? Sono due giorni che cerco di avere una risposta. Che canale usa il secondo ricevitore per ricevere queste richieste? Forse dovresti essere uno scout. Se li beccano, agitano la mano, sputano e lasciano perdere, è comunque un solo reazionario...
Mi prendi in giro o è una specie di trucco? Ho cercato per 2 giorni di ottenere una risposta - quale canale di comunicazione riceve queste richieste il secondo - ricevitore-esecutore?? Perché non ti unisci agli scout? Se vengono presi, si arrenderanno e lasceranno perdere, tanto è tutto un posteriore...
Alexei, credo che lo schema sia il seguente: ogni grafico ha un EA che invia dati all'applicazione. Questi sono i fornitori di dati. C'è un EA su un grafico separato che interroga l'applicazione per i comandi. Questo EA accetta le richieste e le esegue. Di conseguenza, gli EAs sui grafici stessi non sono impegnati a scaricare sondaggi. Inviano i dati e continuano a lavorare nel loro modo. E una EA separata è impegnata in sondaggi per tutto il tempo.
Ma non vedo la necessità di un Expert Advisor separato. Il polling può essere gestito dall'indicatore perché sarà in un thread separato dall'EA. E quando l'indicatore rileva un ordine per questo grafico, può inviare un evento che sarà intercettato ed eseguito dall'Expert Advisor.
Alexei, credo che lo schema sia il seguente: ogni grafico ha un EA che invia dati all'app. Questi sono i fornitori di dati. C'è un EA su un grafico separato che interroga l'applicazione per i comandi. Questo EA accetta le richieste e le esegue. Di conseguenza, gli EAs sui grafici stessi non sono impegnati a scaricare sondaggi. Inviano i dati e continuano a lavorare nel loro modo. E una EA separata è impegnata in sondaggi per tutto il tempo.
Ma non vedo la necessità di un Expert Advisor separato. Il polling può essere gestito dall'indicatore perché sarà in un thread separato dall'EA. E quando l'indicatore rileva un ordine per questo grafico, può inviare un evento che sarà intercettato ed eseguito dall'Expert Advisor.
Non me ne frega niente se è suddiviso in 5 EA o 100500. Chiedevo del canale di comunicazione, perché ce ne possono essere diversi tipi. Anche in questo caso, lo facevo 10 anni fa sulle condutture. A quel tempo non c'erano pip incorporati in mql, ho usato il C++DLL nativo. E l'intero robot era in Sharp. I comandi dell'Expert Advisor sono stati accumulati nel buffer della DLL, perché sono stati emessi in modo asincrono per la velocità. E MQL4 Expert Advisor accedeva alla DLL ad ogni tick (non aveva ancora il timer), passava le quotazioni e prendeva i comandi. Tutto era multivaluta, non capisco perché abbiamo bisogno di molti grafici.
Qui ho descritto il meccanismo di scambio in due righe. È così difficile descrivere il tuo meccanismo invece di un oceano d'acqua?
Qui ho descritto il meccanismo di scambio in due righe. È così difficile descrivere il tuo meccanismo invece di un oceano di acqua?
Merda. Prima ho chiesto della GUI - come comunica? Risposto - non lo fa, non è necessario. Ora, si scopre che ha bisogno di come i consiglieri comunicano. 100 volte ha scritto su questo.
Sei davvero incapace di rispondere alle domande. Non mi interessa come comunicano i consiglieri. Questo è tutto, chiudo il thread, perché è inutile.
Non me ne frega niente se è suddiviso in 5 consiglieri o 100500. Chiedevo del canale di comunicazione, perché ce ne possono essere diversi tipi. Anche in questo caso, lo facevo 10 anni fa sulle condutture. A quel tempo non c'erano pip incorporati in mql, ho usato il C++DLL nativo. E l'intero robot era in Sharp. I comandi dell'Expert Advisor sono stati accumulati nel buffer della DLL, perché sono stati emessi in modo asincrono per la velocità. E MQL4 Expert Advisor accedeva alla DLL ad ogni tick (non aveva ancora il timer), passava le quotazioni e prendeva i comandi. Tutto era multivaluta, non capisco perché abbiamo bisogno di molti grafici.
Qui ho descritto il meccanismo di scambio in due righe. È così difficile descrivere il tuo meccanismo invece di un oceano d'acqua?