Пожелания к MQL5 - страница 28

 

возможно это уже говорили....

1) добавить возможность компиляции когда с шифрованием и с возможностью генерации серийного номера с привязкой к ID компьютера (аналог пакер armandillo),

все это должно выполняться на уровне внутренних возможностей транслятора а не исходника

2) добавить возможность интерактивной работы с внешними программами что бы можно было управлять работой терминала из других программ, подключить/отключить к серверу, проверить связь с сервером, запросить архив котировок, выставить ордер... и тп

3) возможность выставления ордеров не зависимо от поступающих тиков

4) поддержка одновременной работы с несколькими ДЦ/счетами

5) вернуть отладку DLL

6) добавить хотябы поддержку структур, а вообще желательно расширить возможности что бы они были более близки к c++

 

Необходимо добавить возможность исполняемого перехода на хэлп, кот. несёт программа (например, открыть окно с нужным текстом) и на вебстраницу.

Сделал юзер что-то невразумительное - программка ему и говорит: вот тебе консультация по ситуации, почитай как правильно и больше глупости не делай.

 

СК,

надо в окне ордера ТП и СЛ не только в абсолютных величинах, но и в относительных, причем с автоподстановкой последнего значения. например, ставишь один раз ТП=2 и СЛ=10 а дальше только бай или селл, то есть пипсуешь себе на здоровье. это будет очень удобно. а то из-за этого неудобства я недавно сварганил советника специально, чтоб он ТП и СЛ с заданными значеними ставил после того как я нажму на бай или селл.

 

Столько нажелали всего!  Уже 28 страниц!

Хотелось бы от разработчиков услышать, какие пожелания уже в разработке, какие не будут реализованы никогда, а какие может быть будут.

А то непонятно, стоит ли желать чего-то еще, не видно обратной связи. 

Конечно, и по срокам хотелось узнать. Понимаю, что прогнозировать сроки запуска ПО иногда не проще, чем прогнозировать движение валютных курсов.

Ну хотя бы в таком виде: "Бета-версия МТ5 выйдет не ранее чем в .............".  Такую фразу можно написать?   

 
Better:

А то непонятно, стоит ли желать чего-то еще, ни видно обратной связи.


Ну, факт закрепления темы говорит о том, что разработчики считают её полезной :)
 
А про переприсвоение Magic в активном ордере уже было? Идея проста : при мультипериодной торговле можно будет передавать ордер на старший таймфрэйм при длительном тренде.
 
Cronex:
А про переприсвоение Magic в активном ордере уже было? Идея проста : при мультипериодной торговле можно будет передавать ордер на старший таймфрэйм при длительном тренде.
Можно немного подробней? Что имеется ввиду?
 
SK. писал (а):
Cronex:
А про переприсвоение Magic в активном ордере уже было? Идея проста : при мультипериодной торговле можно будет передавать ордер на старший таймфрэйм при длительном тренде.
Можно немного подробней? Что имеется ввиду?

Ну если кратко: у меня применяется единая стратегия торговли для 4 периодов, т.е. принципы входа /выхода / трала по одному алгоритму (набору индикаторов и типу сигналов), но параметры индикаторов для каждого периода естественно разные (фактически это 4 советника на одном графике), разделение по Magic . Что в итоге получается: на младших периодах есть все признаки закрытия позиций намного раньше чем этого действительно заслуживает ситуация на рынке (т.е. любой чих не в ту сторону выливается недобором профита), хотя на более старших таймфрэймах ситуация очень стабильная. Сказывается относительность волантильности на индикаторы. В чем идея наверно уже понятно, при устойчивых стуациях на старших таймфрэймах открытые позиции на младших не закрывать, а сменой Magic передавать их на логику старшего таймфрэйма. Да собственно применение не только для таймфрэймов, а для передачи в другую логику обработки. Мне кажется особой проблемы для ДЦ не будет т.к. тикет остается, а пользы можно накопать.
 
