Discussione sull’articolo "Controlli Grafici Personalizzati. Parte 3. Moduli"
Un lavoro buono e utile, Dimitri. C'è un suggerimento per la quarta parte: "Form Wizard" o "Visual Form Editor". Cosa ne pensi?
Rispetto, Dimitri. Hai fatto un ottimo lavoro.
Ti prego di accettare alcune critiche per la prossima versione delle classi v4.
1. Non c'è abbastanza astrazione nel progetto di base. È risultato che ogni controllo che avete agisce come un'unità indipendente. Di conseguenza, non è possibile combinarli in un array, ad esempio.
2. Ogni classe di un elemento ha ora, in linea di massima, un insieme unico di funzioni. Questo non è un bene. Dovrebbe esserci un antenato comune, le cui funzioni sono semplicemente sovrascritte nei discendenti. Soprattutto perché ci sono così tante funzioni con lo stesso nome nelle classi attuali. cosa impedisce di creare un antenato comune?
3. se appare una classe base, sarà possibile nascondere la gestione degli eventi all'interno dei discendenti, invece di metterli tutti all'esterno del modulo. per creare una cascata di eventi all'interno degli oggetti (simile ai CSS nel web).
Ma in generale, tutte e tre le parti dell'articolo sono degne di essere premiate, in particolare mi sono piaciuti i "nudges" quando si premono i pulsanti e le loro risposte interattive alla pressione in base allo stato dell'elemento.
PS.
E il menu multilivello si finisce ancora, un articolo separato su di esso non è necessario, troppo grasso per un compito così piccolo per scrivere un nuovo articolo. Che sia solo un aggiornamento nella versione v4.
La classe CTreeCtrl può essere presa dall'articolo https://www.mql5.com/it/articles/272 o CTreeNode offerto nel kit MT.
- 2011.03.16
- o_O
- www.mql5.com
Un lavoro buono e utile, Dimitri. C'è un suggerimento per la quarta parte: "Form Wizard" o "Visual Form Editor". Cosa ne pensi?
Personalmente, lo vedo positivamente. Ma è necessario? Visual semplifica solo il posizionamento degli oggetti. Se lo si fa in modo corretto, è necessario creare il codice per gli oggetti creati, legare le variabili o le classi all'oggetto. E, soprattutto, la gestione degli eventi.
Ma in queste classi non astratte non si può fare. Sono molto manuali. In molti punti è necessario scrivere gli oggetti appena creati e la loro elaborazione.
Per gli eventi, ad esempio, non esiste una divisione in sistema e utente - come Draw (sistema di base) e OnDraw - aggiunta da parte dell'utente con il proprio disegno.
In altre strutture (ad esempio Joomla!) non esiste una sola funzione personalizzata OnDraw. È divisa in due: BeforDraw e AfterDraw. In altre parole, il programmatore può gestire l'evento di sistema EVENT_DRAW - sia prima dell'inizio del disegno di sistema che dopo la sua fine.
Rispetto, Dimitri. Hai fatto un ottimo lavoro.
Ti prego di accettare alcune critiche per la prossima versione delle classi v4.
1. Non c'è abbastanza astrazione nel progetto di base. È risultato che ogni controllo che avete agisce come un'unità indipendente. Di conseguenza, non è possibile combinarli in un array, ad esempio.
2. Ogni classe di un elemento ha ora, in linea di massima, un insieme unico di funzioni. Questo non è un bene. Dovrebbe esserci un antenato comune, le cui funzioni sono semplicemente sovrascritte nei discendenti. Soprattutto perché ci sono così tante funzioni con lo stesso nome nelle classi attuali. cosa impedisce di creare un antenato comune?
3. se appare una classe base, sarà possibile nascondere la gestione degli eventi all'interno dei discendenti, invece di metterli tutti all'esterno del modulo. per creare una cascata di eventi all'interno degli oggetti (simile ai CSS nel web).
Ma in generale, tutte e tre le parti dell'articolo sono degne di essere premiate, in particolare mi sono piaciuti i "nudges" quando si premono i pulsanti e le loro risposte interattive alla pressione in base allo stato dell'elemento.
PS.
4. Un menu multilivello si finisce ancora, un articolo separato su di esso non è necessario, troppo grasso per un compito così piccolo per scrivere un nuovo articolo. Che sia solo un aggiornamento della versione v4.
La classe ad albero CTreeCtrl può essere presa dall'articolo https://www.mql5.com/it/articles/272 o CTreeNode offerto nel kit MT.
1- È possibile assemblare controlli di tipo singolo in un array. Perché si dovrebbero raccogliere controlli dissimili in un array?
2. Se si usa una classe base (una per tutti i controlli), significa che deve avere tutti i metodi che possono avere tutte le sottoclassi. Con le classi indipendenti, nell'elenco a discesa dei metodi (durante lo sviluppo), abbiamo solo i metodi che esistono effettivamente nella classe. A mio parere, questo è un punto molto importante. Mi immagino qualcuno che cerca di chiamare il metodo SetWidth() per una barra di scorrimento verticale.
Il secondo argomento - tutte le classi sono commentate per doxygen, se c'è una classe base e delle sottoclassi, non ci sarà una strutturazione così ovvia nella documentazione.
Cerco di creare soluzioni già pronte, in modo che possano essere utilizzate a "occhi chiusi". Per accelerare il processo di creazione di un nuovo controllo, è possibile utilizzare un modello con tutti i metodi obbligatori.
3. Non capisco bene. Se un controllo contiene un altro controllo, la sua gestione degli eventi viene nascosta. In ogni caso, dovrete chiamare Event() per ogni controllo.
4. Non so, forse... Ho una mia classe appositamente progettata per la creazione di menu, non è necessario chiamare AddNode(), viene chiamato AddItem() e il livello è determinato dal numero di spazi con cui inizia il nome dell'elemento. Il processo di creazione di un albero è molto chiaro. Finora funziona con la visualizzazione nel controllo dei commenti e dei tasti. In generale, è possibile creare diversi menu ad albero: 1) come un normale menu principale con schede a discesa, 2) visualizzazione degli elementi di una scheda e del percorso verso l'alto, 3) con visualizzazione ad albero (come windos explorer).
1. Personalmente, lo vedo positivamente. Ma è necessario? La visualizzazione semplifica solo il posizionamento degli oggetti. Se lo si fa in modo corretto, è necessario creare un codice per gli oggetti creati, legare variabili o classi all'oggetto. E soprattutto, l'elaborazione degli eventi.
2. Ma in queste classi non astratte non si può fare. Sono molto manuali. È necessario scrivere in molti punti gli oggetti appena creati e la loro elaborazione.
Per gli eventi, ad esempio, non esiste una divisione in sistema e utente - come Draw (sistema di base) e OnDraw - un'aggiunta dell'utente con il proprio disegno.
In altre strutture (ad esempio Joomla!) non esiste una sola funzione personalizzata OnDraw. È divisa in due: BeforDraw e AfterDraw. In altre parole, il programmatore può gestire l'evento di sistema EVENT_DRAW - sia prima dell'inizio del disegno del sistema che dopo la sua fine.
1. Sarà possibile generare automaticamente il codice per la gestione degli eventi dei controlli e ottenere funzioni di evento per tutti i controlli, come HScrollBar1_OnChange().....
2. Non ci sono ancora eventi, per esempio, quando i valori vengono impostati programmaticamente, gli eventi vengono generati solo quando i valori vengono inseriti dall'utente. Questo è un minimo sufficiente, niente di più. Altrimenti, chi impara a programmare da solo sarà sommerso dagli eventi.
Un lavoro buono e utile, Dimitri. C'è un suggerimento per la quarta parte: "Form Wizard" o "Visual Form Editor". Come lo vedete?
... C'è un suggerimento per la parte 4: "Form Wizard" o "Visual Form Editor". Cosa ne pensate?
1. I controlli di tipo singolo possono essere assemblati in un array. Perché raccogliere diversi tipi di controlli in un array?
Per far confluire tutto in un ciclo e liberarsi di tipi specifici nella gestione degli eventi.
2. Se si usa una classe base (una per tutti i controlli), significa che deve avere tutti i metodi che possono avere le sottoclassi. Con le classi indipendenti, nell'elenco a discesa dei metodi (durante lo sviluppo), abbiamo solo i metodi che esistono effettivamente nella classe. A mio parere, questo è un punto molto importante. Posso immaginare qualcuno che cerca di chiamare il metodo SetWidth() per una barra di scorrimento verticale.
Tutte le funzioni della classe base sono dei tappi vuoti con una funzionalità generale minima. Anche se qualcuno chiama inconsapevolmente una funzione non correlata a un elemento, non succederà assolutamente nulla di male. è questa la forza dell'OOP. Polimorfismo.
Il secondo argomento - tutte le classi sono commentate per doxygen, se c'è una classe base e delle sottoclassi, non ci sarà una strutturazione così ovvia nella documentazione.
Ci sarà. Solo che sarà diversa... :)
- 2010.03.25
- MetaQuotes Software Corp.
- www.mql5.com
1. per inserire tutto in un ciclo e sbarazzarsi di tipi specifici nella gestione degli eventi.
2. Il punto è che la classe base non ha implementazioni di funzioni di azioni specifiche. Tutte le funzioni della classe base sono dei tappi vuoti con funzionalità generali minime. Anche se qualcuno chiama inconsapevolmente una funzione non correlata a un elemento, non succederà assolutamente nulla di male. è questa la forza dell'OOP. Il polimorfismo, invece.
3. succederà. solo che sarà diverso.... :)
1. È tutto? Per il bene di questo per scherzare con il punto 2 - metodo dump?
Alternative:
1) La necessità di aggiungere manualmente una chiamata Event() per ogni classe (che consiste nel copiare con il mouse una riga e cambiare qualche lettera a sinistra del punto) e allo stesso tempo, nell'elenco dei metodi di ogni classe abbiamo solo metodi di lavoro corrispondenti a questa classe, cliccato il punto, l'elenco è saltato fuori e tutto è chiaro.
2) Elaborazione automatica di Event() di tutte le classi, mentre una funzione dovrà ancora essere chiamata da OnChartEvent(), e dall'altra parte: un dump dei metodi nell'elenco. Inoltre, dovrete distruggere i puntatori nel deinit.
Guardate un po' più a fondo e più in là, perché tutti gli Event() dovrebbero essere processati in un ciclo, ogni controllo dovrebbe avere le proprie azioni per il suo Event(), i controlli non servono solo per inserire un valore e non solo per far muovere e sfarfallare tutto sullo schermo, ma anche (nella misura principale) per usare i valori inseriti nel programma.
3. Dovrete leggere circa la metà dei metodi di un controllo in un punto della documentazione e l'altra metà in un altro.
1. Tutto qui? Per il bene di questo, per incasinare il punto 2 - lo scarico dei metodi?
Alternative:
1) La necessità di aggiungere manualmente una chiamata Event() per ogni classe (che consiste nel copiare con il mouse una riga e cambiare qualche lettera a sinistra del punto) e allo stesso tempo, nell'elenco dei metodi di ogni classe abbiamo solo metodi di lavoro corrispondenti a questa classe, cliccato il punto, l'elenco è caduto fuori e tutto è chiaro.
2) Elaborazione automatica di Event() di tutte le classi, mentre una funzione dovrà ancora essere richiamata da OnChartEvent(), e d'altra parte: un dump dei metodi nell'elenco. Inoltre, dovremo distruggere i puntatori nel deinit.
Guardate un po' più a fondo e più in là, perché tutti gli Event() dovrebbero essere processati in un ciclo, ogni controllo dovrebbe avere le proprie azioni per il suo Event(), i controlli non servono solo per inserire un valore e non servono solo per far muovere e sfarfallare tutto sullo schermo, ma anche (nella misura principale) per usare i valori inseriti nel programma.
3. Dovrete leggere circa la metà dei metodi di un controllo in un punto della documentazione e l'altra metà in un altro.
Avete fatto tutto bene.
Date le possibilità di ME è abbastanza comodo, il minimalismo giapponese nell'era del kitsch totale, c'è tutto, niente di superfluo.
Chi vuole fare il loop degli oggetti può implementare una shell postfix dove può scrivere quello che vuole.
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Il nuovo articolo Controlli Grafici Personalizzati. Parte 3. Moduli è stato pubblicato:
Questo è l'ultimo dei tre articoli dedicati ai controlli grafici. Esso tratta la creazione del componente principale dell'interfaccia grafica - il modulo - e il suo utilizzo in combinazione con altri controlli. Oltre alle classi form, alla libreria di controllo sono state aggiunte le classi CFrame, CButton, CLabel.
Il modulo si basa sugli oggetti grafici "Rectangle Label" OBJ_RECTANGLE_LABEL con l'uso di diversi pulsanti OBJ_BUTTON. Visivamente, il modulo rappresenta un rettangolo (Fig. 1) con una barra nella parte superiore del modulo in cui vengono visualizzati il nome del modulo e i pulsanti di controllo.
Un pulsante che sposta il modulo (con un'immagine a mano) si trova a sinistra, il pulsante di minimizzazione (con un'immagine rettangolare) e il pulsante di chiusura (con un'immagine incrociata) si trovano a destra.
Fig. 1. Modulo
Per spostare il modulo, premere il pulsante di spostamento (il pulsante entrerà nella posizione premuta) e fare click in un punto qualsiasi del grafico in cui il modulo deve essere spostato. Di conseguenza, il pulsante di spostamento verrà rilasciato e il modulo si sposterà nella posizione indicata (il suo angolo in alto a sinistra sarà situato sul punto cliccato).
Autore: Dmitry Fedoseev