Fare un progetto in crowdsourcing su Canvas - pagina 34
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
L'applicazione è separata, la GUI è separata.
Ma l'elaborazione dei dati dedotti nella GUI viene eseguita comunque in modo sincrono.
Per esempio, l'applicazione invia 10000 elementi a GUI e GUI elabora tutti questi elementi in modo sequenziale.
Questo è il problema. È necessario parallelizzare l'elaborazione degli elementi in entrata e il loro output nella GUI. Base, testo, icona.
Inoltre, ci sono tre cicli per cella.
Proprio così. Ma, nelle circostanze attuali, l'elaborazione in parallelo è scomoda. Abbiamo bisogno di collegare più EA o servizi. Si rivelerà un'implementazione macchinosa e sconnessa.
C'è un modo basato su grafici a oggetti. Non ci sono entrato, ma può aiutarmi a creare diversi thread. Ha qualcosa a che fare con i modelli...
Ho capito il punto, l'applicazione è separata, la GUI è separata.
Ma l'elaborazione dei dati in uscita nella GUI viene eseguita comunque in modo sincrono.
Così, per esempio, l'applicazione invia 10000 elementi a GUI e GUI elabora tutti questi elementi in modo sequenziale.
Questo è il problema. È necessario parallelizzare l'elaborazione degli elementi in entrata e il loro output nella GUI. Base, testo, icona.
Tanto più che ci sono tre cicli per una cella.
È improbabile che questo funzioni. Anche la winda elabora l'interfaccia in un unico thread. Altrimenti, le finestre e i controlli non avranno la priorità. Solo la GUI stessa e l'elaborazione dei vari dati possono essere divisi in thread. Di fatto, anche la modifica dei dati nei controlli non è consentita da un altro thread. Un dialogo deve essere sempre coerente, quindi qualsiasi rendering e reazione di qualsiasi dialogo è strettamente in un thread, cioè tutto avviene in modo sincrono.
Tutte le operazioni in MT sono strettamente sincrone e questo non può essere realmente cambiato a meno che gli sviluppatori non aggiungano dei thread all'applicazione.
È abbastanza sorprendente che gli sviluppatori stiano cercando di espandere le funzionalità di MT in termini di lavoro con i database, con python, con sharpe... ma si offrono di fare tutto nello stesso thread...
È semplicemente incredibile.
Sono d'accordo con la sorpresa.
L'unica via d'uscita è segare una dll con funzioni asincrone per le vostre applicazioni.
Ma tali applicazioni non possono nemmeno essere messe nel kodobase, perché la dll non è permessa.
È improbabile che questo funzioni. Anche l'interfaccia di Windows è gestita in un singolo thread. Altrimenti, le finestre e i controlli non avranno la priorità. Solo la GUI stessa e l'elaborazione dei vari dati possono essere suddivisi in thread. Di fatto, anche la modifica dei dati nei controlli non è consentita da un altro thread. Un dialogo deve essere sempre coerente, quindi qualsiasi rendering e reazione di qualsiasi dialogo è strettamente in un thread, cioè tutto avviene in modo sincrono.
Mi sembra che tutto si risolverà, è solo necessario pensare in anticipo alla priorità dell'elaborazione asincrona dei dati.
Cioè, costruire uno schema di elaborazione asincrona, con elaborazione sincrona.
Sono d'accordo, con sorpresa.
L'unica via d'uscita è segare una dll con funzioni asincrone alle vostre applicazioni.
Ma tali applicazioni non possono nemmeno essere messe in un kodobase perché la dll non è consentita.
In effetti, non c'è ancora una reale necessità di parallelizzare l'elaborazione degli eventi della GUI. Se le tabelle di 1000 celle girano relativamente veloci anche su MT4, c'è una velocità più che sufficiente per il resto degli eventi. Nella mia pratica non c'è nessun rallentamento. Se avete bisogno di animazioni super-veloci, potete collegare OpenCL. MT5 tira perfettamente la GUI regolare. Nessun problema. Ho appena dimostrato che bisogna essere molto attenti al ridisegno della tela.
Se l'Expert Advisor stesso include calcoli pesanti, la frequenza di uscita dei dati nella GUI può essere ridotta. Il ridisegno di una grande finestra può raggiungere i 100 ms, ma di solito è molto meno. Quindi, un ritardo di 100ms sulla GUI può essere notato solo con calcoli EA MOLTO pesanti.
Sono d'accordo, con sorpresa.
L'unica via d'uscita è segare una dll con funzioni asincrone per le vostre applicazioni.
Ma tali applicazioni non possono nemmeno essere messe in un kodobase perché la dll è vietata.
Molte cose possono essere fatte a livello di DLL.
Questo è tutto ciò per cui MT non è progettato e può+deve+farlo :-)
Non si può controllare il dll, ecco perché non è sul mercato. A proposito, puoi trovare le dll in kodobase. Forse l'hanno vietato ora per qualche motivo.
PS a proposito, domanda curiosa: la DLL può essere firmata con la chiave dello sviluppatore. È possibile consentire tale DLL nel mercato e anche in kodobeise, ma sarà legato all'infrastruttura Microsoft. Qualcuno qui è pronto a comprare una tale licenza per Visual C?Sono d'accordo, con sorpresa.
L'unica via d'uscita è segare una dll con funzioni asincrone per le vostre applicazioni.
Ma tali applicazioni non possono nemmeno essere messe in kodobase perché la dll è proibita.
Sì, questo è il problema principale! Lo stesso mercato proibisce l'uso delle DLL, quindi dobbiamo reinventare la ruota. Ok, se qualcuno pensa che la GUI non sia necessaria, ma qualsiasi calcolo lungo e complesso in ogni caso in un thread non funzionerà, tutto si bloccherà! Quindi deve essere fatto in un dll... che è proibito nel mercato...
E così via. Per questo motivo devo disegnare e risolvere tutto con metodi mql.
In effetti, la separazione di GUI e logica in thread è, ovviamente, già possibile. Qui i ragazzi hanno già discusso la questione del parallelismo https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
Come risultato, il modulo stesso potrebbe essere lasciato nel thread principale, come viene fatto in winnda, mentre qualsiasi calcolo aggiuntivo potrebbe essere spostato all'esecuzione in "background". È così che funzionano Windows, Linux e Android.
Si possono fare così tante cose a livello di DLL.
Questo è ciò che MT non serve e può+deve+fare :-)
Non si può controllare il dll, ecco perché non è sul mercato. A proposito, abbiamo delle DLL in Kodobase. Forse l'hanno vietato ora per qualche motivo.
PS a proposito, domanda curiosa: la DLL può essere firmata con la chiave dello sviluppatore. È possibile permettere tali DLL nel Marketplace e anche in Kodobeise, ma sarà legato all'infrastruttura Microsoft. Qualcuno qui è pronto a comprare una tale licenza per Visual C?Sì, non si può controllare il dll, ma si potrebbe permettere alle stesse librerie del vento...
Non andate nemmeno tanto lontano: anche come parte di una libreria standard ci sono funzioni per accedere a winAPI! Ma qual è il punto? Dopo tutto, non si può mettere nel mercato....
Ok, con tutto questo parlare siamo finiti in un altro diluvio.
Ci sono molte cose che si possono fare a livello di DLL.
Questo è ciò per cui MT non è destinato e può+deve+essere fatto lì :-)
Non si può controllare il dll, ecco perché non è sul mercato. A proposito, puoi ottenere le DLL in Kodobase. Forse l'hanno vietato per qualche motivo.
PS a proposito, domanda curiosa: la DLL può essere firmata con la chiave dello sviluppatore. È possibile permettere tali DLL nel Marketplace e anche in Kodobeise, ma sarà legato all'infrastruttura Microsoft. Qualcuno qui è pronto a comprare una tale licenza per Visual C?Perché dovreste essere legati all'infrastruttura Microsoft?
Penso che assolutamente qualsiasi chiave possa essere usata per firmare una dll, purché sia controllata da MQ.
Ne consegue che queste chiavi devono essere emesse da MQ, e controllano la quantità di hash dell'applicazione.
Perché dovrebbero legarsi all'infrastruttura di Microsoft?
Penso che qualsiasi chiave possa essere usata per firmare una dll, purché sia controllata da MQ.
Ne consegue che queste chiavi devono essere emesse da MQ, e controllano la somma di hash dell'applicazione.
ma perché microsoft è il capo in questo formicaio :-)
Perché pensi che la gente perda i propri dati di accesso quando aggiorna e attiva prodotti su vin pirata?