Creazione di una GUI per MQL in modalità grafica. - 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
In realtà, non è così. Non c'è differenza tra un programma esterno e un programma in MT. Le capacità sono le stesse, l'interazione è la stessa.
Non hai spiegato proprio niente. Come si ottengono i dati da MT* nel pannello sharpe?
Ho fatto il feedback tramite Memory Mapping con sondaggi a tempo. Il pannello mi ha inviato solo impostazioni diverse e risultati di calcolo lenti.
L'ignoranza dà fiducia. Ma la conoscenza moltiplica i dolori.
Ok, allora farò il pannello separato, comunicazione via Memory Mapping. Lo facevo tramite tubi alla fine degli anni 2000, ma non mi piaceva.
Collegato direttamente però, non ha notato alcun orrore.
L'interfaccia COM del terminale sarebbe bella, anche se sta diventando rapidamente obsoleta.
Semplicemente non sembra adattarsi al tempo reale :-(.
L'interfaccia COM probabilmente non sarà disponibile.
Ma posso chiedere perché è obsoleto?
Sta anche diventando rapidamente obsoleto.
L'interfaccia COM probabilmente non sarà disponibile.
Ma posso chiedere perché è obsoleto?
Sta anche diventando rapidamente obsoleto.
è stato sostituito da .net con le sue interfacce di comunicazione
è stato sostituito da .net con le sue interfacce di comunicazione
e in COM i GUID da soli valgono molto
MS ricompra ancora i GUID inutilizzati per un dollaro a 10. Se ti è rimasto qualcosa dai vecchi tempi, puoi fare un bel profitto!
E in COM i GUID da soli valgono molto
MS ricompra ancora i GUID inutilizzati per un dollaro a dieci. Se ti è rimasto qualcosa dai vecchi tempi, puoi fare un bel profitto!
Ne ho un po' in giro :-) Te li farò mandare a MS
066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb
se c'è qualcos'altro, potrei essere in grado di trovarlo.
Colleghi. Penso che la discussione su quale ambiente di sviluppo sia migliore e quale codice sia più veloce non abbia alcun senso. È tutta una questione di gusti e dipende dai compiti da risolvere. Indipendentemente dall'ambiente di sviluppo, abbiamo ancora problemi di interazione tra un'applicazione esterna e uno strumento MetaTrader. Consideriamo un semplice esempio. Avete implementato in un dll nativo un algoritmo di calcoli matematici complessi. Hai passato i parametri richiesti dallo strumento MT a questa libreria e hai iniziato il calcolo, lo strumento ha continuato il suo lavoro fino a quando il calcolo è stato completato. E di nuovo questo problema è indipendente dall'ambiente di sviluppo!
Vedo diverse opzioni:
1. La possibilità di chiamare dall'esterno del programma il metodo OnChartEvent, usando per esempio il PostMessage
2. Aggiungendo a МТ strumenti nuovo metodo, come offerto da Renat: OnExternal, specificando il tipo di evento o generalmente i dati trasferiti, cioè in questo metodo è possibile restituire i dati
3. Implementazione in strumenti di MT di winsocket. Questo è simile al secondo punto, ma permette allo strumento MT di connettersi a una porta specifica per ascoltare i dati.
Se il primo e il secondo elemento permetteranno l'interazione a livello di una singola macchina, il terzo elemento fornirà strumenti di MT con comunicazione di rete.
Ecco un esempio:https://www.mql5.com/ru/articles/2599
Ma anche qui avete il problema di dover controllare se i dati sulla presa sono sempre disponibili.
Quindi il problema del callback rimane in tutti i casi e non è risolto.
Il monitoraggio del timer non è una soluzione ma una stampella. Sì, in assenza di altre opzioni questo è il modo in cui lo stiamo risolvendo ora.
Se gli sviluppatori implementassero una soluzione per questi problemi a livello di piattaforma, allora non ci sarebbe bisogno di accedere all'API del terminale. Dopotutto, non viene chiesto per la bella vita, ma perché non c'è un'interazione completa tra la MT e le applicazioni che vengono create. E ripeto: questo problema esiste indipendentemente dall'ambiente di sviluppo di applicazioni esterne scelto.
Informazioni sulla possibilità di usare le librerie di rete )))https://www.mql5.com/ru/forum/13388
L'argomento è molto vecchio in linea di principio. Gli stessi sviluppatori hanno annunciato una volta la possibilità di lavorare con le librerie di rete senza alcuna difficoltà... Da allora è passata molta acqua, ma la questione rimane irrisolta...
O qui, un messaggio di Renat stesso:https://www.mql5.com/ru/forum/3153/page2#comment_298866
https://www.mql5.com/ru/forum/3153/page2#comment_298892
Colleghi. Penso che la discussione su quale ambiente di sviluppo sia migliore e quale codice sia più veloce non abbia alcun senso. È tutta una questione di gusti e dipende dai compiti da risolvere. Indipendentemente dall'ambiente di sviluppo, abbiamo ancora problemi di interazione tra un'applicazione esterna e uno strumento MetaTrader. Consideriamo un semplice esempio. Avete implementato in un dll nativo un algoritmo di calcoli matematici complessi. Hai passato i parametri richiesti dallo strumento MT a questa libreria e hai iniziato il calcolo, lo strumento ha continuato il suo lavoro fino a quando il calcolo è stato completato. E di nuovo, questo problema non dipende dall'ambiente di sviluppo!
Vedo diverse opzioni:
1. La possibilità di chiamare dall'esterno del programma il metodo OnChartEvent, usando per esempio il PostMessage
2. Aggiungendo a МТ strumenti nuovo metodo, come offerto da Renat: OnExternal, specificando il tipo di evento o generalmente i dati trasferiti, cioè in questo metodo è possibile restituire i dati
3. Implementazione in strumenti di MT di winsocket. Questo è simile al secondo punto, ma permette a uno strumento di MT di connettersi a una porta specifica per ascoltare i dati.
Se il primo e il secondo elemento permetteranno l'interazione a livello di una singola macchina, il terzo elemento fornirà una rete di strumenti MT.
Ecco un esempio:https://www.mql5.com/ru/articles/2599
Ma anche qui avete il problema di dover controllare se i dati sulla presa sono sempre disponibili.
Quindi il problema del callback rimane in tutti i casi e non è risolto.
Il monitoraggio del timer non è una soluzione ma una stampella. Sì, in assenza di altre opzioni questo è il modo in cui lo stiamo risolvendo ora.
Se gli sviluppatori implementassero una soluzione per questi problemi a livello di piattaforma, allora non ci sarebbe bisogno di accedere al terminale API. Dopotutto, non viene chiesto per la bella vita, ma perché non c'è un'interazione completa tra la MT e le applicazioni che vengono create. E ripeto: questo problema esiste indipendentemente dall'ambiente di sviluppo di applicazioni esterne scelto.
Aggiungo sul monitoraggio e il polling, solo che non tutti lo sanno - per evitare di far sobbalzare la DLL ad ogni sondaggio, si può avere int[] per "condividere" le bandiere. All'interno della DLL tutti gli accessi a loro come __atomic__ .
In linea di principio questo funziona ed è abbastanza economico sulle risorse, ma bisogna fare affidamento sul fatto che sul lato MQL l'incremento/decremento sono anche atomici e l'ottimizzatore non fa supposizioni sui valori.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Per fare le cose davvero bene, basterebbe un attributo atomico (volatile?) e un insieme di primitive appropriate. A mio parere, è più facile che costruire un nuovo meccanismo nel sistema e non cambia il protocollo DLL esistente
Aggiungo sul monitoraggio e il polling, non tutti lo sanno - per non disturbare la DLL con ogni sondaggio, si possono creare int[] per "condividere" le bandiere. All'interno della DLL tutti gli accessi a loro come __atomic__ .
In linea di principio questo funziona ed è abbastanza economico sulle risorse, ma bisogna fare affidamento sul fatto che sul lato MQL l'incremento/decremento sono anche atomici e l'ottimizzatore non fa supposizioni sui valori.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Per fare le cose davvero bene, basterebbe un attributo atomico (volatile?) e un insieme di primitive appropriate. Secondo me, è più facile che costruire un nuovo meccanismo nel sistema e non cambia il protocollo DLL esistente
Maxim, in che modo questa soluzione è migliore? Dopotutto, per controllare lo stato di un flag, deve essere controllato periodicamente anche in MQL. Così, si scopre che ovunque si guardi, è necessario monitorare costantemente i cambiamenti dello stato di qualcosa per capire che è il momento di raccogliere i dati. E questo frammento può essere memorizzato nella dll stessa e controllato lì - è quello che faccio io. Nel tuo esempio abbiamo una chiamata implicita alla dll per restituire lo stato della bandiera.