Quasi 400 proprietà di finestre, elementi e parametri del nucleo sono integrati e inseriti in schede nelle finestre dell'editor. Tutti questi elementi diventeranno impostazioni controllabili degli elementi GUI creati in VE.
Sono stati integrati 52 modelli di vari elementi di controllo necessari per il lavoro degli utenti.
È stato fatto molto lavoro sul design e sullo stile. Continuo a valutare una serie di soluzioni per ottenere praticità e usabilità della GUI di VE.
Una volta completata l'integrazione dei modelli e delle proprietà, nonché il loro ordinamento e la loro distribuzione, inizierà il lavoro sulla funzionalità.
Al momento la GUI è scritta nel linguaggio di markup KIB, che è piuttosto noioso. Il passaggio all'editing visivo non è ancora avvenuto. Tuttavia, ciò avverrà nel prossimo futuro.
Ci sono dei difetti grafici. Sono temporanei.
L'altezza della barra delle applicazioni è stata ridotta per risparmiare spazio.
La cornice della finestra dell'editor è stata spostata fuori dal campo visivo per ottenere più spazio.
Sembra fantastico Peter, penso che una volta che avrai usato il VE per costruirsi da solo, ti darà sicuramente delle indicazioni preziose su come funziona il tuo design dell'interfaccia utente. Aspetto con ansia il prossimo aggiornamento dello sviluppo.
Douglas Prager #: Sembra fantastico, Peter. Penso che quando si usa VE per costruire se stessi, si ottengono preziose informazioni su come funziona il design dell'interfaccia utente. Attendo con ansia il prossimo aggiornamento dello sviluppo.
Grazie, Douglas. Hai ragione, è esattamente così. C'è un minimo di "ostacolo" tecnico da superare.
Seguirò con interesse anche il vostro sviluppo fondamentale.
Doerk Hilger #: L'interfaccia utente è ancora al 100% puro MQL. Tutto basato su vettori, completamente scalabile e adattabile a qualsiasi display. Tutti i display visivi funzionano in modo asincrono all'interno di una classe centrale che gestisce e distribuisce tutti gli eventi MQL agli oggetti, a seconda delle loro impostazioni di sottoscrizione e in base alle priorità degli eventi.
Spero di non rubare l'interessantissimo thread e perdonami Peter se lo faccio, non sarà una discussione, spero solo in una risposta breve per l'interesse teorico - intendi dire che hai una sorta di classe statica che conosce (tiene traccia di tutti i puntatori agli oggetti) tutti gli oggetti di classe istanziati nel sistema e ogni oggetto ha accesso a sottoscrivere se stesso agli eventi richiesti da quella classe statica di controllo e quella classe statica singleton di controllo consegna semplicemente gli eventi a tutti gli oggetti? Se è così, lo considera corretto in termini di OOP o forse è accettabile come programmazione guidata dagli eventi? Dato che ne avete scritto, immagino che vogliate accettare domande in merito e, in tal caso, cerchiamo di essere il più brevi possibile per non dirottare questo thread, anche se è correlato.
Spero di non rubare il thread molto interessante e perdonami Peter se lo faccio, non sarà una discussione, spero solo in una risposta breve per l'interesse teorico - intendi dire che hai una sorta di classe statica che conosce (tiene traccia di tutti i puntatori agli oggetti) tutti gli oggetti di classe istanziati nel sistema e ogni oggetto ha accesso a sottoscrivere se stesso agli eventi richiesti su quella classe statica di controllo e quella classe statica di controllo singleton consegna semplicemente gli eventi a tutti gli oggetti? Se è così, lo considera corretto in termini di OOP o forse è accettabile come programmazione guidata dagli eventi? Dato che ne avete scritto, immagino che vogliate accettare domande in merito e, in tal caso, cerchiamo di essere il più brevi possibile per non dirottare questo thread, anche se è correlato.
Sì, è esattamente questo. Breve descrizione:
Il core riceve tutti gli eventi di MetaTrader e qualsiasi oggetto può sottoscrivere il core. Per questo motivo è stato necessario riprogettare/modificare anche la classe CObject, in modo che ogni oggetto abbia una funzione chiamata "public: virtual void OnEACycle(CCycleParams * cpm)". Tale ciclo può essere un evento grafico, un init, un deinit, ecc. Ogni oggetto può anche avere un "public: virtual void OnEATick()". L'effetto collaterale è che in questo modo si ottiene una funzione in più, perché si può sottoscrivere anche la fine di qualsiasi ciclo, indipendentemente da quale sia. Piuttosto utile per chiudere un file o finire qualsiasi altra cosa, semplicemente alla fine di qualsiasi ciclo.
Inoltre, ogni oggetto CObject può avere figli e anche sottoscrittori. Ciò significa che un oggetto può innescare i propri eventi, come quando qualcosa viene cliccato o simili. Allora si esegue semplicemente un object.SubEvent(STH_CLICKED, params). In questo modo l'oggetto stesso non si preoccupa di chi ha bisogno di queste informazioni, ma solo di distribuirle ai sottoscrittori, che ricevono un OnSubEvent(int msg, CSubEventParams * sep) e possono farci quello che vogliono.
Tutto sommato, questo modo è più simile al modo di codificare che conosciamo da C#, dove si usa anche solo .Invoke() per lanciare eventi e non ci si preoccupa di chi li riceve.
In realtà non è così complicato da implementare, ma ovviamente i dettagli sono la sfida finale, dato che si tratta di un nucleo/base per ogni singolo EA o indicatore del futuro che deve funzionare in ogni scenario.
Naturalmente, Load/Unload/Activate ecc. sono personalizzati, ma dal momento che si dispone di questo event-core, si ha molta più flessibilità che senza e molto più controllo su tutto. Se avessi il tempo, scriverei un articolo e fornirei le fonti. Non è un segreto, non c'è nessuna magia.
Grazie. No, nessuna libreria. L'ho sviluppato da zero da solo. In realtà, solo CCanvas è adattato da quelli originali, nient'altro.
Non è facile creare qualcosa di simile. )
Per quanto ne so, nella classe Ccanvas standard non c'è alcuna funzionalità per disegnare un gradiente di colore, come hai risolto il problema del gradiente nella tua GUI?
Consenti l'uso dei cookie per accedere al sito MQL5.com.
Abilita le impostazioni necessarie nel browser, altrimenti non sarà possibile accedere.
Hai effettuato l'accesso. L'autenticazione a due fattori è stata disattivata. Configurala di nuovo e scansiona un nuovo codice QR, oppure continua con l'autenticazione a due fattori disattivata.
Stadio attuale di sviluppo di VE:
Aspetto con ansia il prossimo aggiornamento dello sviluppo.
Sembra fantastico, Peter. Penso che quando si usa VE per costruire se stessi, si ottengono preziose informazioni su come funziona il design dell'interfaccia utente.
Attendo con ansia il prossimo aggiornamento dello sviluppo.
L'interfaccia utente è ancora al 100% puro MQL.
Tutto basato su vettori, completamente scalabile e adattabile a qualsiasi display.
Tutti i display visivi funzionano in modo asincrono all'interno di una classe centrale che gestisce e distribuisce tutti gli eventi MQL agli oggetti, a seconda delle loro impostazioni di sottoscrizione e in base alle priorità degli eventi.
Spero di non rubare l'interessantissimo thread e perdonami Peter se lo faccio, non sarà una discussione, spero solo in una risposta breve per l'interesse teorico - intendi dire che hai una sorta di classe statica che conosce (tiene traccia di tutti i puntatori agli oggetti) tutti gli oggetti di classe istanziati nel sistema e ogni oggetto ha accesso a sottoscrivere se stesso agli eventi richiesti da quella classe statica di controllo e quella classe statica singleton di controllo consegna semplicemente gli eventi a tutti gli oggetti? Se è così, lo considera corretto in termini di OOP o forse è accettabile come programmazione guidata dagli eventi? Dato che ne avete scritto, immagino che vogliate accettare domande in merito e, in tal caso, cerchiamo di essere il più brevi possibile per non dirottare questo thread, anche se è correlato.
Spero di non rubare il thread molto interessante e perdonami Peter se lo faccio, non sarà una discussione, spero solo in una risposta breve per l'interesse teorico - intendi dire che hai una sorta di classe statica che conosce (tiene traccia di tutti i puntatori agli oggetti) tutti gli oggetti di classe istanziati nel sistema e ogni oggetto ha accesso a sottoscrivere se stesso agli eventi richiesti su quella classe statica di controllo e quella classe statica di controllo singleton consegna semplicemente gli eventi a tutti gli oggetti? Se è così, lo considera corretto in termini di OOP o forse è accettabile come programmazione guidata dagli eventi? Dato che ne avete scritto, immagino che vogliate accettare domande in merito e, in tal caso, cerchiamo di essere il più brevi possibile per non dirottare questo thread, anche se è correlato.
Sì, è esattamente questo.
Breve descrizione:
Il core riceve tutti gli eventi di MetaTrader e qualsiasi oggetto può sottoscrivere il core. Per questo motivo è stato necessario riprogettare/modificare anche la classe CObject, in modo che ogni oggetto abbia una funzione chiamata "public: virtual void OnEACycle(CCycleParams * cpm)". Tale ciclo può essere un evento grafico, un init, un deinit, ecc. Ogni oggetto può anche avere un "public: virtual void OnEATick()". L'effetto collaterale è che in questo modo si ottiene una funzione in più, perché si può sottoscrivere anche la fine di qualsiasi ciclo, indipendentemente da quale sia. Piuttosto utile per chiudere un file o finire qualsiasi altra cosa, semplicemente alla fine di qualsiasi ciclo.
Inoltre, ogni oggetto CObject può avere figli e anche sottoscrittori. Ciò significa che un oggetto può innescare i propri eventi, come quando qualcosa viene cliccato o simili. Allora si esegue semplicemente un object.SubEvent(STH_CLICKED, params). In questo modo l'oggetto stesso non si preoccupa di chi ha bisogno di queste informazioni, ma solo di distribuirle ai sottoscrittori, che ricevono un OnSubEvent(int msg, CSubEventParams * sep) e possono farci quello che vogliono.
Tutto sommato, questo modo è più simile al modo di codificare che conosciamo da C#, dove si usa anche solo .Invoke() per lanciare eventi e non ci si preoccupa di chi li riceve.
In realtà non è così complicato da implementare, ma ovviamente i dettagli sono la sfida finale, dato che si tratta di un nucleo/base per ogni singolo EA o indicatore del futuro che deve funzionare in ogni scenario.
Un EA finale ha quindi questo aspetto:
Se avessi il tempo, scriverei un articolo e fornirei le fonti. Non è un segreto, non c'è nessuna magia.
Ho guardato l'interfaccia grafica che hai creato. Mi piace molto. Dimmi, l'hai scritta tu o hai usato qualche libreria MQL?
Grazie.
No, nessuna libreria. L'ho progettata da zero. In realtà solo CCanvas di quelli originali è stato adattato, nient'altro.
Grazie.
No, nessuna libreria. L'ho sviluppato da zero da solo. In realtà, solo CCanvas è adattato da quelli originali, nient'altro.