Вопросы по Мастеру MQL5 и стандартной библиотеке торговых классов - страница 11
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Три вопроса:
Теоретически, можно конечно же собрать советник с помощью мастера, а потом влезть в код и вручную все это хозяйство прикрутить. Но желательно чтобы это все было реализовано в виде стандартных методов, т.е. для чайников, которые захотят воспользоваться мастером, чтобы им не пришлось лезть в код и править, например, в случае если он захотел заменить один сигнальный модуль на другой.
Вы сами отвечаете на все свои вопросы: "... собрать советник с помощью мастера, а потом ... вручную ...". Других вариантов пока нет. Мастер, скорее всего, в ближайшее время развиваться не будет.
Жаль, что такое хорошее начинание и заброшено в дальний угол.
Если бы довести его до ума, то очень многое можно было бы сделать, т.е. не разбрасываться по мелочам, а программистам создавать готовые модули, из которых чайники и друге пользователи могли, не лазая по кодам, собирать различные готовые советники. А так получается та же самая бодяга, что и на алгоритмическом mql4, т.е. бери алгоритм, лезь в код и вручную прикручивай. Принцип OOП опять нарушается. Например, если захотел заменить один модуль на другой, то придется опять лезть в код и заново все вручную все менять. Не мастер получается, а ерунда, т.к. одно только ползание по кодам, с целью хотя бы разобраться, где и что нужно модифицировать, убьет уйму времени.
Хорошее было начинание. Жаль. Вчера только создал сигнальный модуль, а как с его помощью заставить всего советника работать, чтобы не соваться каждый раз в коды, теперь ума не приложу. Хотел статью написать, как им пользоваться, по типу вставил, добавил управление позициями, управление капиталом и риском и все работает. Ан нет, работать не будет. Т.к. если пользователь и соберет советника с помощью мастера, то ничего не заработает. Ему нужно еще целую портянку инструкций написать, куда лезть в код и что менять. Не говоря о том, что мне еще самому нужно со всем этим разобраться прежде, чем инструкцию писать.
Так что пользователям ничего теперь не остается, как учить mql5, OpenCL и проч. чтобы заниматься автотрейдингом. А иначе им удачи не видать.
Ладно, раз этот проект заброшен, то буду думать теперь в другом направлении.
Жаль, что такое хорошее начинание и заброшено в дальний угол.
Будем надеяться не заброшен, а отложен. У самого много интересных мыслей по развитию Мастера. Но...
Надежда умирает последней (с) Народная поговорка
На первый вопрос, т.е. как тестировать сигнальный модуль по ценам открытия, а торговать по тикам, я нашел решение, чтобы не пришлось лазить в коды, причем даже лучше, чем общепринятое.
А вот как считывать показания сигнального модуля в модулях сопровождения позиций и управления капиталом и риском, без ковыряния кодов, допетрить пока не удается. Полазил по исходникам, поразбирался. Свои результаты сигнальный модуль выдает через метод direction(), т.е. каким-то образом достаточно лишь обратиться к экземпляру класса этого самого модуля в модулях сопровождении позиций и управлении капиталом и риском и вызвать этот самый метод, чтобы считать его показания. Как это можно сделать, не меняя кодов, пока не ясно.
Надежда умирает последней (с) Народная поговорка
На первый вопрос, т.е. как тестировать сигнальный модуль по ценам открытия, а торговать по тикам, я нашел решение, чтобы не пришлось лазить в коды, причем даже лучше, чем общепринятое.
А вот как считывать показания сигнального модуля в модулях сопровождения позиций и управления капиталом и риском, без ковыряния кодов, допетрить пока не удается. Полазил по исходникам, поразбирался. Свои результаты сигнальный модуль выдает через метод direction(), т.е. каким-то образом достаточно лишь обратиться к экземпляру класса этого самого модуля в модулях сопровождении позиций и управлении капиталом и риском и вызвать этот самый метод, чтобы считать его показания. Как это можно сделать, не меняя кодов, пока не ясно.
Не меняя кодов наверное ничего не получится.
Не меняя кодов наверное ничего не получится.
Еще не все потеряно. Ведь можно будет создать унаследованные классы от СExpert, СExpertMoney и СExpertTrailing, а в них добавить необходимые методы доступа к экземпляру класса сигнального модуля. Но тут тоже трабла имеет место, т.к. мастер прописывает в создаваемом советнике #include <Expert\Expert.mqh>, а не его потомка.
Надо еще подумать.
Если бы разработчики сразу догадались, что один сигнальный модуль можно использовать для всех остальных модулей, как основной, а также в случае необходимости добавлять дополнительные сигналы (как в данной реализации мастера) в модули сопровождения позиций и управления капиталом и риском, и предусмотрели это в кодах, то все было бы намного проще. А так получается, что у каждого модуля нужно прописывать дополнительные условия для сигналов, соответственно для них нужны дополнительные внешние настройки, в результате чего получается эдакий монстр с кучей оптимизируемых параметров. Не говоря про то, что сигналы из одного модуля могут конфликтовать, т.е. сигнальный может открыть позицию, а модуль сопровождения ее закрыть на следующем же тике, если условия входа в рынок и выхода из рынка будут взаимопротиворечивые.
Еще не все потеряно. Ведь можно будет создать унаследованные классы от СExpert, СExpertMoney и СExpertTrailing, а в них добавить необходимые методы доступа к экземпляру класса сигнального модуля. Но тут тоже трабла имеет место, т.к. мастер прописывает в создаваемом советнике #include <Expert\Expert.mqh>, а не его потомка.
Надо еще подумать.
Если бы разработчики сразу догадались, что один сигнальный модуль можно использовать для всех остальных модулей, как основной, а также в случае необходимости добавлять дополнительные сигналы (как в данной реализации мастера) в модули сопровождения позиций и управления капиталом и риском, и предусмотрели это в кодах, то все было бы намного проще. А так получается, что у каждого модуля нужно прописывать дополнительные условия для сигналов, соответственно для них нужны дополнительные внешние настройки, в результате чего получается эдакий монстр с кучей оптимизируемых параметров. Не говоря про то, что сигналы из одного модуля могут конфликтовать, т.е. сигнальный может открыть позицию, а модуль сопровождения ее закрыть на следующем же тике, если условия входа в рынок и выхода из рынка будут взаимопротиворечивые.
Всё так и задумывалось. Мастер создаёт "рыбу" советника. Дальше:
Всё так и задумывалось. Мастер создаёт "рыбу" советника. Дальше:
В том и безобразие, что изначально не были продуманы такие вещи, как:
Хотели как лучше. Получилось как всегда (с) Черномырдин
В общем то, значительную часть недоразумений можно пофиксить, но делать это необходимо на уровне корневых родительских классов, после чего распространить исправленные классы через апдейты платформы. Т.е. нужно открыть доступ к методу Direction() сигнального модуля из модулей сопровождения позиций и управления капиталом и риском. Потому что если отдельным разработчикам модулей править исходники родительских классов, то получится несовместимость исходников и созданные модули будут нерабочими на других компьютерах. Если разработчики модулей создадут родительские классы с переопределенными методами, то несовместимость все равно будет на уровне мастера, т.к. последний прописывает свои инклюды, а следовательно опять нужно конечным пользователям писать инструкции, а те вряд ли захотят лезть в исходники, а если и залезут, то ошибка в одном единственном символе или еще где и т.д. и т.п..
В том и безобразие, что изначально не были продуманы такие вещи, как:
Хотели как лучше. Получилось как всегда (с) Черномырдин
В общем то, значительную часть недоразумений можно пофиксить, но делать это желательно на уровне корневых родительских классов, после чего распространить исправленные классы через апдейты. Потому что если править исходники родительских классы разработчикам модулей, то получится несовместимость исходников и созданные модули будут нерабочими на других компьютерах. Если разработчик создаст родительские классы с переопределенными методами, то несовместимость уже на уровне мастера, т.к. он прописывает свои инклюды, а следовательно опять нужно конечным пользователям писать инструкции, а те вряд ли захотят лезть в исходники, а если и залезут, то ошибка в одном единственном символе или еще где и т.д. и т.п..
Давайте конкретные предложения. Будем рассматривать.
Пока только одно единственное, которое позволяет устранить вышеуказанные недостатки:
Открыть доступ к чтению значений возвращаемых методом Direction() сигнального модуля из модулей сопровождения позиций и управления капиталом и риском.
Т.е. в модулях сопровождения позициями и управления капиталом и риском добавить еще один метод, например с идентификатором double getMainSingnal(), который обращается к экземпляру класса модуля сигналов и возвращает в качестве результата, результат метода Direction() сигнального модуля. Поскольку такой обмен информацией происходит в режиме "только чтение", то безопасность никоим образом не будет нарушена.
Для этого нужно
P.S. Поле в котором хранится ссылка на экземпляр класса модуля сигналов есть в классе CExpert
CExpertSignal *m_signal; // trading signals objectТ.е. необходимо создать аналогичные поля для классов CExpertMoney и CExpertTrailing и передать им во время инициализации тоже самое значение из вышеуказанного поля в том же самом классе CExpert