GUI in crowdsourcing. Open beta testing. - pagina 29
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
Beh, c'era un mezzo esempio. È chiaro che c'è qualche file come pezzo di una funzione di lavoro. Dove viene generato l'interruttore (pulsanti) e abbiamo la possibilità di scrivere reazioni alla pressione dei pulsanti.
Sì, questo è un mezzo esempio. Non è riuscito ad arrivare alla fine a causa di quel bug con le posizioni.
Err quali altre funzioni selezionare... non c'è bisogno di fare nessuno di questi. Genera un file in cui, come ho capito, i pulsanti validi sono assegnati all'interruttore.Tutto qui. Fermata completa. Da qui sta a tutti chiamare le loro reazioni a questo pulsante. Per esempio per salvare che è stato premuto o qualcosa del genere. L'ambiente per il feedback di premere penso che inutile.
Err, quali altre caratteristiche scegliere... Non c'è bisogno di nulla di tutto ciò. Genera un file in cui, a quanto ho capito, si assegnano pulsanti validi all'interruttore. Questo è tutto. Fermata completa. Da qui sta a tutti chiamare le loro reazioni a questo pulsante. Per esempio per salvare che è stato premuto o qualcosa del genere. L'ambiente per il feedback di pressatura penso non sia necessario.
È meglio lavorare sul design
Err, quali altre caratteristiche scegliere... Non c'è bisogno di nulla di tutto ciò. Genera un file in cui, a quanto ho capito, si assegnano pulsanti validi all'interruttore. Questo è tutto. Fermata completa. Da qui sta a tutti chiamare le loro reazioni a questo pulsante. Per esempio per salvare che è stato premuto o qualcosa del genere. L'ambiente per il feedback del clic penso che non sia necessario.
E qui è meglio implementare l'ambiente attraverso le classi. Chiamando anche il menu delle schede, ecc. ecc.
Err, quali altre caratteristiche scegliere... Non c'è bisogno di nulla di tutto ciò. Genera un file in cui, a quanto ho capito, si assegnano pulsanti validi all'interruttore. Questo è tutto. Fermata completa. Da qui sta a tutti chiamare le loro reazioni a questo pulsante. Per esempio per salvare che è stato premuto o qualcosa del genere. Penso che l'ambiente per il feedback non sia necessario.
E l'ambiente dovrebbe essere implementato attraverso le classi. Anche le chiamate al menu delle schede e così via.
Non sventoliamo l'espressione "abbiamo bisogno di classi" davanti al naso di Peter. Aspettiamo almeno il video, poi faremo delle domande.
Ho già suggerito a Peter di modificare il suo "kernel" con una variante molto semplice: usare strutture. Al diavolo queste lezioni, se una persona non vuole immergersi in esse - sono affari suoi.
Ma usare le strutture renderebbe semplicemente la vita più facile a Peter stesso.
Come appare ora il "core", ovvero l'array globale: un array multidimensionale, beh, almeno bidimensionale. La seconda dimensione contiene le proprietà di un certo tipo di controllo per indici. Si può accedere alle proprietà anche per nome, poiché gli indici sono sostituiti da definizioni e si ottiene uno "pseudo-riferimento" per nome. In effetti, tutto è costruito sulle definizioni, come quel "linguaggio di markup" nel codice di Peter.
Ho già suggerito a Peter di implementare una struttura, così l'array globale potrebbe essere reso unidimensionale e le proprietà potrebbero essere richiamate direttamente per nome. Anche l'edificio "centrale" sarebbe semplificato, perché basterebbe aggiungere nuovi oggetti di scena alla struttura originale e riferirsi ulteriormente ad essi per nome. E il codice stesso potrebbe essere accorciato eliminando l'elenco delle numerose definizioni e dei metodi per utilizzarle.
Da un lato non è una classe, ma dall'altro renderebbe la gestione dell'array globale molto più facile per Peter. Inoltre, Peter ha già una certa esperienza nel lavorare con una struttura simile: un sindacato.
Ma Peter ha il suo modo di fare il sensei e noi aspetteremo solo il risultato...
Proporrei il seguente schema come esempio trasversale: Creare un modulo con tre campi: importo del trade, prezzo SL e prezzo TP, due pulsanti: COMPRA e VENDI
Creare Expert Advisor, collegare la GUI come inluder. Aggiungere una variabile per l'offerta iniziale. Quando viene inizializzato, l'importo iniziale dell'offerta viene passato al campo appropriato nella GUI.
Creare nella funzione Expert Advisor "Open Deal". Questa funzione dovrebbe essere chiamata non appena uno dei pulsanti della GUI viene cliccato.
Nella funzione stessa "scopriamo" quale comando è stato dato e chiediamo anche alla GUI quale tasso è impostato ora e sulla base di questi dati apriamo l'affare corrispondente.
Proporrei il seguente schema come esempio trasversale: Creare un modulo con tre campi: importo del trade, prezzo SL e prezzo TP, due pulsanti: COMPRA e VENDI
Creare Expert Advisor, collegare la GUI come inluder. Aggiungere una variabile per l'offerta iniziale. Quando viene inizializzato, l'importo iniziale dell'offerta viene passato al campo appropriato nella GUI.
Creare nella funzione Expert Advisor "Open Deal". Questa funzione dovrebbe essere chiamata non appena uno dei pulsanti della GUI viene cliccato.
Nella funzione stessa "scopriamo" quale comando è stato dato e chiediamo anche alla GUI quale tasso è impostato ora e sulla base di questi dati apriamo l'affare corrispondente.
Non lo capisci.
Perché, questo è anche implementabile attraverso una funzione che viene chiamata quando il campo è riempito e il valore di input è del tipo template... tutto. Anche lasciare che sia come stringa.... ancora non ci sarà il riempimento ad alta velocità del campo