Il mio approccio. Il nucleo è il motore. - pagina 26
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
I costruttori di GUI sono fatti per una specifica libreria grafica. Se ci fosse un costruttore di GUI per MQL, sarebbe qui.
Ho visto un articolo da qualche parte, da qualche parte in hubre, sembra, come "creare un costruttore di GUI per Python", così ho pensato che forse qualcuno ha visto una GUI multipiattaforma dove potrei aggiungere il mio codice
Ma se voglio scrivere un costruttore da zero, preferisco usare MQL.
1. Non ho mai sviluppato in Sharp, non avevo interesse, ma circa 5 anni fa ho usato Delphi per collegare .dll con pulsanti e moduli e ha funzionato senza problemi, inoltre ho scritto l'intero progetto in Delphi durante un giorno, ho passato mezza giornata cercando di trovare il motivo per cui i moduli standard non funzionavano, ma quando l'ho collegato chiamando le finestre di sistema tutto funzionava correttamente, ma MT4 era molto lento allora, ora è lento e vola
Non ho problemi a collegare .dll, sincronizzare con mutex standard - avviare un thread per connettersi al terminale e questo è tutto, poi tutto va da solo - separatamente un modulo in .dll, separatamente MT nessuno sta aspettando nessuno
SZS: si noti che Delphi è piuttosto poco pratico per creare una .dll, ma quello che era a portata di mano (quello su cui ero seduto in quel momento) l'ho usato))
2. Per quanto riguarda il gist, non capisco perché non possono usare classi standard dal toolkit MT, sarebbe bello unificare il processo di creazione della grafica, forse sarebbe un include universale dove si potrebbero commentare pulsanti/dialoghi inutili, ecc.
1. questo è un modo molto, molto amatoriale di guardare il problema (senza offesa). Un progetto che si fa in un giorno non è un progetto. È un piccolo compito.
Immaginate di creare un'applicazione composta da 10 finestre, tra le quali ci sono grandi tabelle di dati, finestre di impostazioni e finestre di dialogo. Li disegnate in Delphi. Poi si crea una DLL. Poi lo colleghi al tuo progetto MT.
La vostra applicazione MT deve essere collegata alla GUI di Delphi tramite la memoria condivisa. Collega le funzioni ai controlli e i dati alle celle della tabella. È necessario organizzare la complessa interazione delle due parti dell'applicazione e pensarci bene.
È necessario il funzionamento sincrono e lo scambio di valori di parametri tra le due parti - GUI e MT Application.
Ancora una volta: se la vostra applicazione è grande e seria (tabelle, finestre di impostazioni, finestre di dialogo, liste antiche, ecc...) creare un lavoro unico, coerente ed efficiente di due parti tramite DLL è un compito MOLTO serio. L'ho fatto e so di cosa sto parlando.
E tu stai parlando di qualche piccolo compito che può essere fatto in un giorno. Non è grave.
È possibile utilizzare la libreria standard molto tempo fa. Ma la domanda riguarda lo sforzo richiesto e il risultato che otterrete. Cosa sono? So che Anatoly ha usato la libreria standard come trampolino di lancio per creare la propria libreria. Ma perché l'ha fatto, se anche la libreria standard funziona? La risposta è semplice - ha implementato tutto di qualità superiore ed è andato oltre la Libreria Standard. Ma la distribuzione di massa può essere ottenuta solo riducendo la difficoltà d'uso. Più facile da usare, - più utenti saranno (con un aumento della qualità, naturalmente).
1. questo è un modo molto, molto amatoriale di guardare il problema (senza offesa). Un progetto che si fa in un giorno non è un progetto. È un piccolo compito.
Immaginate di creare un'applicazione composta da 10 finestre, tra le quali ci sono grandi tabelle di dati, finestre di impostazioni e finestre di dialogo. Li disegnate in Delphi. Poi si crea una DLL. Poi lo colleghi al tuo progetto MT.
La vostra applicazione MT deve essere collegata alla GUI di Delphi tramite la memoria condivisa. Collega le funzioni ai controlli e i dati alle celle della tabella. Dovete organizzare la complessa interazione delle due parti dell'applicazione e pensarci bene.
È necessario il funzionamento sincrono e lo scambio di valori di parametri tra le due parti - GUI e MT Application.
Ancora una volta: se la vostra applicazione è grande e seria (tabelle, finestre di impostazioni, finestre di dialogo, liste antiche, ecc...) creare un lavoro unico, coerente ed efficiente di due parti tramite DLL è un compito MOLTO serio. L'ho fatto e so di cosa sto parlando.
E tu stai parlando di qualche piccolo compito che può essere fatto in un giorno. Questo non è serio.
Quali sono le sue rimostranze? Non capite che lo scambio di dati tra MT e .dll è vecchio come il mondo
Stavo facendo una .dll perché prima non c'era una grafica decente in MT, volevo dei pulsanti e un pannello
tavoli? - ben disegnare tabelle, controlli? - disegnare.... Non si può proprio separare il compito, nello stesso Delphi ci sono molti componenti già pronti, sia per creare database di database che per lavorare con essi
Cioè da MT hai bisogno solo dei dati stessi, e il resto lo farà un programma di terze parti, si può prendere la parola, ma nello stesso Delphi per scrivere lavoro con il database, con l'output in tabelle, grafici, ecc lavoro per un giorno ;)
Cosa sono i dati in MT? = è solo un tick e una barra, e non ha senso "correre" attraverso una .dll - basta scaricare tutto in un file una volta e lavorare con il file in un programma di terze parti
SZS: qualcuno ha scritto recentemente sul forum che le aziende IT moderne apprezzano i dipendenti che non capiscono a fondo il codice in cui lavorano, ma quelli che appena possibile possono eseguire un grande volume di compiti, cioè, devono essere in grado di integrare il lavoro di altre persone nel loro compito, e non costruire ogni volta tutto da zero! Non conosco la tua occupazione principale, non ho mai lavorato come programmatore, ma sto lavorando costantemente in campi correlati, per molto tempo impegnato nella manutenzione di controllori industriali, ACS e ACS, e ho dovuto fare aggiungere soluzioni di programma e interagire con gli sviluppatori, quindi ho dovuto entrare in tutte le soluzioni software già pronte - qui non si può scrivere tutto da zero )))), e i produttori di "ferro" industriale utilizzano sistemi di programmazione specializzati, dove C, dove SCADA, e assembler, e ogni volta deve essere in grado di leggere il codice di qualcun altro ;))
Lei propone di creare, sulla base del suo "motore", un design condizionatamente funzionante, che non può essere ulteriormente modificato dai programmatori?
Quali sono i sentimenti difficili? Non capite che lo scambio di dati tra MT e .dll è vecchio come il mondo
Ho fatto la .dll perché prima non c'era una grafica decente in MT, volevo pulsanti e pannello
tavoli? - ben disegnare tabelle, controlli? - disegnare.... Non si può proprio separare il compito, nello stesso Delphi ci sono molti componenti già pronti, sia per creare database di database che per lavorare con essi
Cioè da MT hai bisogno solo dei dati, e il resto lo farà un programma di terze parti, si può prendere la parola, ma nello stesso Delphi per scrivere lavoro con il database, con l'output in tabelle, grafici, ecc lavoro per un giorno ;)
ZS: cosa sono i dati in MT? = è solo un tick e una barra, e non ha senso "correre" la storia attraverso una .dll - basta scaricare tutto in un file una volta e lavorare con il file in un programma di terze parti
Se si prendono solo i dati che arrivano da MT, e li si passa attraverso una DLL a un'applicazione scritta in Delphi o C++ o C#, allora è sicuramente possibile. Allora l'applicazione di trading sarà completamente scritta in un linguaggio di programmazione diverso.
Cioè, serie temporali, tester, ottimizzazione, sintetici e molte altre cose devono essere create in un altro linguaggio.
Perché avete bisogno di MQL? È sufficiente fornire i dati direttamente a un'applicazione terza, e utilizzare la piattaforma come mittente di eventi e ordini. E questo è tutto. Ma i vantaggi di MQL come linguaggio di trading system andranno persi.
Perché avete bisogno di MQL?
Perché MQL è un linguaggio applicativo sviluppato per scrivere applicazioni di trading. Questo è il suo principale vantaggio. È leggero e semplice. Ha un sacco di soluzioni pronte per i programmatori. Li prendono e li usano.
I programmatori hanno una scelta:
Ovviamente, l'opzione più preferibile è usare MQL e MT, perché danno vantaggi - Test, Ottimizzazione, Ricerca (sintetica), Indicatori, funzioni pratiche, serie temporali... + Supporto tecnico linguistico sul forum.
Ma questo ideale ha un grave difetto: la capacità limitata di creare applicazioni complesse, a causa della difficoltà di creare una GUI di qualità.
Quest'ultimo problema l'ho in gran parte risolto.
Pertanto, quando si tratta di fare pratica e si inizia a scrivere una domanda seria, si sceglierà sicuramente MT. Così faranno molti, molti altri.
...
Stai suggerendo di creare, sulla base del tuo "motore", un design condizionatamente funzionante, che non può essere ulteriormente modificato dai programmatori?
Il motore è il "portatore" di quella GUI che viene creata nel mio costruttore. Non ha bisogno di essere modificato. Collegatelo solo all'applicazione e la GUI creata funzionerà.
Ancora una volta: se l'applicazione è grande e seria (tabelle, finestre di impostazioni, finestre di dialogo, liste antiche, ecc...) creare un funzionamento unico, coerente ed efficiente delle due parti tramite la DLL è un compito MOLTO serio. L'ho fatto e so di cosa sto parlando.
Chiunque possa creare un'applicazione grande e complessa userà sicuramente la libreria gui. Cosa deve fare lo sviluppatore, se sviluppa la sua applicazione e decide di aggiungere un'animazione, per esempio? Dovrebbe cercarvi e chiedere, o dovrebbe rompere tutto e costruire da zero?
Dove avete preso l'idea che ci sia un problema con la creazione di GUI. Guardate il mercato, ci sono molte applicazioni con GUI.
1. Chiunque possa creare un'applicazione grande e complessa userà sicuramente la libreria gui.
2. Cosa deve fare lo sviluppatore se, durante lo sviluppo della sua applicazione, decide, per esempio, di aggiungere un'animazione? Cercare e chiedere, o rompere tutto e costruire da zero?
3) E dove hai preso l'idea che c'è un problema con la creazione di GUI. Guardate il mercato, ci sono un sacco di applicazioni con GUI.
1. La libreria GUI è una libreria progettata per programmatori seri. Non può essere prodotto in massa a causa della difficoltà di utilizzo. Che senso ha? Solo alcuni di noi spulceranno la libreria e creeranno applicazioni complesse mentre altri non saranno in grado di farlo?
2. Lasciate che lo sviluppatore crei l'animazione nella sua applicazione. Cosa ha a che fare questo con me? Può chiamare questa animazione indipendentemente dalla GUI e dal motore, o collegare la chiamata della sua animazione a qualche pulsante.
3) Ci sono solo poche persone la cui GUI è degna di attenzione. Tu, Anatoly e forse qualcun altro... Il resto non raggiunge il minimo livello di serietà.
3. ci sono solo poche persone la cui GUI è degna di nota.
Non sarei così categorico. E non stavo parlando dello sviluppo di librerie gui, ma di applicazioni gui. Ce ne sono molti sul mercato, alcuni usano i loro propri sviluppi, alcuni usano la libreria standard e alcuni usano la libreria di Anatoly.
1. Questo è il punto: la libreria GUI è progettata per programmatori seri. Non può essere diffuso in modo massiccio a causa della difficoltà di utilizzo. Che senso ha? Alcuni di loro spulceranno la libreria e creeranno applicazioni complesse e altri falliranno?
2. Lasciate che lo sviluppatore crei l'animazione nella sua applicazione. Cosa ha a che fare questo con me? Può chiamare questa animazione indipendentemente dalla GUI e dal motore, o collegare la chiamata della sua animazione a qualche pulsante.
3) Ci sono solo poche persone la cui GUI è degna di attenzione. Tu, Anatoly e forse qualcun altro... Gli altri non raggiungono nemmeno il minimo livello di serietà.
Peter, penso che il problema principale che hai è nel posizionamento del progetto.
Può essere interessante solo per quei partecipanti che hanno un'esperienza piuttosto buona nella programmazione, ma allo stesso tempo - preferiscono scambiarsi le mani.
Pensi che ce ne siano molti?
Guarda - tutti i critici del tuo progetto sono persone che non si impegnano nel trading "manuale" su base regolare. Al massimo - di tanto in tanto. E, dato che non guardano il vostro progetto come commercianti "manuali" - lo guardano come programmatori. E, comprensibilmente, trovano un sacco di soluzioni molto dubbie.
Secondo me, la tua domanda ora dovrebbe riguardare la ricerca di questa nicchia (a mio parere, molto ristretta): i programmatori che preferiscono scambiare le mani.
Credo di aver visto un articolo da qualche parte, tipo su hubra, chiamato "creare un costruttore di GUI per Python", così ho pensato che forse qualcuno ha visto una GUI multipiattaforma dove potrei aggiungere il mio codice
Se voglio scrivere un costruttore da zero, preferisco usare MQL.
I moderni costruttori di GUI (quelli che "spargono i pulsanti sui moduli") sono una cosa abbastanza tecnologica e attaccare elementi MQL a loro non sembra fantastico.
Nella forma intermedia ( file di progetto, ecc.) quasi tutti hanno XML che descrive il layout e le relazioni tra gli elementi.
La generazione di codice della piattaforma di destinazione è in effetti la trasformazione XSLT, che può essere fatta da chiunque pensi di essere un web-developer :-)
Prendete per esempio EasyAndFast (https://www.mql5.com/ru/code/19703) perché è basato su oggetti e ha tutti i componenti necessari. (e aperto e documentato a proposito, a differenza di questo thread),
e scrivere semplicemente un traduttore.
Non ci sono costruttori di gui-mql, non perché sia mega complesso, ma semplicemente perché non è richiesto.