Sequenza di esecuzione di Init() e DeInit() - pagina 24

Nuovo commento
 
fxsaber:
L'esempio che hai rielaborato non era perfettamente adatto al problema in questione. Potete mostrare un altro esempio che non avrà una soluzione attraverso UninitializeReason.

Questo è tutto, chiudo questo dialogo. Che senso ha discutere dei modi di grattarsi l'orecchio? Se non c'è altra soluzione, potete usare il vostro codice, ma l'universalità non è sempre la soluzione ideale.

Per esempio, nessuno penserebbe di chiamare un taglialegna per tagliare 1 cespuglio di lamponi. Quindi il vostro codice è paragonabile ad una squadra di taglialegna per tagliare un cespuglio di lamponi.

Saluti Alexei.

 
Non capisco, se il vecchio DeInit e il nuovo OnInit sono eseguiti in thread diversi, qual è il problema con OnInit che aspetta solo che DeInit si verifichi e finisca. Usare una variabile globale come semaforo.
 
Aleksei Radchenko:
Non capisco, se il vecchio DeInit e il nuovo OnInit sono eseguiti in thread diversi, qual è il problema con OnInit che aspetta solo che DeInit si verifichi e finisca. Usare una variabile globale come semaforo.
Su un singolo grafico tutti gli indicatori girano solo su un thread.
 
Alexey Viktorov:

Che senso ha usare un esempio primitivo a due bit?

Usate invece un esempio di codice quasi corretto.

Alexey, questo esempio è stato creato in modo che anche un perdente possa capirlo. Per questo ho scritto che è primitivo. Spiacente, non è stato progettato per i voti alti.

Stamattina ho visto un cagnolino che abbaiava ai camion di passaggio. Lei manda il suo amore.

 
Nikolai Semko:

Alexei, questo esempio è stato creato in modo che anche chi non è all'altezza possa capirlo. Per questo ho scritto che era primitivo. Spiacente, non è stato progettato per i voti alti.

Stamattina ho visto un cane che abbaiava ai camion di passaggio. Lei manda il suo amore.

Stavi abbaiando con lei?

Cosa si può capire dall'esempio in cui non c'è un controllo della presenza dell'oggetto prima della sua creazione? Reclami contro gli sviluppatori che non hanno reso possibile scrivere in alcun modo, con errori grossolani? Scriverò come voglio e gli sviluppatori devono fornirmi tutte le condizioni per farlo. Gli sviluppatori devono prevedere tutti i possibili errori che potrei fare in futuro. È così? Non risucchiare il problema da dove non esiste.

 
Alexey Viktorov:

Cosa si può capire dall'esempio in cui non c'è un controllo di un oggetto prima della sua creazione? Reclami contro gli sviluppatori che non hanno reso possibile scrivere come si vuole, con errori grossolani?


Alexey, sembra che tu sia completamente fuori dal giro. Leggete le fonti primarie, per favore.
Ecco una citazione:"Se un oggetto è stato creato in precedenza, viene fatto un tentativo di cambiare le sue coordinate. "

Capisco che è una buona forma nelle grandi opere mettere controlli di vario tipo. Ma in questo caso questo controllo non ha senso. Perché se non c'è un oggetto, ObjectCreate lo creerà, e se c'è, cambierà semplicemente le sue coordinate. In questo esempio molto primitivo, l'obiettivo era quello di mostrare il fatto di cancellare un oggetto per Deunit del vecchio TF, cosa che dimostra perfettamente.
Il tuo "botta e risposta" non riguarda nulla. Molto probabilmente è solo un tentativo di attirare l'attenzione su di sé.
E se volete linee di codice superflue, prive di qualsiasi senso, per allenare le vostre dita, vi consiglio un'eccellente risorsa "Keyboard Solo".

 
Alexey Viktorov:

Ti sei buttato con lei?

