Errori, bug, domande - pagina 1118

Nuovo commento
 
Zeleniy:
Ho capito, ho avuto il file di installazione per più di un mese, ora ne ho scaricato uno nuovo e funziona, non pensavo che il file di installazione stesse cambiando perché sta scaricando i file giusti dopo.
Al contrario... se il vecchio non visualizzava la tabella perché avrebbe dovuto iniziare a visualizzarla... questo è strano...
 
micle:
al contrario... quello vecchio, se non visualizzava la targa, perché avrebbe dovuto iniziare a visualizzarla... questo è strano...
Non lo so, ma quello nuovo si è comportato come al solito senza alcuna compressa e ha iniziato a scaricare i file di installazione.
 
Zeleniy:
Non lo so, ma quello nuovo si è comportato come al solito senza alcun segno e ha iniziato a scaricare i file di installazione.
mistica...
 
Zeleniy:
Non lo so, ma quello nuovo si è comportato come al solito senza schede e ha iniziato a scaricare i file di installazione.

Ho già visto che la comparsa di una tale finestra durante il processo di installazione potrebbe essere legata alla protezione del computer (apparentemente, a causa di qualche aggiornamento regolare) e la successiva manifestazione peculiare come questa.

Non importa se era un file di installazione precedente o appena scaricato.

Ora prendo nota, per il futuro, nel caso, di questa nuova dipendenza per me (non sto sperimentando ora).

Ma sono contento che il tuo problema sia risolto.

Come suggerimento: per quanto mi ricordi, c'è stato un aggiornamento del terminale MT5 di recente. Forse in questo caso c'è qualche connessione tra il prompt del proxy, la versione non aggiornata del file di installazione e il processo di installazione online.
 

Dalla lista delle modifiche alla nuova build di MT5 del 2014.04.04 10:14:"3. Terminale: risolto un bug che causava il mancato disegno di oggetti grafici sul grafico in alcune condizioni. "Non so se gli sviluppatori hanno soddisfatto la mia richiesta in SD #966979 o se questo è un altro tipo di correzione, o anche un effetto collaterale di qualche miglioramento nella prossima build, ma in ogni caso ora mi va bene così. La lista dei cambiamenti dice che era un bug, ma nella corrispondenza con la SD mi è stato detto inequivocabilmente:"Non è un bug, è una limitazione per risparmiare risorse."

Ora puoi guardare comodamente le build di TA su qualsiasi TF come prima.

Grazie, chiudo la domanda.

 

La costanza del metodo può essere sovrascritta in una classe derivata (build 917)

class A {
public:
        virtual void f() const {}
        int x;
};
class B : public A {
public:
        virtual void f() /*не const*/ { x = 2; }
};
void g( const A* a ) { a.f(); }
void OnStart()
{
        A *a = new B();
        a.x = 1;
	Print( a.x ); //результат = 1
        g( a );
        Print( a.x ); //результат = 2, а обещали, что g( const A* ) не может менять объект
        delete( a );
}

Un altro esempio

class A {
public:
        virtual void f() const { Print( "1" ); }
};
class B : public A {
public:
        virtual void f()       { Print( "2" ); }
};
void g( const A* a ) { a.f(); }
void OnStart()
{
        A *a = new B();
        g( a );
        delete( a );
}

Risultato= 2, ma in C++ risultato = 1

L'errore non sta nel fatto che in una classe derivata non si può dichiarare un metodo con lo stesso nome della classe base (che è ammissibile), ma che il C++ li considera diversi e MQL considera che B::f() sovrascrive A::f() const

 

La funzione Print() emette i non-numeri del segnale float come non-segnali, il che è illogico, perché double li emette entrambi normalmente.

Float deve: 1) rimuovere il prefisso Q dai numeri non di segnale e quindi i numeri di segnale e non di segnale saranno stampati in modo identico, oppure 2) emettere i numeri di segnale con il prefisso S. Se mi sbaglio, vi prego di darmi un esempio di segnale float non numerico che verrebbe stampato dalla funzione Print() senza prefisso Q

Per esempio, prendo un segnale doppio non numerico, lo converto in float e lo emetto entrambi tramite Print(). Nel primo caso stampa SNAN, nel secondo QNAN

 

Durante il processo di ricerca delle modalità di scrittura dei dati nel file dal tester, ecco un errore (abbreviato, perché non ci stava bene):

