Fare un progetto in crowdsourcing su Canvas - pagina 36
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
Qualsiasi elemento di un dialogo (modulo, controllo (pulsante, lista, immagine)) ha alcune proprietà. La programmazione procedurale non definisce il concetto di "proprietà" o "campo". Nella programmazione procedurale, abbiamo funzioni e variabili (globali o locali). Ma le variabili sono comuni a, quindi non possono essere usate per descrivere le proprietà di ogni singolo controllo. Allora qual è la soluzione? Una semplice: le strutture!
Sì, una struttura può avere una descrizione delle proprietà necessarie di un controllo, così come un array di controlli annidati (fino all'infinito).
Tutta questa roba è memorizzata in un array di finestre di dialogo.
Possiamo renderlo più universale: la struttura di descrizione del controllo consiste in due matrici: la matrice delle proprietà e la matrice dell'elemento slave. Un array di proprietà è un array di strutture di una coppia proprietà-valore. Con questo approccio, ogni nuovo controllo può avere qualsiasi insieme arbitrario di proprietà. Ma questo non è conveniente per l'elaborazione. Sarebbe più logico specificare le proprietà specifiche del controllo nella struttura: dimensioni, posizione, colore, cornice, e così via - tutto ciò di cui ogni controllo ha bisogno.
E la struttura conterrà anche un array di pixel del controllo.
Quando viene ricevuto un evento del mouse, tutti gli array vengono fatti girare per controllare se il cursore colpisce un particolare controllo. Il controllo viene eseguito dall'ultimo al primo controllo.
Una volta determinato quale controllo ha il cursore, l'elemento dell'array dato viene inviato alla funzione repaint e quindi l'array di risorse viene aggiornato e l'immagine sul grafico viene aggiornata.
Non so cosa abbia postato e cosa abbia fatto in materia di GUI, ma nei miei thread non ha dato nessun suggerimento tecnico, nessuna soluzione e nessuna discussione sull'argomento. Solo trolling vuoto, indicando soluzioni di terzi ed esortando a non reinventare la ruota.
Torniamo all'argomento in questione.
Per quanto ho familiarità con la libreria standard (molto poco in realtà), gli elementi e le finestre sono composti da oggetti MT. Cioè, nel nostro contesto - non sono disegnati sulla tela. Naturalmente sono disegnati, ma non sulla nostra tela, il che ci impedisce di controllare i colori dei pixel, creare gradienti di superficie e altro.
In teoria, potremmo prendere la struttura della libreria, copiarla e farne un analogo sul kanvas. In teoria...
Il problema è che CCanvas stesso non è adatto per fare una GUI su di esso. Perché? Perché il sistema kanvas è usato principalmente per le primitive grafiche. Quindi, in sostanza, questa classe non fornisce altro che primitive. L'archetipo GUI deve essere costruito da te. E in questo caso, la classe non è necessaria. È più conveniente accontentarsi delle proprie soluzioni. Dopo tutto, si può disegnare un marcatore rettangolare senza la classe. Proprio come si può creare o caricare una tela. È molto semplice. Pertanto, ho preferito la mia soluzione.
Ma qualcuno non può fare a meno di CCanvas. Per questo non insisto.
Il problema con CCanvas è che la sua interfaccia grafica è strettamente legata alla finestra del grafico.
Cioè, non si può fare una finestra completa come modulo di interfaccia del terminale.
E sarebbe molto bello scrivere i propri moduli di interfaccia.
leggermente sbagliato, naturalmente :-)
Ho postato un'interfaccia alla DLL Tcl (che è Tool Common Language), che ha grafica Tk che è condivisa come una GUI in Python/Ruby/etc
l'obiettivo non era quello di ottenere una GUI, ma un bel sottoprodotto :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
a mio parere conveniente e soprattutto conciso :-)
Non sto agitando nessuno - conosco tcl/tk, lo uso, condivido la mia esperienza (vedi sourceforge atcl)
Sì Max, è esattamente quello di cui sto parlando TCL e del tuo prototipo di cui stavamo discutendo in quel momento. C'era una restrizione che l'utente doveva avere la libreria appropriata installata sul suo computer. Non sembrava difficile, ma è comunque una certa limitazione.
Lasciamo questo nel passato. Max, unisciti a noi nella discussione. Roman, partecipa anche tu ))).
Da quanto sopra si può capire che un elemento di struttura è un controllo di dialogo specifico, contiene le proprie proprietà e può contenere controlli annidati. L'insieme delle proprietà di un tale controllo universale è limitato solo dall'immaginazione dello sviluppatore.
Naturalmente, possiamo evitare la struttura e descrivere le proprietà dei controlli in un array multidimensionale, ma non è inizialmente conveniente perché dobbiamo ricordare chiaramente quale indice del controllo memorizza ogni proprietà. E l'array non può contenere tipi di dati eterogenei. Risulta che la descrizione dell'elemento di controllo nella programmazione procedurale è possibile solo attraverso le strutture. Cioè, l'elemento struttura è un controllo concreto, cioè l'oggetto concreto del dialogo con le sue proprietà.
Il problema con CCanvas è che la sua interfaccia grafica è strettamente legata alla finestra del grafico.
Cioè, non si può fare una finestra completa come modulo di interfaccia del terminale.
E sarebbe molto bello scrivere i propri moduli di interfaccia.
Poi ci sarà l'inverso: collegare l'interfaccia al grafico. Per esempio, per fare un pulsante che sia strettamente legato all'ora e al prezzo.
Una GUI separata può essere scritta in pochissimo tempo - con tutte le tabelle, schede, menu e fischietti. In C# o anche in BASIC. E all'interno del grafico è un problema significativo per le applicazioni esterne.
Qualsiasi elemento di un dialogo (modulo, controllo (pulsante, lista, immagine)) ha alcune proprietà. La programmazione procedurale non definisce il concetto di "proprietà" o "campo". Nella programmazione procedurale, abbiamo funzioni e variabili (globali o locali). Ma le variabili sono comuni a, quindi non possono essere usate per descrivere le proprietà di ogni singolo controllo. Allora qual è la soluzione? Una semplice: le strutture!
Sì, una struttura può avere una descrizione delle proprietà necessarie di un controllo, così come un array di controlli annidati (fino all'infinito).
Tutta questa roba è memorizzata in un array di finestre di dialogo.
Possiamo renderlo più universale: la struttura di descrizione del controllo consiste in due matrici: la matrice delle proprietà e la matrice dell'elemento slave. Un array di proprietà è un array di strutture di una coppia proprietà-valore. Con questo approccio, ogni nuovo controllo può avere qualsiasi insieme arbitrario di proprietà. Ma questo non è conveniente per l'elaborazione. Sarebbe più logico specificare le proprietà specifiche del controllo nella struttura: dimensioni, posizione, colore, cornice, e così via - tutto ciò di cui ogni controllo ha bisogno.
E la struttura conterrà anche un array di pixel del controllo.
Quando viene ricevuto un evento del mouse, tutti gli array vengono fatti girare per controllare se il cursore colpisce un particolare controllo. Il controllo viene eseguito dall'ultimo controllo al primo.
Una volta determinato quale controllo ha il cursore, l'elemento nell'array viene inviato alla funzione repaint e quindi aggiorna l'array di risorse e aggiorna l'immagine sul grafico.
1. Supponiamo che abbiate progettato una semplice struttura di controlli di base - una finestra, un pulsante, una casella di controllo. Ognuno è costituito da un insieme di componenti - oggetti. Checkbox - base, testo, icona. Pulsante - base, testo, icona e così via. Ogni oggetto di ogni elemento deve avere il proprio insieme di proprietà. Puoi scriverli in una struttura o in una classe, ma secondo me non è conveniente. Perché? - Perché quando li metti in una finestra, devi trovarli sulla tela con il cursore. Quando si sposta il cursore, devono essere messi a fuoco. Per questo, le loro coordinate attuali devono essere in un array. Ed è più conveniente se tutte le loro proprietà (comprese le coordinate attuali) sono nello stesso array. In questo modo si può accedere immediatamente a qualsiasi proprietà di qualsiasi elemento sulla tela che è il focus del cursore. È anche più facile fare un loop attraverso un array di elementi.
Cioè, è più facile attraversare UNA matrice in un ciclo per trovare l'elemento che il cursore ha colpito. È ancora più conveniente se questo array è globale. Poi, in qualsiasi funzione, potete prendere le informazioni necessarie da essa e cambiare i valori delle proprietà necessarie, degli elementi necessari.
Questo è l'accesso più breve ed efficiente agli elementi e la loro elaborazione più veloce. Questo è il mio "nucleo".
2. Tuttavia, conoscendo i capricci dei professionisti per cercare la massima imitazione di OOP standard, non propongo questa tecnologia.
3. un array di pixel non ha bisogno di essere memorizzato da nessuna parte. Si costruisce al momento della necessità, secondo i parametri degli elementi dell'array. Per esempio: dovete ridisegnare la finestra. Chiamiamo la funzione repaint. La funzione chiama l'array di elementi, vede tutte le sue proprietà, dichiara l'array di pixel, calcola le sue dimensioni, disegna i suoi oggetti successivamente nel ciclo, chiama ResourceCreate(). Questo è tutto.
Un elemento catturato sotto il cursore viene inviato alla stessa funzione per essere ridisegnato. Riceve una notifica (flag di ridipintura) e il suo numero nell'array di elementi. Successivamente, la funzione chiama la risorsa richiesta tramite ResourceReadImage(), la mette nell'array di pixel e poi, all'interno dell'array di pixel, trova l'area dell'elemento richiesto e ridipinge tutti i suoi oggetti. Questo è tutto.
1. Supponiamo che abbiate progettato una semplice struttura di controlli di base - una finestra, un pulsante, una casella di controllo. Ognuno consiste in un insieme di parti costitutive - gli oggetti. Checkbox - base, testo, icona. Pulsante - base, testo, icona e così via. Ogni oggetto di ogni elemento deve avere il proprio insieme di proprietà. Puoi scriverli in una struttura o in una classe, ma secondo me non è conveniente. Perché? - Perché quando li metti in una finestra, devi trovarli sulla tela con il cursore. Quando si sposta il cursore, devono essere messi a fuoco e per questo le loro coordinate attuali devono essere in un array. Ed è più conveniente se tutte le loro proprietà (comprese le coordinate attuali) sono nello stesso array. In questo modo si può accedere immediatamente a qualsiasi proprietà di qualsiasi elemento sulla tela che è il focus del cursore. È anche più facile fare un loop attraverso un array di elementi.
Cioè, è più facile attraversare UNA matrice in un ciclo per trovare l'elemento che il cursore ha colpito. È ancora più conveniente se questo array è globale. Poi, in qualsiasi funzione, potete prendere le informazioni necessarie da essa e cambiare i valori delle proprietà necessarie, degli elementi necessari.
Questo è l'accesso più breve ed efficiente agli elementi e la loro elaborazione più veloce. Questo è il mio "nucleo".
2. Tuttavia, conoscendo i capricci dei professionisti per cercare la massima imitazione di OOP standard, non propongo questa tecnologia.
3. un array di pixel non ha bisogno di essere memorizzato da nessuna parte. Si costruisce al momento della necessità, secondo i parametri degli elementi dell'array. Per esempio: dovete ridisegnare la finestra. Chiamiamo la funzione repaint. La funzione chiama l'array di elementi, vede tutte le sue proprietà, dichiara l'array di pixel, calcola le sue dimensioni, disegna i suoi oggetti successivamente nel ciclo, chiama ResourceCreate(). Questo è tutto.
Un elemento catturato sotto il cursore viene inviato alla stessa funzione per essere ridisegnato. Riceve una notifica (flag di ridipintura) e il suo numero nell'array di elementi. Successivamente, la funzione chiama la risorsa richiesta tramite ResourceReadImage(), la mette nell'array di pixel e poi, all'interno dell'array di pixel, trova l'area dell'elemento richiesto e ridipinge tutti i suoi oggetti. Questo è tutto.
In realtà, questo dovrebbe funzionare indipendentemente dalla tecnologia di costruzione. Ma può essere percepito in modo diverso. Nel vostro caso, passate un array nel ciclo e determinate quale controllo ha il cursore in quel momento. Così, quando si definisce l'indice si vedono immediatamente le proprietà dell'elemento trovato. Ma come si possono memorizzare diversi tipi di dati in un unico grande array?
In realtà, questo dovrebbe accadere indipendentemente dalla tecnologia di costruzione. Si può solo percepire in modi diversi. Nel vostro caso, fate un ciclo attraverso l'array e determinate quale controllo ha il cursore al momento. Così, quando si definisce l'indice si vedono immediatamente le proprietà dell'elemento trovato. Ma come si possono memorizzare diversi tipi di dati in un unico grande array?
In linea di principio, è possibile generalizzare i tipi. Sono giunto alla conclusione che non succederà nulla di male se la maggior parte delle proprietà degli oggetti sono di tipo int. Tutti gli altri tipi abbreviati (il doppio è praticamente assente nelle proprietà degli oggetti grafici) li ho trascurati per motivi di semplificazione. Il "superamento" della memoria è così insignificante che non ha senso pensarci. Naturalmente, non possiamo andare per un tale sacrilegio per amore della professionalità))). Ma siamo nel 21° secolo e non mi sento minacciato dai falò).
Ho reso i nomi degli oggetti come numeri, e li ho messi nella serie generale delle proprietà degli oggetti.
L'unico posto dove avevo bisogno di un tipo diverso di dati erano i parametri di controllo. Lì ho creato un secondo kernel, che memorizza le proprietà dei parametri, e i valori stessi nel tipo stringa, che posso facilmente lanciare a qualsiasi cosa (o meglio, a ciò che è prescritto nelle proprietà dei parametri).
SUGGERIMENTO: per "parametro dell'elemento di controllo" si intende il PARAMETRO GESTITO DALL'ATTREZZATURA.1. Supponiamo che abbiate progettato una semplice struttura di controlli di base - una finestra, un pulsante, una casella di controllo. Ognuno consiste in un insieme di parti costitutive - gli oggetti. Checkbox - base, testo, icona. Pulsante - base, testo, icona e così via. Ogni oggetto di ogni elemento deve avere il proprio insieme di proprietà. Puoi scriverli in una struttura o in una classe, ma secondo me non è conveniente. Perché? - Perché quando li metti in una finestra, devi trovarli sulla tela con il cursore. Quando si sposta il cursore, devono essere messi a fuoco. Per questo, le loro coordinate attuali devono essere in un array. Ed è più conveniente se tutte le loro proprietà (comprese le coordinate attuali) sono nello stesso array. In questo modo si può accedere immediatamente a qualsiasi proprietà di qualsiasi elemento sulla tela che è il focus del cursore. È anche più facile fare un loop attraverso un array di elementi.
Cioè, è più facile attraversare UNA matrice in un ciclo per trovare l'elemento che il cursore ha colpito. È ancora più conveniente se questo array è globale. Poi, in qualsiasi funzione, potete prendere le informazioni necessarie da essa e cambiare i valori delle proprietà necessarie, degli elementi necessari.
Questo è l'accesso più breve ed efficiente agli elementi e la loro elaborazione più veloce. Questo è il mio "nucleo".
2. Tuttavia, conoscendo i capricci dei professionisti per cercare la massima imitazione di OOP standard, non propongo questa tecnologia.
3. un array di pixel non ha bisogno di essere memorizzato da nessuna parte. Si costruisce al momento della necessità, secondo i parametri degli elementi dell'array. Per esempio: dovete ridisegnare la finestra. Chiamiamo la funzione repaint. La funzione chiama l'array di elementi, vede tutte le sue proprietà, dichiara l'array di pixel, calcola le sue dimensioni, disegna i suoi oggetti successivamente nel ciclo, chiama ResourceCreate(). Questo è tutto.
Un elemento catturato sotto il cursore viene inviato alla stessa funzione per la ridipintura. Riceve una notifica (flag di ridipintura) e il suo numero nell'array di elementi. Poi la funzione chiama la risorsa richiesta tramite ResourceReadImage(), la mette nell'array di pixel, e poi trova l'area dell'elemento richiesto all'interno dell'array di pixel e ridipinge tutti i suoi oggetti. Questo è tutto.
ugh questa eterna negatività a oop, proprio oltre la linea
Vi siete mai chiesti come è nato? Il punto è che molte persone che scrivono in stile procedurale e non conoscono l'OOP si trovano di fronte al desiderio di raggruppare funzioni, e poi questo desiderio si sviluppa in un desiderio di combinare queste funzioni in un'area di memoria e riferirsi ad essa, cioè riferirsi fisicamente all'area con le funzioni che è memorizzata in una variabile. Poi vogliamo cambiare il nostro gruppo di funzioni selezionate senza duplicare il codice (otteniamo l'ereditarietà). Così una persona che inizialmente ha familiarità solo con lo stile procedurale qualche tempo dopo chiede perché ci sono così tante restrizioni in un mql (riferimento all'ereditarietà multipla).
In generale, si crede che sia più facile insegnare OOP in una volta sola, perché se una persona fa conoscenza con lo stile procedurale allora sarà molto difficile da riqualificare (per la maggior parte delle persone), ma ce ne sono altri, poiché inizialmente c'era solo lo stile procedurale... descritto sopra.
ZS C'è una variazione sull'OOP in generale, una sorta di familiarità con l'OOP a livello di codice procedurale, e l'utilizzo dell'OOP al massimo.
Una classe è un riferimento a una memoria (tabella) di funzioni, che possono essere riscritte ed estese mantenendo l'array principale + il riferimento alle variabili. e ho dimenticato cos'altro.... (come 32 byte)
Con il problema della ricerca eterna, ho recentemente confrontato la funzione di ordinamento integrata con Red sort (uno dei modelli), perdita di velocità di 3-6 volte in certe condizioni (integrata persa =)
Sulla GUI penso che ci siano metodi standard.
,
Ugh, questa negatività perpetua verso l'OOP, attraverso le linee.
Vi siete mai chiesti come è nato? La questione è che molte persone che scrivono in stile procedurale e non conoscono l'OOP affrontano il desiderio di raggruppare funzioni, poi questo desiderio cresce in un desiderio di combinare queste funzioni in un'area di memoria e riferirsi ad essa, cioè riferirsi fisicamente ad un'area con funzioni che è memorizzata in una variabile. Poi vogliamo cambiare il nostro gruppo di funzioni selezionate senza duplicare il codice (otteniamo l'ereditarietà). Così una persona che inizialmente ha familiarità solo con lo stile procedurale qualche tempo dopo chiede perché ci sono così tante restrizioni in un mql (riferimento all'ereditarietà multipla).
In generale, si crede che sia più facile insegnare OOP in una volta sola, perché se una persona fa conoscenza con lo stile procedurale allora sarà molto difficile da riqualificare (per la maggior parte delle persone), ma ce ne sono altri, poiché inizialmente c'era solo lo stile procedurale... descritto sopra.
ZS C'è una variazione sull'OOP in generale, una sorta di familiarità con l'OOP a livello di codice procedurale, e l'utilizzo dell'OOP al massimo.
Una classe è un riferimento a una memoria (tabella) di funzioni, che possono essere riscritte ed estese mantenendo l'array principale + il riferimento alle variabili. e ho dimenticato cos'altro.... (come 32 byte)
Con il problema della ricerca eterna, ho recentemente confrontato la funzione di ordinamento integrata con Red sort (uno dei modelli), perdita di velocità di 3-6 volte in certe condizioni (integrata persa =)
Sulla GUI penso che ci siano metodi standard.
,
Non ho nessuna negatività verso il concetto di OOP. Io stesso ne sono un aderente. Ho un negativo agli standard. Per essere più precisi, a seguirli senza cervello).
A parte questo, io sono per l'OOP. Ma io sono per un OOP semplificato.