Creazione di una GUI per MQL in modalità grafica. - pagina 10
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
Polling unidirezionale da μl, pip, file o richieste web.
Sono sicuro che andrebbe benissimo! Non stiamo parlando di mandare qualcosa a MT. Il trasferimento stesso può essere fatto in qualsiasi altro modo. L'importante è dire a MT che qualche azione deve essere eseguita. È esattamente lo stesso che nella libreria GUI che hai sviluppato: tutti i colbec sono fatti attraverso gli eventi.
A proposito, a proposito di questa libreria: hai intenzione di espanderla e tradurla completamente su tela? Cioè, il "prodotto" finale non è un insieme di oggetti grafici, ma un quadro completo.
E nel contesto della revisione delle dll, ovviamente mi piacerebbe poter includere le dll come risorsa in MT, in modo da non doverle "trascinare" insieme all'Expert Advisor o all'indicatore.
Perché fermarsi a dotnet per la gui?
La domanda non è tanto sulla GUI. Le interfacce possono essere create facilmente utilizzando strumenti di MT. Certo, è un po' complicato e richiede la creazione di classi di elaborazione proprie, ma tutto può essere risolto. Ho iniziato a lavorare con la rete a causa dell'impossibilità di implementare alcuni algoritmi di lavoro con Internet. È piuttosto complicato e instabile in C++, anche in lingua madre, per non parlare di MT. Una volta che ho padroneggiato la rete, posso iniziare a usare anche la GUI, perché tutto è pronto per essa, a differenza di MT. Tra le questioni aperte dello sviluppo di applicazioni in qualsiasi linguaggio, cioè in qualsiasi, dato che queste domande non sono collegate alla rete: 1. Feedback, 2. Collegamento della GUI al grafico (https://www.mql5.com/ru/forum/103764) - uno degli argomenti.
Polling unidirezionale da µl, pip, file o query web.
è una tua scelta ;-)
dal punto di vista delle applicazioni - ci dovrebbe essere un modo standard dopo aver chiamato la DLL per dire a MT "questo è quello che vuoi, questo è quello che ottieni".
Scenario tipico per calcoli lunghi, IO di rete - MT chiama DLL, DLL crea un thread e qualcosa viene fatto in esso. Ci deve essere un modo per dire "questo è tutto, è stato calcolato". Senza di esso, stiamo costantemente sondando gli EA per qualcosa.
è una tua scelta ;-)
Dal punto di vista delle applicazioni - ci dovrebbe essere un modo standard per dire a MT "questo è ciò che vuoi, questo è ciò che ottieni".
Scenario tipico per calcoli lunghi, IO di rete - MT chiama DLL, DLL crea un thread e qualcosa viene fatto in esso. Ci deve essere un modo per dire "questo è tutto, è stato calcolato". Senza di esso, stiamo costantemente sondando l'EA per qualcosa.
Sono d'accordo con te!
Bene
Possiamo tutti discutere fino alla fine sui meriti di un ambiente di sviluppo o di un altro. Ma per cosa? Sappiamo tutti che nessun sistema di sviluppo è autosufficiente, perché risolve problemi specifici. Qualsiasi altro componente plug-in sviluppato in qualsiasi altro linguaggio o ambiente può essere usato per estendere le sue capacità. Dobbiamo solo rendere facile la comunicazione. Non andiamo lontano: le stesse librerie di Windows che usiamo attraverso l'importazione... ...li usiamo per implementare le funzionalità che ci mancano. E non si può dire che sia implementato puramente per mezzo di mql. ))) Quindi che differenza fa quale applicazione esterna usiamo per espandere le capacità e raggiungere gli obiettivi desiderati? In che modo una dll auto-scritta è peggiore di una di Windows?
Ecco un articolo per esempio: https://www.mql5.com/ru/articles/364
Ma non si tratta di sbarazzarsi completamente di dll, semplicemente non accadrà mai, perché MT ha rigorosamente i suoi compiti. Le librerie di sistema sono presenti in questo articolo, in qualsiasi modo lo si guardi. Sì, a differenza delle librerie fatte in casa, queste librerie non hanno bisogno di essere portate in giro con Expert Advisor o indicatori...
Bene, cosa vi impedisce di aggiungere la possibilità di compilare le DLL nelle risorse dello strumento?
Sì, non si può mettere sul mercato, perché il mercato non permette di usare dll, ma sarebbe molto più conveniente per il proprio sviluppo.
Possiamo tutti discutere fino alla fine sui meriti di un ambiente di sviluppo o di un altro. Ma per cosa? Sappiamo tutti che nessun sistema di sviluppo è autosufficiente, perché risolve problemi specifici. Qualsiasi altro componente plug-in sviluppato in qualsiasi altro linguaggio o ambiente può essere usato per estendere le sue capacità. Dobbiamo solo rendere facile la comunicazione. Non andiamo lontano: le stesse librerie di Windows che usiamo attraverso l'importazione... ...li usiamo per implementare le funzionalità che ci mancano. E non si può dire che sia implementato puramente per mezzo di mql. ))) Quindi che differenza fa quale applicazione esterna usiamo per espandere le capacità e raggiungere gli obiettivi desiderati? In che modo una dll auto-scritta è peggiore di una di Windows?
Ecco un articolo per esempio: https://www.mql5.com/ru/articles/364
Ma non si tratta di sbarazzarsi completamente di dll, semplicemente non accadrà mai, perché MT ha rigorosamente i suoi compiti. In questo articolo, le librerie di sistema sono presenti in qualsiasi modo lo si guardi. Sì, a differenza delle librerie fatte in casa non è necessario portare queste librerie con Expert Advisor o indicatori...
Bene, cosa vi impedisce di aggiungere la possibilità di compilare le DLL nelle risorse dello strumento?
Sì, non puoi metterlo sul mercato, perché il mercato non permette di usare dll, ma per il tuo sviluppo personale sarebbe molto più conveniente.
Questi pensieri e post sono vecchi di 10 anni.
Se stiamo parlando dell'ecosistema, allora dovremmo semplicemente chiudere l'uso di qualsiasi importazione in MT. Ma non lo fanno. Dopo tutto, non hanno deciso di usare le importazioni della biblioteca per una ragione. Per un po' MT non poteva lavorare con le richieste web, c'erano limitazioni quando si lavorava con i file... tutto questo è stato ESPANSO con l'importazione di librerie. È tutto ovvio e tutti i sistemi funzionano così. Anche ora MQL può lavorare con i file solo da una sandbox. Non è che qualcuno contesti questo approccio, è la politica dello sviluppatore e tutti la capiscono e la sostengono. Se avete bisogno di uscire da una sandbox o di usare il registro per memorizzare dati, o un database o una mappatura ... allora per favore usate le librerie per questo scopo. Giusto? Tutto ha perfettamente senso. Lo strumento non ha bisogno di database o altro... è tutto solo per gli sviluppatori, ed è per questo che è disponibile il linguaggio MQL, in modo da poter implementare strumenti di qualsiasi funzionalità. E poiché c'è un ambiente di sviluppo, MT non è più una cosa a sé. )) Hai solo bisogno di ... ))))
Questo tipo di pensieri e post sono vecchi di 10 anni, ma siamo ancora qui...
Come può essere ancora così?
Tutte le possibilità di interoperabilità esistono da molto tempo. Il supporto DLL è stato addirittura introdotto nel 2004.
I nostri linguaggi sono in costante evoluzione e diventano sempre più potenti e funzionali. E l'ecosistema è più potente di quello di chiunque altro.