Galleria di interfacce utente scritte in MQL - pagina 80

Nuovo commento
 
Aleksey Vyazmikin #:

Non si tratta di critiche, ma della gioia di raggiungere un risultato tangibile.

Da questo punto di vista, sono d'accordo, ma in assenza di richieste, questa gioia scompare immediatamente e rimane il vuoto. Quindi ora mi trovo nella stessa situazione di chi scrive consulenze senza garantire il risultato. Nella stessa barca, per così dire.
 
Реter Konow #:
Per lo sviluppatore, naturalmente. Tuttavia, guardando all'esperienza degli autori degli articoli e delle librerie GUI, non si può fare a meno di notare una certa difficoltà di divulgazione che hanno dovuto affrontare. Per qualche ragione a me non del tutto chiara, questo argomento non cattura l'attenzione del grande pubblico. Forse perché la percentuale di sviluppatori forti non è alta, ma è anche probabile che la complessità di grandi librerie e articoli spaventi qualcuno. Siamo sinceri: l'OOP non è una semplice astrazione e quando si frappone, la motivazione di una persona viene messa alla prova.

Il mio linguaggio di markup è ovviamente molto più semplice del concetto di OOP, ma richiede anche una presentazione suddivisa in parti e protratta per mesi. In termini di divulgazione, questo è un approccio molto inefficiente. Ecco perché sono giunto alla conclusione che il linguaggio di markup ripeterà quasi inevitabilmente il destino delle librerie grafiche.

Al contrario, un editor visuale all'interno della piattaforma di trading è un modo nuovo. Non è mai stato fatto prima. C'è quindi la speranza che abbia un destino diverso.



Al giorno d'oggi la maggior parte delle interfacce avanzate sono sviluppate in modo programmatico e danno ottimi risultati, inoltre la scrittura di una libreria richiede molto meno tempo rispetto allo sviluppo di un editor grafico completo, la cosa principale è solo creare un'interfaccia software comoda e facile da usare.

 
Kuzma Shevelev #:



Al giorno d'oggi la maggior parte delle interfacce avanzate sono sviluppate in modo programmatico e danno ottimi risultati, inoltre la scrittura di una libreria richiede molto meno tempo rispetto allo sviluppo di un editor grafico completo, la cosa principale è solo creare un'interfaccia software comoda e facile da usare.

Non ho intenzione di discutere, è solo un'opinione.

Nell'evoluzione dello sviluppo di GUI, le librerie di classi o di funzioni occupano il primo gradino dei tre esistenti: libreria grafica, linguaggio di markup e editor visuale.

La libreria permette allo sviluppatore di creare controlli nel modo più dispendioso in termini di tempo, ma vale la pena notare che consente la massima libertà creativa (pensata solo per sviluppatori MOLTO esperti).

Il linguaggio di markup è l'anello intermedio di questa catena. Combina convenienza e facilità con un'ampia gamma di funzionalità. Tuttavia, eredita dalle librerie uno dei loro principali svantaggi: la necessità di compilare completamente il programma per verificare ogni minima modifica. Se cambiate il colore di un elemento, compilatelo, se volete controllare qualcosa, ricompilatelo. Cambiato il carattere? - ricompilare. Spostate la posizione? Avete scritto un testo diverso? - ricompilare, ricompilare, ricompilare.

Tuttavia, il linguaggio di markup è indispensabile quando si creano grandi gruppi di elementi multipli e si impostano in massa le proprietà. Rende questo processo molto comodo. Molto più facile che in una libreria. Inoltre, la sintassi ridotta, l'intuitività e le regole non complicate garantiscono una comprensione molto più rapida rispetto alle librerie.

L'editor visuale è il livello più alto. Combina tutti i vantaggi del linguaggio di markup, ma li eleva a un nuovo livello, che è fuori dalla portata delle librerie. Quando si lavora nell'editor, tutte le modifiche sono visibili immediatamente. Non è necessaria la ricompilazione. Non è inferiore, ma supera il linguaggio di markup in termini di capacità. Il top.

E obiettivamente, non manca molto a questa vetta... rispetto alla distanza percorsa finora.

 
Anche se non uso alcun grafico nei miei EA, e gli EA danno risultati finanziari molto tangibili, seguo l'argomento con interesse e auguro all'autore di avere successo dal profondo del cuore!
 
JRandomTrader #:
Anche se non uso alcun grafico nei miei EA, e gli EA danno risultati finanziari molto tangibili, seguo l'argomento con interesse e auguro all'autore di avere successo dal profondo del cuore!
Grazie mille!


 
Un altro aggiornamento sullo stato di sviluppo è previsto per il 31 dicembre.
 

Stato di sviluppo: buono.

Negli ultimi quindici giorni è stato fatto molto lavoro seguendo un piano prestabilito. L'enfasi sull'implementazione delle funzionalità di modifica manuale all'interno della finestra dell'editor grafico ha dato i suoi frutti. I meccanismi di editing precedenti delle vecchie versioni dell'editor sono stati ripristinati e aggiornati. Tuttavia, c'è ancora molto lavoro da fare. Entro il 7 gennaio intendo presentare il lavoro completo di tutti i principali meccanismi di editing necessari per l'editor grafico. È quasi pronto.

P.S. Molti gadget funzioneranno molto meglio nel prossimo futuro.

P.S.S. Buon anno!




 

Buon anno Peter. Grazie ancora per tutto il tuo duro lavoro.
Attendo con ansia il tuo prossimo aggiornamento/presentazione.

 
Douglas Prager #:

Buon anno, Peter. Grazie ancora per tutto il tuo duro lavoro.
Attendo con ansia il tuo prossimo aggiornamento/presentazione.

Grazie, Douglas. Buon anno!
 
Реter Konow #:
Da questo punto di vista, sono d'accordo, ma in assenza di domanda, questa gioia scompare immediatamente e rimane il vuoto. Quindi ora mi trovo nella stessa situazione di chi scrive consulenze senza garantire il risultato. Nella stessa barca, per così dire.
Ti capisco. La realtà colpisce duramente.
1...7374757677787980818283
Nuovo commento