Fare un progetto in crowdsourcing su Canvas - pagina 13
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
Per me, è più facile creare un team di sviluppo del prodotto, i cui membri, in misura concordata, riceveranno un profitto dalle vendite del prodotto (forse qualcuno è l'ideologo del progetto, qualcuno finanzia per una quota, qualcuno è il programmatore).
E dato che tutti sono motivati finanziariamente, per implementare anche le librerie necessarie per l'interfaccia come parte del progetto.
Per me, è più facile creare un team di sviluppo del prodotto, i cui membri, in misura concordata, riceveranno un profitto dalle vendite del prodotto (forse qualcuno è l'ideologo del progetto, qualcuno finanzia per una quota, qualcuno è il programmatore).
E poiché tutti sono finanziariamente motivati - per implementare all'interno del progetto e le librerie necessarie per l'interfaccia.
Ho letto il thread e ancora non capisco perché sia necessario disegnare un pulsante su Canvas da zero. Puoi spiegare senza emozioni?
perché gli sviluppatori di MT non sono onnipotenti ed è dispendioso in termini di tempo disturbarli con richieste insignificanti
Perché potrebbe essere utile:
1. l'interfaccia della bitmap è veloce. Così veloce che è quasi indistinguibile da quella del sistema. Per esempio, ho implementato elementi semitrasparenti con gradienti eanche quando si muovono sono resi in modo fluido senza ritardi visibili, tenendo conto della miscelazione dei colori e del calcolo del canale alfa su altri oggetti con gradienti semitrasparenti.
2. l'interfaccia è scalabile. Potete rendere l'applicazione più complessa e non rallenterà a causa della cancellazione e della creazione di un gran numero di oggetti del grafico. I costi di ridisegno sono minimi, appena un millesimo di secondo.
3. si possono creare controlli già pronti e se ne possono creare di nuovi, poiché si può fornire il proprio pool di eventi, per esempio:
OnMouseDown - ha premuto la LKM
OnMouseUp - ha premuto la LKM
OnMouseHoverOn - fa passare il cursore del mouse sopra un oggetto
OnMouseHoverOut - sposta il cursore del mouse dall'oggetto
OnMouseClick - preme e clicca entro i confini dell'oggetto
OnMouseDblClick - doppio clic del mouse entro i limiti dell'oggetto
OnDragStart - evento che si verifica una volta all'inizio del movimento con il tasto sinistro del mouse premuto
OnDragMove - evento generato durante il movimento con il tasto sinistro del mouse
OnDragEnd - evento generato dopo lo spostamento con LKM
OnPut - l'oggetto è castato in un altro oggetto
OnGet - l'oggetto viene scaricato in un altro oggetto
OnFocus - l'oggetto è stato messo a fuoco
OnBlur - l'oggetto perde il focus
OnResize - l'oggetto ha cambiato dimensione
OnParentResize - l'oggetto padre ha cambiato dimensione
OnKeyPress - tasto premuto
OnChange - valore di un campo cambiato
ecc.
Perché potrebbe essere utile:
1. l'interfaccia della bitmap è veloce. Così veloce che è praticamente indistinguibile dall'interfaccia del sistema. Per esempio, ho implementato elementi semitrasparenti con gradienti eanche quando si muovono, sono resi in modo fluido senza alcun ritardo visibile, tenendo conto della miscelazione dei colori e del calcolo del canale alfa su altri oggetti con gradienti semitrasparenti.
2. l'interfaccia è scalabile. Potete rendere l'applicazione più complessa e non rallenterà a causa della cancellazione e della creazione di un gran numero di oggetti del grafico. Il costo del ridisegno è minimo, è solo una sostituzione dell'immagine in un millesimo di secondo.
3. si possono creare controlli già pronti e se ne possono creare di nuovi, poiché si può fornire il proprio pool di eventi, per esempio:
OnMouseDown - ha premuto la LKM
OnMouseUp - ha premuto la LKM
OnMouseHoverOn - fa passare il cursore del mouse sopra un oggetto
OnMouseHoverOut - sposta il cursore del mouse dall'oggetto
OnMouseClick - preme e clicca entro i confini dell'oggetto
OnMouseDblClick - doppio clic del mouse entro i limiti dell'oggetto
OnDragStart - evento che si verifica una volta all'inizio del movimento con il tasto sinistro del mouse premuto
OnDragMove - evento generato durante il movimento con il tasto sinistro del mouse
OnDragEnd - evento generato dopo lo spostamento con LKM
OnPut - l'oggetto è castato in un altro oggetto
OnGet - l'oggetto viene scaricato in un altro oggetto
OnFocus - l'oggetto è stato messo a fuoco
OnBlur - l'oggetto perde il focus
OnResize - l'oggetto ha cambiato dimensione
OnParentResize - l'oggetto padre ha cambiato dimensione
OnKeyPress - un tasto premuto
OnChange - valore di un campo cambiato
ecc.
Esauriente, grazie!
@Igor Volodin, @Combinator, @Anatoli Kazharski
Comincerò con l'argomento dolente).
La questione che mi preoccupa di più è una sorta di universalità/astrazione per la memorizzazione dei parametri di rendering.
----
Come si capisce, tutti i controlli usano allo stesso modo il carattere, il colore dello sfondo e il colore del testo, ecc.
Quando tutti questi parametri sono uguali per tutti i controlli, allora l'interfaccia ha un aspetto comune con un unico concetto.
Ma come memorizzarli? perché i controlli non usano sempre tutti i parametri.
+ Il sistema è complicato dal fatto che gli elementi hanno diversi stati che dovrebbero usare i colori del carattere e dello sfondo in modo diverso. Sono Active, Disable, Over, o Select, ecc.
+ ci sono gruppi di controllori - rilievo (come Button) e campi di input (come Edit, List), e quando è lo sfondo per renderli
----
Nell'attuale idea di lavoro ho un elemento di attributo minimo di classe GAttribBase, che contiene 5 parametri di base (carattere/dimensione, colore di sfondo/bordo, dimensione del bordo)
Questi elementi di base sono utilizzati per formare un array per gli stati della classe GAttribut(Active/Disabvle/Over/Select, ecc.).
E poi GAttribut è popolato per i diversi tipi di elementi - Rilievo, modificabile, ecc.
Così, compiliamo i parametri di rendering una volta (li memorizziamo in xml), possono essere modificati per creare diversi design e li usiamo globalmente senza definirli per ogni controller.
Naturalmente, se qualche controllore ha bisogno di avere i propri parametri di rendering definiti - basta creare il proprio oggetto GAttributribut nel controllo e specificare i colori desiderati.
----
Questo modello funziona, il design unificato si ottiene in poco tempo, tutti i controlli prendono i colori dalla matrice comune.
Ma secondo me, non è universale. L'utente non capisce quali parametri della base GAttribBase sono usati per il rendering di questo o quel controllo.
Perché il codificatore sappia esattamente quale colore deve essere cambiato, dovrebbe guardare nella funzione di rendering del controllo. Il che è davvero fastidioso.
-----
Comunque, qualche idea per il codificatore per essere libero dalla gestione dei colori (per usare subito i colori predefiniti e non preoccuparsene all'inizio).
D'altra parte, se vuole ricolorare alcuni dei controlli sullo schermo, non deve indagare su quale GAttribBase è usato e in quale caso.
@Igor Volodin, @Combinator, @Anatoli Kazharski
In generale - che idee avete per il codificatore per essere libero dal lavoro sui colori da un lato (in modo che usi subito i colori posati e non si preoccupi di loro all'inizio)
E d'altra parte, se vogliono ricolorare alcuni dei controlli sullo schermo, possono farlo senza entrare nel labirinto delle funzioni di disegno e cercare quale GAttribBase è usato e in quale caso.
Ok, temi.
Per esempio, l'oggetto principale della nostra applicazione, chiamiamolo App, è associato all'oggetto ConcreteTheme.
Cos'è un oggetto a tema:
colori (sfondo, primo piano, disabilitato, attivo, ecc.), dimensioni di base, dimensioni dei caratteri per i casi standard: titlesize, commonsize, ecc. sprites per: pannelli, pulsanti, caselle di controllo, ecc.
Un nuovo tema è una nuova classe/struttura con valori cambiati. Ma è meglio che i temi possano essere ereditati sovrascrivendo solo certi parametri.
Il resto - la gerarchia dei controlli in cui ogni controllore usa uno dei valori necessari dell'oggetto-tema per default. Se ha bisogno di sovrascrivere questo, chiamiamo un metodo per lavorare con quella proprietà, specificando il nuovo valore.
Per esempio SetBgColor(XRGB(255,0,128));
CView - una classe di base che fornisce un'interazione di base basata sugli eventi
- CRect - coordinate
- Cpanel ha un bgcolor
- CButton ha un oggetto stato, ogni stato ha bg
- CText ha un colore del testo e proprietà del carattere
- CCircolo
E così via.
Se vuoi usare xml per descrivere gli elementi,
poi per ogni controllo o primitiva di classe dobbiamo creare una classe generatrice chiamiamola "build-container" che mapperà gli attributi (bgcolor="(255,0,128)") ai metodi corrispondenti ( SetBgColor(attrValue) ) della classe. Tali contenitori di build saranno analizzati dal parser XML, l'output sarà un oggetto inizializzato con i valori necessari, o con quelli predefiniti se non sono stati specificati valori.
Qui Theme è uguale al mio - un insieme di GAttributors per diversi tipi di controlli e i loro stati.
ma tu suggerisci già il primo passo sulla via della trasparenza per i coder - aggiungere funzioni a controlli specifici per cambiare le loro proprietà di rendering (SetBgColor ecc.)
Fondamentalmente sono d'accordo, sarà chiaro quali colori ha e cosa può essere cambiato.
una tale domanda allora - Theme implica una ridondanza di parametri inutilizzati?
Diciamo che nel mio GAttribBase di base per qualche controllo (per esempio il pulsante) usiamo solo il colore di sfondo e la dimensione, e altri parametri - spessore del bordo ecc. non sono usati in questo controllo.
Cioè - avete un elemento di base per tutti i controlli? dove è memorizzata l'informazione "per tutti i casi", o tutti i controlli hanno solo i loro parametri senza l'overhead dell'universalità?
...
In generale - quali sono alcune idee per il codificatore per essere libero dalla gestione dei colori (in modo che usi i colori di default e non si preoccupi di loro all'inizio)
E d'altra parte - in modo che se vuole ricolorare qualche controllore sullo schermo, non deve immergersi nel deserto delle funzioni di rendering e scoprire quale GAttribBase è usato e in quale caso.
Impostare i valori predefiniti per ogni voce. Se l'utente ha bisogno di cambiare qualcosa, per ogni proprietà dell'elemento dovrebbe esserci un metodo per impostare il nuovo valore. Questo è il modo in cui l'ho fatto ora.
Non ce l'ho ancora:
Ma tutto questo è il mio ragionamento sul mio schema. Non escludo che cambierà ancora molto quando inizierò la transizione. Quindi tutto quello che ho scritto sopra potrebbe non essere più rilevante per l'argomento in discussione qui. )