Galleria di interfacce utente scritte in MQL - pagina 55
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
Ho anche la tela a schermo intero che viene ridisegnata completamente ogni volta che cambio, ma non impiega più di 50ms...
La cosa più costosa è disegnare il testo. Pertanto, per non utilizzare TextOut ogni volta, li memorizzo in array. Il risultato è molto più veloce.
Sì, TextOut viene utilizzato. Penserò a cosa si può fare con esso.
In questo caso, la semplice aritmetica funziona: la somma delle aree di 10 - 17 finestre è molto più grande dello schermo intero. Concordo. Più i disegni aggiuntivi secondari necessari per creare ombre, icone, cornici....
E riguardo a TextOut controllerò e scriverò. Idea interessante.
Non capisco la tua semplice aritmetica :). Nella mia aritmetica non c'è bisogno di disegnare i pixel che non sono visibili all'utente, e la dimensione massima della tela per il disegno è limitata dalla dimensione del display in pixel.
Disegno in livelli, indipendentemente dal numero di finestre, tutti in un'unica bitmap. Le finestre possono essere anche un centinaio. Le primitive semplici vengono disegnate in un tempo minuscolo. La cosa più lunga, come ho scritto sopra, sono i testi. Ma con l'aiuto di TextOut al primo utilizzo, e poi già da array pronti.
È necessario approvare un piano per il lavoro futuro.
Pubblicherò un aggiornamento ogni settimana. Sabato o domenica.
1. Nella prossima release rilascerò una versione completa del motore. Risolverò i bug e velocizzerò il rendering.
2. La seconda release sarà dedicata alle tabelle. Ripristinerò le funzionalità di base.
3. La terza release sarà dedicata alle tabelle dinamiche. Spero di implementarle in una settimana. Ci proverò.
4. Quarta versione - finestra dinamica. Cercherò di pubblicare la versione finita.
A questo punto, le versioni di base del costruttore, del motore e del linguaggio di markup possono essere considerate complete.
Aprirò sicuramente un ramo di modelli scritti in codice KIB, dove posterò le finestre e i gruppi di elementi finiti. Con illustrazioni per rendere più facile il lavoro di chi vuole costruire l'interfaccia.
E cercherò di scrivere articoli tutorial in modo che le persone possano utilizzare l'intera gamma di possibilità.
In questo thread continuerò a pubblicare codice, immagini e materiale esplicativo come posso. Sarò molto impegnato nel lavoro di cui sopra.
Non capisco la tua semplice aritmetica :). Nella mia aritmetica non è necessario renderizzare i pixel che non sono visibili all'utente e la dimensione massima della tela per il rendering è limitata dalla dimensione del display in pixel.
Disegno in livelli, indipendentemente dal numero di finestre, tutti in un'unica bitmap. Le finestre possono essere anche un centinaio. Le primitive semplici vengono disegnate in un tempo minuscolo. La cosa più lunga, come ho scritto sopra, sono i testi. Ma con l'aiuto di TextOut al primo utilizzo, e poi già da array pronti.
Lavorare con una tela di grandi dimensioni ha molte limitazioni. Ho già pensato a questa opzione e ne ho anche discusso con Nikolay.
Mi spiego: lo fate perché utilizzate la classe Ccanvas standard. Ci sono soluzioni già pronte all'interno delle quali si lavora. Ma io non uso la classe Ccanvas. Tutti i codici di rendering sono uno sviluppo personale. Ecco perché non mi attengo al concetto di un unico canvas per TUTTO. A mio parere, è una soluzione tecnicamente scomoda e inefficiente in un ambiente grafico. È più facile usare insiemi di oggetti bitmap e collegarvi risorse già pronte che avere un'unica bitmap e costruire programmaticamente l'interazione delle immagini su di essa. È persino difficile da immaginare. Ma non è questo l'aspetto principale.
Immaginate quanto sia più difficile realizzare il concetto di GUI a più finestre se si dispone di una sola tela. Non mi assumerei mai un compito del genere.
Ma anche questo non è decisivo. Il motivo principale per cui si rifiuta l'idea di un unico canvas per tutte le immagini: quando c'è un solo canvas, lo spostamento delle finestre dell'interfaccia richiede il ridisegno all'interno dell'ambiente MQL. Al contrario, se ogni finestra occupa un proprio oggetto bitmap e viene spostata dalla funzione ObjectSetInteger(), - il ridisegno degli oggetti spostati ricade su funzioni standard che lavorano al di fuori dell'ambiente MQL. Pertanto, è molto più veloce.
Si tratta solo di una direzione di sviluppo diversa in cui altre soluzioni funzionano in modo più efficace.
Grazie mille per il suggerimento su TextOut. Indagherò su questo punto.
I rami del template sono scrittiin codice KIB che
Sì, per il debug implementerò la disconnessione del programma utente dal motore, se è questo che intendevi. Probabilmente mi sono spiegato male.
Lavorare con una sola tela di grandi dimensioni presenta molte limitazioni. Ho già pensato a questa opzione e ne ho anche discusso con Nikolay.
Mi spiego: voi lo fate perché usate la classe Ccanvas standard. Ci sono soluzioni già pronte all'interno delle quali si lavora. Ma io non uso la classe Ccanvas. Tutti i codici di rendering sono scritti per sviluppo personale. Quindi non mi attengo al concetto di un unico canvas per TUTTO. A mio parere, è una soluzione tecnicamente scomoda e inefficiente in un ambiente grafico. È più facile usare insiemi di oggetti bitmap e collegarvi risorse già pronte, piuttosto che avere una sola bitmap e costruire programmaticamente l'interazione delle immagini su di essa. È persino difficile da immaginare. Ma non è questo l'aspetto principale.
Immaginate quanto sia più difficile realizzare il concetto di GUI a più finestre se si dispone di una sola tela. Non mi assumerei mai un compito del genere.
Ma anche questo non è decisivo. Il motivo principale per cui si rifiuta l'idea di un unico canvas per tutte le immagini: quando c'è un solo canvas, spostare le finestre dell'interfaccia richiede un ridisegno all'interno dell'ambiente MQL. Al contrario, se ogni finestra occupa un proprio oggetto bitmap e viene spostata tramite ObjectSetInteger(), - il ridisegno durante lo spostamento ricade su funzioni standard che lavorano al di fuori dell'ambiente MQL. Pertanto, è molto più veloce.
Si tratta solo di una direzione di sviluppo leggermente diversa, in cui altre soluzioni funzionano in modo più efficiente.
Grazie mille per il suggerimento su TextOut. Indagherò su questo punto.
Non sto usando il kanvas standard :).
E ho trovato più semplice implementare un'interfaccia multi-finestra su una sola bitmap. Ma a ciascuno il suo!
E in pratica sembra essere più veloce ridisegnare l'intera tela che usare ObjectSetInteger, ecc....