Durante l'ottimizzazione o il test non in modalità visiva, se ci sono avvisi o avvisi di eventi udibili nel codice - suonano tutti e le finestre di avviso si aprono. Forse è meglio ignorarli nel tester, tranne che per la modalità visiva?
artmedia70: Durante l'ottimizzazione o il test non in modalità visiva, se ci sono avvisi o avvisi di eventi udibili nel codice - suonano tutti e le finestre di avviso si aprono. È meglio ignorarli nel tester, tranne che per la modalità visiva?
Li inserisco nel codice e li aggiro da solo
void CreateOrSetLine(conststring NameObj,datetime Time1,double Price1,datetime Time2,double Price2,color cColor)
{
if(IsOptimization()==true)
return;
if(ObjectFind(NameObj)==-1)
{
ObjectCreate(NameObj,OBJ_TREND,0,Time1,Price1,Time2,Price2);
ObjectSet(NameObj,OBJPROP_RAY,false);
ObjectSet(NameObj,OBJPROP_BACK,false);
ObjectSet(NameObj,OBJPROP_COLOR,cColor);
}
...
... в т ч алерты
... и прочие сообщения - которые на оптимизации не нужны
и так получаю более быстродействующий код
Lo capisco. La domanda riguarda qualcos'altro. Quanto tempo ci vorrà per elaborare gli if con un uso intensivo della grafica e un'ottimizzazione seria. E si può semplicemente fare in modo che il tester ignori l'output di grafici, avvisi e suoni in una modalità non visiva.
artmedia70: Sì, è chiaro. La domanda è diversa. Quanto tempo ci vorrà per elaborare gli if in caso di uso intensivo della grafica e ottimizzazione seria. E si può semplicemente fare in modo che il tester ignori l'output di grafica, avvisi e suoni in una modalità non visiva.
Sono parzialmente d'accordo, ma se non c'è codice nel tester, si può gestire con una transizione condizionale e il problema non è così grande
In ogni caso si risparmierà la velocità di elaborazione
è solo che nella tua proposta il tester striscia comunque il codice e bypassa solo l'output grafico e sonoro, mentre nella mia variante l'output avviene immediatamente
del blocco di codice che non è necessario durante i test e io, come autore, so meglio cosa può essere saltato e cosa no
e questo approccio è notevolmente più veloce.
non è un fatto che il tester gestirà l'intero blocco di codice più velocemente che se si va direttamente al posto dove l'autore sa esattamente che ulteriore codice non è necessario per l'ottimizzazione
Sì, grazie, è stato risolto prontamente. Ma purtroppo c'è un nuovo comportamento incomprensibile di OBJ_EDIT. Cercherò di spiegare.
Ho due OBJ_EDIT , uno sopra l'altro. Dato che l'ordine di disegno non è stato ancora fissato, dobbiamo giocare con i nomi degli oggetti. Beh, ci siamo abituati.
Quello inferiore si chiama "1_abc" e quello superiore "abc". Al disegno iniziale tutto è corretto. Al ridisegno del programma (per esempio cambio di dimensioni) la parte superiore, "abc", scompare (va "sotto" quella inferiore). E se si clicca sul luogo dove era il suo campo viene evidenziato, anche se lui stesso non è visibile. Ho provato a dare altri nomi per cambiare l'ordine di disegno, ancora lo stesso comportamento... è apparso nell'ultima build 563, prima andava bene.
Consenti l'uso dei cookie per accedere al sito MQL5.com.
Abilita le impostazioni necessarie nel browser, altrimenti non sarà possibile accedere.
Hai effettuato l'accesso. L'autenticazione a due fattori è stata disattivata. Configurala di nuovo e scansiona un nuovo codice QR, oppure continua con l'autenticazione a due fattori disattivata.
Ciò che è stato fissato nel 560 non funziona nel 562. I pulsanti posti sopra OBJ_EDIT non funzionano più.
Prova la build 563, per favore.
Durante l'ottimizzazione o il test non in modalità visiva, se ci sono avvisi o avvisi di eventi udibili nel codice - suonano tutti e le finestre di avviso si aprono. È meglio ignorarli nel tester, tranne che per la modalità visiva?
Li inserisco nel codice e li aggiro da solo
nel codice e bypassare me stesso
Sì, è chiaro. La domanda è diversa. Quanto tempo ci vorrà per elaborare gli if in caso di uso intensivo della grafica e ottimizzazione seria. E si può semplicemente fare in modo che il tester ignori l'output di grafica, avvisi e suoni in una modalità non visiva.
In ogni caso si risparmierà la velocità di elaborazione
è solo che nella tua proposta il tester striscia comunque il codice e bypassa solo l'output grafico e sonoro, mentre nella mia variante l'output avviene immediatamente
del blocco di codice che non è necessario durante i test e io, come autore, so meglio cosa può essere saltato e cosa no
e questo approccio è notevolmente più veloce.
non è un fatto che il tester gestirà l'intero blocco di codice più velocemente che se si va direttamente al posto dove l'autore sa esattamente che ulteriore codice non è necessario per l'ottimizzazione
Prova la build 563 per favore.
La build 563 non funziona:
Lo stesso codice funziona bene in 5.
Come non è fissato? Ora gli oggetti sono disegnati in ordine strettamente cronologico e non in ordine alfabetico. Non è entrato nella costruzione?
Per favore, fornisci un esempio del tuo codice per illustrare il problema
La build 563 non funziona:
Lo stesso codice funziona bene nella build 5.
Sì, funziona.
controllare la grafica pura, forse è a causa di un bug del template