Galleria di interfacce utente scritte in MQL - pagina 24

Nuovo commento
 
hini #:
Come si fa a sbarazzarsi di più di cinquemila avvisi generati in fase di compilazione, molti dei quali in file di linguaggio di markup?
Non si può. È tecnicamente inevitabile perché scriviamo codice di markup nell'array di stringhe. Questo tipo di dati è convenzionalmente adatto a scrivere qualsiasi valore e parola.

Alla fine, non importa, perché il costruttore è perfettamente in grado di distinguere tra parole chiave, nomi e valori numerici.

Questo approccio non comporta alcuna perdita di dati.
 
In teoria si potrebbe scrivere (int) o (double) prima di ogni valore numerico, ma lascio la scelta all'utente.
 
Dobbiamo "pestare la gola" al compilatore, ma alla fine vinciamo). Non è un grosso problema.


Per la cronaca. Rispetto le regole di programmazione e gli avvertimenti del compilatore, ma in questo caso non ho trovato una soluzione migliore. Mi rendo conto che ad alcuni non piacerà questo approccio, ma si è rivelato il più ottimale. E innocuo.
 
Spero davvero che domani sarà in grado di postare un aggiornamento e coloro che vogliono finalmente iniziare a creare la propria interfaccia. Farò del mio meglio.
 
Реter Konow avvertenze del compilatore, ma in questo caso non sono riuscito a trovare una soluzione migliore. Mi rendo conto che ad alcuni non piacerà questo approccio, ma si è rivelato il più ottimale. E innocuo.
Una piccola storia:

Quando si è posto il problema di dove scrivere il codice di markup, mi sono trovato di fronte a due opzioni principali: in un array di stringhe o in un file. Dopo aver soppesato i pro e i contro che mi sono venuti in mente, ho deciso che un array è molto meglio per una serie di motivi. In primo luogo, l'inizializzazione e l'elaborazione immediata del contenuto dell'array da parte del codice costruttore. In secondo luogo, l'accesso fulmineo ai singoli attributi e proprietà dei controlli da parte del costruttore/motore per la lettura/sovrascrittura, se necessario (con un file sarebbe un problema enorme). In terzo luogo, è molto più semplice inviare un array a una risorsa tramite un evento OnChartEvent() personalizzato. Ecco perché abbiamo scelto un array. E gli avvertimenti... beh, cosa si può fare. Bisogna sempre sacrificare qualcosa per raggiungere l'obiettivo.

 
Correzione al testo precedente: l'inoltro non avviene per risorsa, ma per fette di stringhe composte.
 
Beh, e la ragione totale che metterà il chiodo finale nel "coperchio della bara" dell'idea che il markup possa essere scritto in un file di testo:

Un file .txt non può essere compilato per assicurarsi che non ci siano errori grossolani. Ciò significa che se l'utente sbaglia qualcosa con virgole, virgolette, spazi e così via, non lo saprà dal compilatore.

Solo dopo aver fallito nella costruzione dell'interfaccia si renderà conto di aver digitato male il codice e andrà a cercare ogni minimo errore di battitura. Se ne manca anche solo uno, la procedura deve essere ripetuta.

Questo è un prezzo follemente alto per l'assenza di avvisi del compilatore.

Ecco perché in MQL la variante con array di stringhe per il codice di markup non ha alternative e non può essere utilizzata. E le avvertenze del compilatore dovrebbero essere prese come un dato di fatto.
 
P.S. Il compilatore avverte anche quando una parola chiave è scritta male. A volte intellisense aiuta. In un file .txt, se si sbaglia a scrivere le parole chiave, non lo si sa. Quindi non c'è alcun vantaggio pratico di un file rispetto a un array.

Spero di aver spiegato in modo dettagliato perché non si dovrebbero eliminare gli avvisi del compilatore in questo caso particolare.

Buona giornata a tutti.

 
Реter Konow gli avvertimenti del compilatore non dovrebbero essere rimossi in questo caso particolare.

Ciao a tutti.

Ok, capito.
 
Questa parte del codice è al centro del costruttore
1...171819202122232425262728293031...71
Nuovo commento