Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
возможно это уже говорили....
1) добавить возможность компиляции когда с шифрованием и с возможностью генерации серийного номера с привязкой к ID компьютера (аналог пакер armandillo),
все это должно выполняться на уровне внутренних возможностей транслятора а не исходника
2) добавить возможность интерактивной работы с внешними программами что бы можно было управлять работой терминала из других программ, подключить/отключить к серверу, проверить связь с сервером, запросить архив котировок, выставить ордер... и тп
3) возможность выставления ордеров не зависимо от поступающих тиков
4) поддержка одновременной работы с несколькими ДЦ/счетами
5) вернуть отладку DLL
6) добавить хотябы поддержку структур, а вообще желательно расширить возможности что бы они были более близки к c++
Необходимо добавить возможность исполняемого перехода на хэлп, кот. несёт программа (например, открыть окно с нужным текстом) и на вебстраницу.
Сделал юзер что-то невразумительное - программка ему и говорит: вот тебе консультация по ситуации, почитай как правильно и больше глупости не делай.
СК,
надо в окне ордера ТП и СЛ не только в абсолютных величинах, но и в относительных, причем с автоподстановкой последнего значения. например, ставишь один раз ТП=2 и СЛ=10 а дальше только бай или селл, то есть пипсуешь себе на здоровье. это будет очень удобно. а то из-за этого неудобства я недавно сварганил советника специально, чтоб он ТП и СЛ с заданными значеними ставил после того как я нажму на бай или селл.
Столько нажелали всего! Уже 28 страниц!
Хотелось бы от разработчиков услышать, какие пожелания уже в разработке, какие не будут реализованы никогда, а какие может быть будут.
А то непонятно, стоит ли желать чего-то еще, не видно обратной связи.
Конечно, и по срокам хотелось узнать. Понимаю, что прогнозировать сроки запуска ПО иногда не проще, чем прогнозировать движение валютных курсов.
Ну хотя бы в таком виде: "Бета-версия МТ5 выйдет не ранее чем в .............". Такую фразу можно написать?
А то непонятно, стоит ли желать чего-то еще, ни видно обратной связи.
А про переприсвоение Magic в активном ордере уже было? Идея проста : при мультипериодной торговле можно будет передавать ордер на старший таймфрэйм при длительном тренде.
А про переприсвоение Magic в активном ордере уже было? Идея проста : при мультипериодной торговле можно будет передавать ордер на старший таймфрэйм при длительном тренде.
Ну если кратко: у меня применяется единая стратегия торговли для 4 периодов, т.е. принципы входа /выхода / трала по одному алгоритму (набору индикаторов и типу сигналов), но параметры индикаторов для каждого периода естественно разные (фактически это 4 советника на одном графике), разделение по Magic . Что в итоге получается: на младших периодах есть все признаки закрытия позиций намного раньше чем этого действительно заслуживает ситуация на рынке (т.е. любой чих не в ту сторону выливается недобором профита), хотя на более старших таймфрэймах ситуация очень стабильная. Сказывается относительность волантильности на индикаторы. В чем идея наверно уже понятно, при устойчивых стуациях на старших таймфрэймах открытые позиции на младших не закрывать, а сменой Magic передавать их на логику старшего таймфрэйма. Да собственно применение не только для таймфрэймов, а для передачи в другую логику обработки. Мне кажется особой проблемы для ДЦ не будет т.к. тикет остается, а пользы можно накопать.
Ну если кратко: у меня применяется единая стратегия торговли для 4 периодов, т.е. принципы входа /выхода / трала по одному алгоритму (набору индикаторов и типу сигналов), но параметры индикаторов для каждого периода естественно разные (фактически это 4 советника на одном графике), разделение по Magic . Что в итоге получается: на младших периодах есть все признаки закрытия позиций намного раньше чем этого действительно заслуживает ситуация на рынке (т.е. любой чих не в ту сторону выливается недобором профита), хотя на более старших таймфрэймах ситуация очень стабильная. Сказывается относительность волантильности на индикаторы. В чем идея наверно уже понятно, при устойчивых стуациях на старших таймфрэймах открытые позиции на младших не закрывать, а сменой Magic передавать их на логику старшего таймфрэйма. Да собственно применение не только для таймфрэймов, а для передачи в другую логику обработки. Мне кажется особой проблемы для ДЦ не будет т.к. тикет остается, а пользы можно накопать.
Cмысл понятен.
Но думаю, что ради такой идеи вносить изменения в язык и технологию общения терминала с сервером нет нужды. Ведь всё необходимое можно учесть в программе на стороне терминала. Более того, сама идея менять маджик красноричиво свидетельствует о недоработке стратегии, её критериев. Маджик (как ясно и из Вашего примера) не несёт и не может нести в принципе некий незыблемый критерий, по которому ордер надо закр. или откр. Нетрудно понять, что стратегия не может и не должна базироваться на маджике (быть привязана к ордеру). Просто потому, что маджик никак не связан с рынком.
На мой взгляд, это - один из ключевых моментов в торговле. Просто в языке оказался маджик, попался под руку, и мы - давай к нему привязываться.. На самом деле ситуацию надо рассматривать на каждом новом тике как новую, как не имеющую никакой предыстории (истории событий по игровому счёту, в том числе, времени и цены открытия рыночных ордеров).
А маджик - это, хотя и отчасти полезный, но по-моему, не очень удобный механизм для учёта .. неизвестно чего. На мой взгляд, если бы ордер можно было бы однозначно идентифицировать (при переоткрытии и частичном закрытии), то маджик и вовсе потерял бы смысл.
Cмысл понятен.....
Попробую привести некоторые аргументы, начну с конца...
По моему мнению, если принять ордер за объект, то маджик на данный момент с точки зрения программирования полноправное переменное свойство этого объекта как и уровень SL или TP. Возможно я ошибаюсь, но в MQL однозначно идентифицировать ордер по отношению к коду исполняемому в терминале на всех его возможных стадиях жизни (при переоткрытии и частичном закрытии) на данный момент не представляется возможным и маджик в большей степени компенсирует эту ситуацию. Маджик и не должен быть привязан к рынку - у него просто другая область применения и никакой смысловой нагрузки кроме своего значения не несет.
В позиции по рассмотрению ситуации на рынке как безисторической, позволю с Вами не согласиться... Но это мое собственное мнение. При профитном ордере все же есть смысл посмотреть на старший таймфрэйм для принятия решения либо пересидеть небольшой откат и продолжить работу с ордером на старшем таймфрэйме или просто закрыть его за бесперспективность.
Про состоятельность и недоработку стратегии дисскутировать и не собираюсь - полностью согласен... Но над этим как раз и работаю :-)
Менять язык и протокол обмена между сервером и терминалом, ну не знаю ... На данный момент присвоение значения маджика уже есть и принимается сервером при выставлении ордера. Я не владею информацией о формате протокола обмена, но есть подозрение что это пакетная передача некой структуры данных по транспорту с последующей верификацией консистентности. Добавить еще один необязательный параметр в структуру данных передаваемой OrderModify я думаю не представляет особого труда. Я глубоко сомневаюсь что разработчики пошли по пути атомарного протокола обмена и тем самым загнали себя в тяжелый процесс поддержки версионности.
Ну а в общем я просто спросил о планах :-) Нет так нет.