Cosa potete capire dall'esempio in cui non c'è un controllo di un oggetto prima della sua creazione? Reclami contro gli sviluppatori che non hanno reso possibile scrivere quello che si vuole con errori grossolani? Scriverò come voglio e gli sviluppatori devono fornirmi tutte le condizioni per farlo. Gli sviluppatori devono prevedere tutti i possibili errori che potrei fare in futuro. È così? Non risucchiare il problema da dove non esiste.


Cosa c'è di così terribile nel cercare di creare un oggetto esistente? Sparirà?
 
Dmitry Fedoseev:

Cosa c'è di così terribile che succederebbe se provassimo a creare un oggetto esistente? Sparirà?

Dimitri mi sembri un programmatore istruito. Non ti hanno insegnato le regole dell'etichetta nella programmazione?

Per il resto si può scrivere come nel vecchio mql4 con la possibilità di overrun dell'array e altre ipotesi. Si ottiene un errore in risposta... Beh, segnalalo... andiamo avanti, non abbiamo tempo... E poi ci imbattiamo in un problema che non vale un accidente in un linguaggio più rigoroso e cominciamo a lamentarci con gli sviluppatori...

Cristo è risorto.

 
Nikolai Semko:


... Lo scopo di questo esempio molto primitivo era di mostrare il fatto che Deunit ha rimosso l'oggetto della vecchia TF, cosa che dimostra perfettamente.

Il fatto del fallimento è mostrato nel controesempio. Non devi succhiare il problema da dove non esiste. Mettete un controllo sul motivo della deinizializzazione e l'oggetto non viene cancellato, cambia solo le sue coordinate.
 
Alexey Viktorov:
Il fatto del fallimento è mostrato nell'esempio di risposta. Non è necessario aspirare il problema da dove non è presente. Si controlla il motivo della deinizializzazione e l'oggetto non viene cancellato, cambia solo le sue coordinate.
//Часть твоего кода:
void OnDeinit(const int reason)
  {
   if(UninitializeReason() != REASON_CHARTCHANGE)      // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред! 
                                                       // И зачем здесь использовать функцию UninitializeReason(), когда можно уже существует переменная  reason?
    {
     ObjectDelete(0,"InitDeinit");
     ChartRedraw(0);                                   // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так. 
     Print(__FUNCTION__, "  InitDeinit удалён");       // А где ж твоя любимая проверка, вдруг не удален.
    }
  }

Il mio esempio è stato creato per mostrare il problema di una sequenza ambigua dell'unità della nuova TF e dell'unità della vecchia TF, non come soluzione.

Hai solo aggirato il problema, non l'hai risolto.
Nel mio esempio, è solo importante che nell'unità della vecchia TF l'oggetto sia cancellato in ogni caso, anche quando la TF è cambiata, e nell'unità del nuovo oggetto sia creato di nuovo.

Se la sequenza è prima Deunit della vecchia TF, poi Unit della nuova TF, come dovrebbe essere logicamente. Poi l'oggetto viene cancellato e poi creato di nuovo.

Se la sequenza è prima l'Unità della nuova TF e poi la Deunità della vecchia TF, allora l'oggetto viene semplicemente modificato quando si cerca di crearlo nell'Unità, perché non è ancora cancellato. E poi viene cancellato dalla Deunit del vecchio TF. Questo è il bug.

Questo era lo scopo di questo esempio - mostrare cosa può incontrare qualsiasi programmatore che non ha letto questo ramo e non è a conoscenza di questa "caratteristica".
Questo esempio non voleva essere una soluzione. Le varianti della soluzione sono presentate qui e qui. Penso che aggiungerò anche una soluzione più tardi, ma senza usare variabili globali e file del terminale e perché questa soluzione funzioni anche se diversi indicatori identici sono impostati in una finestra. Avete provato a risolvere questo problema? Oppure siete capaci solo di trovare errori nel codice degli altri, soprattutto quando non ci sono.

Non essere più stupido!

1...171819202122232425262728
Nuovo commento
Motivazione: