Auguri per MQL5 - pagina 29

 
Cronex:

Nella posizione di vedere la situazione del mercato come istrionica, mi permetto di dissentire con voi... Ma questa è la mia opinione personale. Nel caso di un ordine redditizio ha senso guardare il timeframe superiore per decidere se aspettare un piccolo pullback e continuare a lavorare con l'ordine a un timeframe superiore o semplicemente chiuderlo per mancanza di successo.

Non sto dicendo che non dovreste considerare la storia del mercato. Infatti è l'unica cosa che può e deve essere presa in considerazione.

Sto dicendo che non ha senso (dannoso) prendere in considerazione la data e il prezzo di apertura di un ordine. In questo senso majik è un mezzo per mantenere le illusioni :) Non voglio ripetermi, date un'occhiata qui.

E sul filo, non credo che majic vada bene. Immaginate quanti programmatori sventurati ci sono. In alcuni programmi, una richiesta di majik entrerà sicuramente in un ciclo e sovraccaricherà il server. E se anche uno solo di questi programmi entra in circolazione, sarà la fine dell'intera tecnologia.

 
SK. писал (а):

E sul filo, non credo che ci sarà alcun majic. Immaginate quanti programmatori miserabili ci sono. In alcuni programmi, una richiesta di majik entrerà sicuramente in un ciclo e caricherà il server. Se anche uno solo di questi programmi entra in circolazione, l'intera tecnologia sarà rovinata.

Credo di essermi sbagliato: non stavo suggerendo di richiederlo separatamente dal server. Ho suggerito di sovrascriverlo solo quando OrderModify viene chiamato.



 
SK. писал (а): Immaginate quanti programmatori fuorviati ci sono. In alcuni programmi, una richiesta di CAMBIARE un majik è destinata a entrare in un ciclo e a caricare il server.

Capisco cosa vuoi dire: il pericolo esiste. Proprio come con il riordino di SL e TP.

 
Cronex:
SK. ha scritto (a): immagina quanti programmatori sventurati ci sono. In alcuni programmi, una richiesta di CAMBIARE un majik è destinata a entrare in un ciclo e a caricare il server.

Capisco cosa vuoi dire: il pericolo esiste. Proprio come con il cambio di SL e TP


Questo è già un dettaglio di quello che non faranno senza di noi:) Ma se lo fosse, anche la richiesta o la risposta sarebbe presunta - come la vedete voi. Per esempio, un cambiamento sul server SL da un PC connesso all'account risponderebbe visualizzando il nuovo valore SL su tutti i PC connessi all'account.

Io e te siamo come Dobczynski e Bobczynski:

Bobchinsky. ... "Eh!" dico a Peter Ivanovich...
Dobczynski. No, Pyotr Ivanovich, ho detto: "э!"
Bobchinsky. Prima l'hai detto tu e poi l'ho detto io. "Э! - Peter Ivanovich e ho detto. - "E perché dovrebbe sedersi qui, quando la strada per lui
alla provincia di Saratov?"

 
SK. писал (а):


Già... Tutto ciò che l'utente può fare per mettere in ginocchio il sistema, lo farà. Anche senza rinsavire :-)

Sfortunatamente, come conseguenza, molti prodotti sono sovraccarichi di controlli e ricontrolli, protezione dell'interfaccia contro "sciocchezze" e azioni accidentali e imprevedibili dell'utente.

Recentemente ho dovuto comunicare con un cliente che ha interpretato lo stato "Approvato" di un documento ufficiale in modo un po' particolare. Il documento è in un certo senso approvato e firmato, ma tutto quello che c'è dentro può essere cambiato senza ulteriori ripensamenti e riapprovazioni. Immaginate come esempio: voi inviate un ordine di pagamento alla banca, la banca lo esegue fedelmente, e voi poi, dopo aver corretto il documento originale, venite in banca e fate una retata con la dicitura "errata esecuzione dell'ordine di pagamento".

 
Cronex:

Sfortunatamente, come conseguenza di ciò, molti prodotti sono sovraccarichi di funzionalità di controllo e ricontrollo, protezione dell'interfaccia da "sciocchi" e azioni accidentali imprevedibili dell'utente.

Sì, ne sono ben consapevole. Per questo motivo ho dovuto spendere molto tempo per rendere il programma a prova di errore, quindi il lavoro si è già protratto per mezzo anno. E tutto perché l'utente può cambiare il colore o l'aspetto dell'icona di controllo e poi lamentarsi.

A proposito, sull'argomento di questo thread. C'è bisogno di proprietà degli oggetti regolabili programmaticamente : proibire/consentire cambiamenti di colore, dimensione, carattere, evidenziazione, cancellazione, ecc.

 
Vi ricordo che è possibile eseguire il terminale senza interfaccia grafica.
Per esempio lo stesso campionato, chiaramente un esperto ben funzionante non ha bisogno di un'interfaccia grafica.
 

Una grande richiesta per rendere possibile l'esecuzione di un EA (indicatore, script), non solo all'arrivo di un nuovo tick, ma in diversi modi

Ho bisogno di

  1. Per zecca
  2. Per tempo
  3. Per evento esterno, importante per il collegamento ai calcoli di altre matrici.

Forse come questo inizio di 3 funzioni

Start 0 {} // lavora per tick

Start 1 {} // lavora per tempo (seleziona ogni secondo, minuto, ora, ecc.)

Start 2 {} // viene eseguito su un evento esterno, ad esempio quando un programma esterno ha completato i calcoli e i dati sono stati aggiornati nel file dei risultati di calcolo di quel programma.

Grazie in anticipo.

 

Può anche essere utile poter organizzare gli indicatori degli utenti per gruppi in cartelle sul file system. Non è una buona idea avere un mucchio di indicatori in una cartella :-)

 

Sarebbe anche bello poter impostare una scala di prezzo fissa (pip/pixel) con i limiti della scala che cambiano automaticamente per multipli di un dato valore, ad esempio 5 o 10 pip.