Ошибки, баги, вопросы - страница 1702
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ок, а как корректно перевести double в int с сохранением знака (число не важно, если уходит за пределы то ограничить пределом int)
Ответили и сразу закрыли
Мне нужно было иметь возможность удалить себя (индикатор) на тот случай, если запущена хоть одна копия, пусть и с другими входными параметрами. Для этого требовалось выяснить handle самого себя. К сожалению, на тот момент еще не знал, что это невозможно в MQL в 100% случаев. Поэтому решил пойти на не очень хитрый прием.
Перебираю все хэндлы. И смотрю, последнее значение первого буфера через CopyBuffer, если оно совпадает с тем рэндомом, что я записал в своем индикаторе перед проверкой, то это автоматом обозначает, что хэндл принадлежит мне и я могу себя удалять, если понадобится.
Именно из этих соображений был написан столь безобидный код, который вызвал такую неоднозначную, но, очевидно, негативную реакцию разработчиков. Видите ли, так делать нельзя. Что незаконного сделал-то? Ну прочел значение своего буфера через CopyBuffer. Это незаконно?!
Нет ничего подобного на "так делать нельзя" в ответе разработчиков. Нигде не сказано, что это "незаконно".
Если вы считаете, что этот "безобидный код" вам безусловно необходим - используйте его. Только добавьте IndicatorRelease(handle)) в OnCalculate() после чтения буфера. Вы же не имеете необходимость на каждом тике проверять что это "ваш" индикатор?
Вот так индикатор решает вашу задачу и перестает быть "невидимкой":
Пусть сообщество будет в курсе, что вот таким образом возможно создать фоновое никак не контролируемое исполнение любого кода даже на терминале без чартов. Вот такой лайфхак. А считать это багом или нет - вопрос терминологии, видимо. Понимаю так, что архитектурно изменить здесь разработчики что-либо не в состоянии. Поэтому такой гнев. По другому объяснить такую реакцию себе не могу.
Нет "гнева" в ответе сервисдеска. Есть непонимание вашей мотивации регулярно преувеличивать проблемы с которыми вы сталкиваетесь.
Разработчики в состоянии изменить. Но обычно очень осторожно относятся к предложениям "отнять и запретить" даже недокументированное поведение, если оно не является однозначно вредным. Данный "хак" довольно специфичен, но возможно кто-то им пользуется.
Возможно еще будут правки в терминале по этому поводу, но это уж точно не гигантская проблема и приоритет у этого вопроса минимальный.
Никто все равно не выскажется. Такую граблю хорошо бы в Справке отразить.
Оказывается вы прекрасно понимаете, что этот "серьезный баг" терминала интересен только вам одному.
На этом данный вопрос закроем. Технические подробности все обсудили, а эмоции в этой ветке лишние.
Нет ничего подобного на "так делать нельзя" в ответе разработчиков. Нигде не сказано, что это "незаконно".
Если вы считаете, что этот "безобидный код" вам безусловно необходим - используйте его. Только добавьте IndicatorRelease(handle)) в OnCalculate() после чтения буфера. Вы же не имеете необходимость на каждом тике проверять что это "ваш" индикатор?
Нет, конечно, такой необходимости нет.
Вот так индикатор решает вашу задачу и перестает быть "невидимкой":
На эту тему недавно получил ответ от Вашего коллеги
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
Slawa, 2016.09.07 17:17
fxsaber:
IndicatorRelease после iCustom делать надо?
Зачем?
Не надо. После IndicatorCreate тоже не надо делать
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Ошибки, баги, вопросы
fxsaber, 2016.09.07 17:27
После - не значит сразу. Но если не надо, то когда надо?Нет "гнева" в ответе сервисдеска. Есть непонимание вашей мотивации регулярно преувеличивать проблемы с которыми вы сталкиваетесь.
Мотивация сугубо эгоистическая. Хочу, чтобы все работало предсказуемо, согласно документации. Баги достали, вот и результат
Разработчики в состоянии изменить. Но обычно очень осторожно относятся к предложениям "отнять и запретить" даже недокументированное поведение, если оно не является однозначно вредным. Данный "хак" довольно специфичен, но возможно кто-то им пользуется.
Возможно еще будут правки в терминале по этому поводу, но это уж точно не гигантская проблема и приоритет у этого вопроса минимальный.
Согласен насчет приоритета.
Оказывается вы прекрасно понимаете, что этот "серьезный баг" терминала интересен только вам одному.
На этом данный вопрос закроем. Технические подробности все обсудили, а эмоции в этой ветке лишние.
Так мне не надо, я пытаюсь проделать большую работу что бы в будущем облегчить себе жизнь.
Я победил свою проблему так в родителе все протектед и наследование идет под протектед далее переопределение.
Только теперь уже неясно, что вы хотели изначально.
Похоже, просто избавиться от недоступных методов во всплывающем списке.
Похоже, просто избавиться от недоступных методов во всплывающем списке.
Не только, я для себя переписал классы графических обьектов и из одного класса в котором описаны все свойства обьектов я теперь легко и понятно (во всяком случае для меня) делаю наследники типа Button при этом создавая такой класс я вижу свойства только кнопки, и не вижу свойств TextLabel ..
Далее из этих простых элементов я уже могу конструировать более сложные с минимальной вероятностью ошибки и максимально быстро и понятно (во всяком случае для меня) .
Возможно Вы начнете дружно пинать меня и говорить что в стандартной библе все есть, сразу скажу не все и это все не понятно. Я привык работать с тем что понимаю полностью, а что бы понимать как это все работает это все самому нужно перебрать..
Так недоступные и так не появляются, разве нет?
Нет, появляются.
В студии, кстати, то же самое.
Нет, появляются.