Seqüência de execução Init() e DeInit() - página 24

Novo comentário
 
fxsaber:
O exemplo que você retrabalhou não era perfeitamente adequado para o problema em questão. Você pode mostrar outro exemplo que não terá uma solução através da UninitializeReason.

É isso aí, vou encerrar este diálogo. Qual é o objetivo de discutir maneiras de coçar seu ouvido? Se não houver outra solução, você pode usar seu código, mas a universalidade nem sempre é a solução ideal.

Por exemplo, para cortar um arbusto de framboesa, ninguém pensaria em chamar uma equipe de madeireiros. Portanto, seu código é comparável ao de uma equipe de lenhadores para cortar um arbusto de framboesa.

Cumprimentos a Alexei.

 
Não entendo, se o velho DeInit e o novo OnInit são executados em fios diferentes, qual é o problema com o OnInit apenas esperando que o DeInit ocorra e termine. Use uma variável global como semáforo.
 
Aleksei Radchenko:
Não entendo, se o velho DeInit e o novo OnInit são executados em fios diferentes, qual é o problema com o OnInit apenas esperando que o DeInit ocorra e termine. Use uma variável global como semáforo.
Em um único gráfico, todos os indicadores funcionam apenas em uma linha.
 
Alexey Viktorov:

Para que serve o uso de um exemplo primitivo de um bipartido?

Use um exemplo de código quase correto em seu lugar.

Alexey, este exemplo foi criado para que até mesmo um perdedor pudesse entendê-lo. É por isso que escrevi que é primitivo. Desculpe, não foi projetado para os "A's" retos.

Vi um pequeno cão latindo em caminhões que passavam esta manhã. Ela envia seu amor.

 
Nikolai Semko:

Alexei, este exemplo foi criado para que até mesmo os fracassados pudessem entendê-lo. É por isso que escrevi que era primitivo. Desculpe, não foi projetado para os "A's" retos.

Vi um cão latindo em caminhões que passavam esta manhã. Ela envia seu amor.

Você estava latindo com ela?

O que pode ser entendido a partir do exemplo onde não há verificação da presença de objetos antes de sua criação? Reclamações contra os desenvolvedores de que eles não tornaram possível escrever de forma alguma, com erros grosseiros? Escreverei da maneira que eu quiser e os desenvolvedores devem me fornecer todas as condições para isso. Os desenvolvedores têm que prever todos os possíveis erros que eu possa cometer no futuro. É isso? Não chupe o problema para fora de onde ele não existe.

 
Alexey Viktorov:

O que pode ser entendido a partir do exemplo onde não há verificação de um objeto antes de ele ser criado? Reclamações contra os desenvolvedores de que eles não tornaram possível escrever como eles gostariam, com erros grosseiros?


Alexey, você parece estar completamente fora do circuito. Leia as fontes primárias, por favor.
Aqui está uma citação:"Se um objeto já foi criado antes, é feita uma tentativa de alterar suas coordenadas. "

Entendo que em grandes obras é de boa forma colocar cheques de vários tipos. Mas neste caso, este cheque não tem sentido. Porque se não houver nenhum objeto, o ObjectCreate o criará, e se houver, ele simplesmente mudará suas coordenadas. Neste exemplo muito primitivo, o objetivo era mostrar o fato de que a eliminação de um objeto por Deunit da antiga TF, o que demonstra perfeitamente.
Seu "atropelamento e fuga" não tem nada a ver. Muito provavelmente, apenas uma tentativa de chamar a atenção para si mesmo.
E se você quiser linhas supérfluas de código, desprovidas de qualquer sentido, para treinar seus dedos, recomendo um excelente recurso "Teclado Solo".

 
Alexey Viktorov:

Você estava pulando com ela?

O que você pode entender do exemplo onde não há cheque para um objeto antes de ele ser criado? Reclama contra os desenvolvedores que eles não tornaram possível escrever o que você quiser com erros grosseiros? Escreverei da maneira que eu quiser e os desenvolvedores devem me fornecer todas as condições para isso. Os desenvolvedores têm que prever todos os possíveis erros que eu possa cometer no futuro. É isso? Não chupe o problema para fora de onde ele não existe.


O que há de tão terrível em tentar criar um objeto existente? Será que vai desaparecer?
 
Dmitry Fedoseev:

O que é tão terrível que aconteceria se tentássemos criar um objeto existente? Será que vai desaparecer?

Dimitri, você me parece ser um programador educado. Você não foi ensinado as regras de etiqueta na programação?

Para o resto, você pode escrever como no antigo mql4 com a possibilidade de sobreposições de matriz e outras suposições. Você recebe um erro em resposta... Bom, sinalize-o de volta... Vamos em frente, não temos tempo... E então nos deparamos com um problema que não vale nada em uma linguagem mais estrita e começamos a reclamar com os desenvolvedores...

Cristo ressuscitou.

 
Nikolai Semko:


... O objetivo deste exemplo muito primitivo era mostrar o fato de que Deunit removeu o objeto da antiga TF, o que demonstra perfeitamente ... ...

O fato do fracasso é mostrado no contra-exemplo. Você não precisa sugar o problema para fora de onde ele não existe. Verifique o motivo da desinicialização e o objeto não é apagado, ele apenas muda suas coordenadas.
 
Alexey Viktorov:
O fato do fracasso é mostrado no exemplo de resposta. Não é necessário sugar o problema para fora de onde ele não está presente. Você verifica o motivo da desinicialização e o objeto não é excluído, ele apenas muda suas coordenadas.
//Часть твоего кода:
void OnDeinit(const int reason)
  {
   if(UninitializeReason() != REASON_CHARTCHANGE)      // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред! 
                                                       // И зачем здесь использовать функцию UninitializeReason(), когда можно уже существует переменная  reason?
    {
     ObjectDelete(0,"InitDeinit");
     ChartRedraw(0);                                   // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так. 
     Print(__FUNCTION__, "  InitDeinit удалён");       // А где ж твоя любимая проверка, вдруг не удален.
    }
  }

Meu exemplo foi criado para mostrar o problema de uma seqüência ambígua da Unidade da nova TF e da Unidade da antiga TF, não como uma solução.

Você simplesmente ignorou o problema, não o resolveu.
No meu exemplo, é apenas importante que na Unidade do antigo TF o objeto seja apagado em qualquer caso, inclusive quando o TF é modificado, e na Unidade do novo objeto seja criado novamente.

Se a seqüência é primeiro Deunit da antiga TF, então Unit da nova TF, como deveria ser logicamente. Em seguida, o objeto é apagado e depois criado novamente.

Se a seqüência é primeiro a Unidade do novo TF e depois a Unidade do antigo TF, então o objeto é simplesmente modificado quando se tenta criá-lo na Unidade, porque ainda não foi apagado. E depois é apagado pelo Deunit da antiga TF. Este é o bug.

Esse foi o objetivo deste exemplo - mostrar o que qualquer programador que não tenha lido este ramo e não esteja ciente desta "característica" pode encontrar.
Este exemplo não foi concebido para ser uma solução. Como as variantes da solução são apresentadas aqui e aqui. Acho que também acrescentarei uma solução mais tarde, mas sem utilizar variáveis e arquivos globais do terminal e para que esta solução funcione mesmo que vários indicadores idênticos sejam definidos em uma janela. Você já tentou resolver este problema? Ou você só é capaz de encontrar erros no código de outras pessoas, especialmente quando elas não estão lá.

Não seja mais estúpido!

1...171819202122232425262728
Novo comentário
Razão: