Последовательность выполнение Init() и DeInit() - страница 24

Новый комментарий
 
fxsaber:
Пример, который Вы переделали, не идеально соответствовал обсуждаемой проблеме. Можно показать другой пример, который не будет иметь решения через UninitializeReason.

Всё, я прекращаю этот диалог. Какой смысл обсуждать способы чесания уха? Ну не будет другого решения можно будет попользоваться вашим кодом, но универсальность не всегда является идеальным решением проблемы.

К примеру, чтобы вырезать 1 куст малины никому и в голову не придёт вызывать бригаду лесорубов. Так вот ваш код сравним с бригадой лесорубов для вырезки одного куста малины.

С уважением Алексей.

 
Не пойму, если старый DeInit и новый OnInit выполняются в разных потоках, в чем проблема в OnInit просто подождать наступления и завершения DeInit. В качестве семафора использовать глобальную переменную.
 
Aleksei Radchenko:
Не пойму, если старый DeInit и новый OnInit выполняются в разных потоках, в чем проблема в OnInit просто подождать наступления и завершения DeInit. В качестве семафора использовать глобальную переменную.
На одном чарте все индикаторы работают только на один потоке.
 
Alexey Viktorov:

Какой смысл юзать примитивный пример двоечника?

Поюзай лучше пример ПОЧТИ правильного кода

Алексей, этот пример был создан так, чтобы понятно было даже двоечникам. Поэтому я и написал,  что он примитивный. Извините, на отличничков  не был расчитан.

Сегодня утром видет собачонку, лающую на проходящие грузовики. Она передала вам привет.

 
Nikolai Semko:

Алексей, этот пример был создан так, чтобы понятно было даже двоечникам. Поэтому я и написал,  что он примитивный. Извините, на отличничков  не был расчитан.

Сегодня утром видет собачонку, лающую на проходящие грузовики. Она передала вам привет.

А вы вместе с ней скакали?

Что можно понять из примера в котором нет проверки наличия объекта перед его созданием? Претензии к разработчикам что они не сделали возможность писать как попало, с грубейшими ошибками? Типа того, я буду писать как попало, а разработчики мне должны создать все условия для этого. Разработчики должны предусмотреть все возможные ошибки которые смогу сделать в будущем. Так что-ли??? Не надо высасывать проблему оттуда где её нет.

 
Alexey Viktorov:

Что можно понять из примера в котором нет проверки наличия объекта перед его созданием? Претензии к разработчикам что они не сделали возможность писать как попало, с грубейшими ошибками? 


По ходу, Алексей, Вы совсем не в теме. Читайте первоисточники, плиз. 
Цитирую: "Если объект был до этого создан, то производится попытка изменить его координаты."

Я понимаю, что хорошим тоном в больших работах является ставить проверки различного рода. Но в этом случае эта проверка лишина всякого смысла. Т.к. если объекта нет, ObjectCreate его создаст, а если есть, то просто изменит его координаты. В данном совсем примитивном примере преследовалась цель показа факта удаления объекта Деюнитом старого ТФ, что он и прекрасно демонстрирует.
Ваш "наезд" - ни о чем. Скорей всего просто попытка привлечь к себе внимание. 
А если вам хочется лишние строки кода, лишенные всякого смысла, дабы потренировать свои пальчики - рекомендую прекрасный ресурс "Соло на клавиатуре".

 
Alexey Viktorov:

А вы вместе с ней скакали?

Что можно понять из примера в котором нет проверки наличия объекта перед его созданием? Претензии к разработчикам что они не сделали возможность писать как попало, с грубейшими ошибками? Типа того, я буду писать как попало, а разработчики мне должны создать все условия для этого. Разработчики должны предусмотреть все возможные ошибки которые смогу сделать в будущем. Так что-ли??? Не надо высасывать проблему оттуда где её нет.


Что такого страшного случиться от попытки создания существующего объекта? Он исчезнет что ли?
 
Dmitry Fedoseev:

Что такого страшного случиться от попытки создания существующего объекта? Он исчезнет что ли?

Дмитрий вы, как мне кажется, образованный программист. Вас не учили правилам хорошего тона в программировании?

А в остальном можно писать и как в старом mql4 с возможностью выхода за пределы массива например и прочими допущениями. В ответ получили ошибку... ну и флаг ей взад... пойдём дальше, нам некогда... А потом нарываемся на проблему, которая и выеденного яйца не стоит, в более строгом языке и начинаем предъявлять претензии разработчикам...

Христос воскрес.

 
Nikolai Semko:


... В данном совсем примитивном примере преследовалась цель показа факта удаления объекта Деюнитом старого ТФ, что он и прекрасно демонстрирует. ...

Факт неудаления показан в ответном примере. Не надо высасывать проблему оттуда где её нет. Поставил проверку причины деинициализации и объект не удаляется, а просто меняет свои координаты.
 
Alexey Viktorov:
Факт неудаления показан в ответном примере. Не надо высасывать проблему оттуда где её нет. Поставил проверку причины деинициализации и объект не удаляется, а просто меняет свои координаты.
//Часть твоего кода:
void OnDeinit(const int reason)
  {
   if(UninitializeReason() != REASON_CHARTCHANGE)      // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред! 
                                                       // И зачем здесь использовать функцию UninitializeReason(), когда можно уже существует переменная reason?
    {
     ObjectDelete(0,"InitDeinit");
     ChartRedraw(0);                                   // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так. 
     Print(__FUNCTION__, "  InitDeinit удалён");       // А где ж твоя любимая проверка, вдруг не удален.
    }
  }

Мой пример создавался чтобы показать проблему неоднозначной последовательности выполнения Юнита нового ТФ и Деюнита старого ТФ, а не как ее решение.

Ты просто обошел проблему, а не решил ее. 
В моем примере как раз важно, чтобы в Деюните старого ТФ удалялся объект в любом случае, в том числе и при смене ТФ, а в Юните нового объекта он был создан вновь. 

Если последовательность сначала Деюнит старого ТФ, потом Юнит нового ТФ, как должно быть по логике. Тогда объкт удаляется а потом создается вновь.

Если же последовательность - сначала Юнит нового ТФ, потом Деюнит старого ТФ, тогда объкт при попытке его создать в Юните просто модифицируется, т.к. он еще не удален. А потом удаляется Деюнитом старого ТФ. В этом и есть баг.

В этом смысл был этого примера - показать то, с чем может столкнуться любой программист, не прочитавший данной ветки и не знающий данную "особенность". 
Этот пример не рассматривался, как какое-то решение. Как варианты решения представлены здесь и здесь. Думаю я тоже добавлю чуть позже решение, но без применения глобальных переменных терминала и файлов, а также чтобы данное решение работало , если даже в одном окне установлено несколько одинаковых индикаторов. А тебе слабо попробовать решить такую задачку? Или ты только и способен на поиски ошибок в чужом коде, особенно когда их там нет.

Не тупи больше!

1...171819202122232425262728
Новый комментарий