2014.04.08 01:47:30.531 2013.07.01 02:10:00   00: 0x000000013FD1F038
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F04D 498 BCD            mov        rcx, r13
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F04A 41 B001            mov        r8b, 0x1
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F043 80 BD3804000000    cmp        byte [rbp+0x438], 0x0
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F040 83 C202            add        edx, 0x2
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F03D 418 BD4            mov        edx, r12d
2014.04.08 01:47:30.531 2013.07.01 02:10:00   
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F03B EB03              jmp        0x13fd1f040
2014.04.08 01:47:30.531 2013.07.01 02:10:00      crash -->  000000013 FD1F038 8 B50FC            mov        edx, [rax-0x4]
2014.04.08 01:47:30.531 2013.07.01 02:10:00   
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1F033 4885 C0            test       rax, rax
[cut]
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1EE6E 55                push       rbp
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1EE67 4 C894018          mov        [rax+0x18], r8
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1EE63 48895808          mov        [rax+0x8], rbx
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013 FD1EE60 488 BC4            mov        rax, rsp
2014.04.08 01:47:30.531 2013.07.01 02:10:00   Access violation at 0x000000013FD1F038 read to 0x00000003FFFFFFFF

Cioè, naturalmente, capisco che questo errore è un risultato naturale della mia goffaggine. E in ogni caso è stato rapidamente risolto (il problema era nel tentativo di passare dati non stringa in FileWrite tramite una terza funzione, se necessario - posso descriverlo in modo più dettagliato). Ma l'errore non sembra molto chiaro e un po' spaventoso :) e il compilatore non suggerisce da nessuna parte che è previsto. Forse dovremmo almeno aggiungere qualche tipo di deformazione o qualcosa del genere...

 
Lone_Irbis:

Durante il processo di ricerca delle modalità di scrittura dei dati nel file dal tester, ecco un errore (abbreviato, perché non ci stava bene):

Cioè, naturalmente, capisco che questo errore è un risultato naturale della mia goffaggine. E in ogni caso è stato rapidamente risolto (il problema era nel tentativo di passare dati non stringa in FileWrite tramite una terza funzione, se necessario - posso descriverlo in modo più dettagliato). Ma l'errore non sembra molto chiaro e un po' spaventoso :) e il compilatore non suggerisce da nessuna parte che è previsto. Forse dovremmo almeno aggiungere qualche tipo di deformazione o qualcosa del genere...

Sì, per favore descrivilo in modo più dettagliato.

Interessato a build, OS, bit rate, impostazioni del tester. Si prega di allegare il codice per la riproduzione.

Grazie.

 

OK, ci proverò. Sono stato in grado di tornare al momento giusto e riprodurlo, ma non posso isolare il bug e riprodurlo separatamente...

Build: MetaTester 5 x64 build 910 (07 Mar 2014) https://dl.dropboxusercontent.com/u/61587787/bugreport/build.png

Win7 x64 desktop https://dl.dropboxusercontent.com/u/61587787/bugreport/system.png

copiato dalla finestra del tester: https://dl.dropboxusercontent.com/u/61587787/bugreport/log.txt

screenshot dal tester (beh, non si sa mai):https://dl.dropboxusercontent.com/u/61587787/bugreport/tester1.pnghttps://dl.dropboxusercontent.com/u/61587787/bugreport/tester2.png

impostazioni del tester (non so se mi spiego):https://dl.dropboxusercontent.com/u/61587787/bugreport/config.png

Frammento di codice:

   int idx = 133;
   WriteCSV("test.csv",idx);
   
class Core { 
public:  
   void     WriteCSV(string FileName, string s1, string s2, string s3, string s4, string s5, string s6);
};

void Core::WriteCSV(string FileName, string s1, string s2="", string s3="", string s4="", string s5="", string s6=""){
   int handle = FileOpen(FileName,FILE_CSV|FILE_WRITE|FILE_SHARE_WRITE|FILE_UNICODE|FILE_COMMON,"~");
   if(handle == INVALID_HANDLE) Print("error");
   else FileWrite(handle,s1,s2,s3,s4,s5,s6);
   FileClose(handle);
}

Se si sostituisce conWriteCSV("test.csv",(string)idx); - l'errore scompare. Le altre variabili non stringhe non fanno nulla qui. Non sembra fare differenza a cosa corrisponda idx, però (è solo il numero di serie della notizia nell'array). Riprodotto su qualsiasi notizia quando si cerca di salvare il risultato. Degli avvertimenti, solo laconversione implicita da 'numero' a 'stringa' è mostrata, ma di nuovo, solo in questo caso si trasforma in un crash.

Non voglio davvero postare il codice completo e il .set qui, ma potrei inviarlo da qualche parte.

1...111111121113111411151116111711181119112011211122112311241125...3184
Nuovo commento