Cronex:
Ну если кратко: у меня применяется единая стратегия торговли для 4 периодов, т.е. принципы входа /выхода / трала по одному алгоритму (набору индикаторов и типу сигналов), но параметры индикаторов для каждого периода естественно разные (фактически это 4 советника на одном графике), разделение по Magic . Что в итоге получается: на младших периодах есть все признаки закрытия позиций намного раньше чем этого действительно заслуживает ситуация на рынке (т.е. любой чих не в ту сторону выливается недобором профита), хотя на более старших таймфрэймах ситуация очень стабильная. Сказывается относительность волантильности на индикаторы. В чем идея наверно уже понятно, при устойчивых стуациях на старших таймфрэймах открытые позиции на младших не закрывать, а сменой Magic передавать их на логику старшего таймфрэйма. Да собственно применение не только для таймфрэймов, а для передачи в другую логику обработки. Мне кажется особой проблемы для ДЦ не будет т.к. тикет остается, а пользы можно накопать.


Cмысл понятен.

Но думаю, что ради такой идеи вносить изменения в язык и технологию общения терминала с сервером нет нужды. Ведь всё необходимое можно учесть в программе на стороне терминала. Более того, сама идея менять маджик красноричиво свидетельствует о недоработке стратегии, её критериев. Маджик (как ясно и из Вашего примера) не несёт и не может нести в принципе некий незыблемый критерий, по которому ордер надо закр. или откр. Нетрудно понять, что стратегия не может и не должна базироваться на маджике (быть привязана к ордеру). Просто потому, что маджик никак не связан с рынком.

На мой взгляд, это - один из ключевых моментов в торговле. Просто в языке оказался маджик, попался под руку, и мы - давай к нему привязываться.. На самом деле ситуацию надо рассматривать на каждом новом тике как новую, как не имеющую никакой предыстории (истории событий по игровому счёту, в том числе, времени и цены открытия рыночных ордеров).

А маджик - это, хотя и отчасти полезный, но по-моему, не очень удобный механизм для учёта .. неизвестно чего. На мой взгляд, если бы ордер можно было бы однозначно идентифицировать (при переоткрытии и частичном закрытии), то маджик и вовсе потерял бы смысл.

 
SK. писал (а):


Cмысл понятен.....

Попробую привести некоторые аргументы, начну с конца...

По моему мнению, если принять ордер за объект, то маджик на данный момент с точки зрения программирования полноправное переменное свойство этого объекта как и уровень SL или TP. Возможно я ошибаюсь, но в MQL однозначно идентифицировать ордер по отношению к коду исполняемому в терминале на всех его возможных стадиях жизни (при переоткрытии и частичном закрытии) на данный момент не представляется возможным и маджик в большей степени компенсирует эту ситуацию. Маджик и не должен быть привязан к рынку - у него просто другая область применения и никакой смысловой нагрузки кроме своего значения не несет.

В позиции по рассмотрению ситуации на рынке как безисторической, позволю с Вами не согласиться... Но это мое собственное мнение. При профитном ордере все же есть смысл посмотреть на старший таймфрэйм для принятия решения либо пересидеть небольшой откат и продолжить работу с ордером на старшем таймфрэйме или просто закрыть его за бесперспективность.

Про состоятельность и недоработку стратегии дисскутировать и не собираюсь - полностью согласен... Но над этим как раз и работаю :-)

Менять язык и протокол обмена между сервером и терминалом, ну не знаю ... На данный момент присвоение значения маджика уже есть и принимается сервером при выставлении ордера. Я не владею информацией о формате протокола обмена, но есть подозрение что это пакетная передача некой структуры данных по транспорту с последующей верификацией консистентности. Добавить еще один необязательный параметр в структуру данных передаваемой OrderModify я думаю не представляет особого труда. Я глубоко сомневаюсь что разработчики пошли по пути атомарного протокола обмена и тем самым загнали себя в тяжелый процесс поддержки версионности.

Ну а в общем я просто спросил о планах :-) Нет так нет.

Причина обращения: