Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
редактировать : GVget условие != -1.0 к >= 0.0; редактировать
[...] занимает немного больше времени, чем я думал ...
Это все больше становится повторением (извините за каламбур) предыдущей темы, которую я уже упоминал: https://www.mql5.com/en/forum/120034. Все, что связано с глобальными переменными, поднимает вопросы о резервном копировании и аварийном восстановлении. Если торговля должна быть перенесена в спешке на новый сервер, то либо должна быть доступна свежая резервная копия gvariables.dat, либо пользователь должен быть в состоянии воссоздать глобальные переменные вручную.
Я не изучал ваш код внимательно, но я также не уверен, что произойдет, если существует несколько копий советника и MT4 будет перезапущен. Похоже, что код может предполагать, что советники будут автоматически перезагружены в том же порядке, в котором они были первоначально загружены вручную. Другими словами, несколько копий советника могут получить разные значения This_EA_qty при перезагрузке, и тогда я не могу понять, как они правильно определят свои исторические ордера в списке MT4. Но я могу ошибаться в этом.
занимает немного больше времени, чем я думал ...
редактировать : GVget условие != -1.0 к >= 0.0
// TimeCurrent() in seconds since 1970 would most probably exceed that
TimeCurrent() возвращает 32-битное целое число. Тип datatime является псевдонимом для типа int, int также является 32-битным целым числом.
Еще одна вещь, которую я не понимаю в вашем коде - почему вы используете разные MN для каждой открытой сделки? Это противоположно тому, для чего предназначены MN. Идея MN заключается в том, что вы можете идентифицировать все сделки определенного советника, просто взглянув на MN. В чем причина случайной части MN? Как бы выглядел код в вашем советнике, который закрывал бы все открытые сделки этого советника или отслеживал все стопы этого советника?
Вопрос о постоянстве все еще остается. Я не знаю, как это будет работать после перезапуска терминала или после переключения на совершенно другой терминал...
Это все больше становится повторением (извините за каламбур) предыдущей темы, которую я уже упоминал: https://www.mql5.com/en/forum/120034. Все, что связано с глобальными переменными, поднимает вопросы о резервном копировании и аварийном восстановлении. Если торговля должна быть перенесена в спешке на новый сервер, то либо должна быть доступна свежая резервная копия gvariables.dat, либо пользователь должен быть в состоянии воссоздать глобальные переменные вручную.
Я не изучал ваш код внимательно, но я также не уверен, что произойдет, если существует несколько копий советника и MT4 будет перезапущен. Похоже, что код может предполагать, что советники будут автоматически перезагружены в том же порядке, в котором они были первоначально загружены вручную. Другими словами, несколько копий советника могут получить разные значения This_EA_qty при перезагрузке, и тогда я не могу понять, как они правильно определят свои исторические ордера в списке MT4. Но я могу ошибаться.
Вот такие отзывы я ожидаю... спасибо gordon, 7bit & jjc...
Ваши ответы требуют некоторого размышления... но чтобы ответить быстро :
- если эксперт This_EA уже был прикреплен однажды на другом графике, magic_number тогда будет иметь значение : 101-1-time_stamp (тире для ясности).
- содержащаяся информация будет 101 - идентификатор эксперта; 1 - количество This_EA, действующее на данный момент; time_stamp - время отправки ордера.
- Затем мы можем просканировать его с помощью StringSubStr и узнать, что конкретный ордер был открыт This_EA, в то время как был прикреплен 1 другой This_EA.
TimeCurrent() возвращает 32-битное целое число. Тип datatime является псевдонимом для типа int, int также является 32-битным целым числом.
Другая вещь, которую я не понимаю в вашем коде - почему вы используете разные MN для каждой открытой сделки? Это противоположно тому, для чего предназначены MN. Идея MN заключается в том, что вы можете идентифицировать все сделки определенного советника, просто взглянув на MN. В чем причина случайной части MN? Как бы выглядел код в вашем советнике, который закрывал бы все открытые сделки этого советника или отслеживал все стопы этого советника?
Извините, я имел в виду, что результирующий int magic_name превысит это распределение. Я перенесу комментарий в коде соответствующим образом.
Чтобы уравнять наше восприятие. Я бы предложил такие требования к этому "автоматизированному" magic_number. MN должен иметь следующее:
- Вы можете определить, каким советником был открыт данный конкретный ордер с указанным MN.
- Советник, содержащий эту технику - если он подключен к множеству (более 1), не будет генерировать одно и то же магическое число, если эти советники открывают ордера одновременно за пределами 1-секундного интервала.
- таким образом, не будет конфликта в обработке ордеров, но в то же время происхождение MN все еще может быть отслежено.
- пожалуйста, добавьте, если мой список не полон...
- содержащаяся информация будет 101 - идентификатор эксперта; 1 - количество This_EA, действующее на данный момент; time_stamp - время отправки ордера.
- Затем мы можем просканировать его с помощью StringSubStr и узнать, что определенный ордер был открыт This_EA, в то время как был прикреплен 1 другой This_EA.
Но для чего нужна временная часть в MN? Почему бы просто не использовать только номера экспертов? И не использовать substr? Использование substr потребует преобразования int в строку, затем некоторых строковых операций и сравнения строк, временная часть MN отбрасывается, потому что она никогда не нужна. Строковые операции с целыми числами обычно выглядят по-дилетантски, потому что в большинстве случаев их можно было бы лучше решить, закодировав информацию в разных битах 32-битного слова и используя побитовые операции для манипулирования или проверки, что было бы на порядки быстрее и элегантнее.
Почему бы просто не использовать (EA-instance-unique) значение int для mn и использовать простое целочисленное сравнение для сравнения либо всего числа, либо определенных его битов?
Например, пусть первые 28 бит будут идентификатором, а последние четыре бита - числом от 0 до 15 для идентификации различных типов сделок (например, если он может открывать 3 различных типа ордеров: начальный, уровень1, уровень2 и хедж).
Если я правильно понял - ваше решение для двух разных экспертов, случайно имеющих одинаковый ID, заключается в том, чтобы поместить все ID экспертов в заголовок каждого эксперта. Это своего рода боль в заднице... Даже если вы поместите эту часть в включаемый файл, вам все равно придется перекомпилировать все эксперты для каждого нового эксперта.
Вопрос о постоянстве все еще остается. Я не знаю, как это будет работать после перезапуска терминала или после переключения на совершенно другой терминал...
Нет, не понял :) пожалуйста, прочитайте комментарии в коде относительно WindowExpertName().
При вызове из эксперта он будет получать имя файла эксперта/скрипта/индикатора без ".mq4" или ".ex4", вам не нужно ставить никаких include, просто назовите свои советники соответствующим образом.
PS : извините за спамный ответ :)
Но для чего нужна часть времени в MN? Почему бы просто не использовать только числа EA? И не использовать substr? При использовании substr нужно преобразовать int в строку, затем выполнить несколько строковых операций и сравнить строки, а временная часть MN отбрасывается, потому что она никогда не нужна. Строковые операции с целыми числами обычно выглядят по-дилетантски, потому что в большинстве случаев их можно было бы лучше решить, закодировав информацию в разных битах 32-битного слова и используя побитовые операции для манипулирования или проверки, что было бы на порядки быстрее и элегантнее.
Почему бы просто не использовать (EA-instance-unique) значение int для mn и использовать простое целочисленное сравнение для сравнения либо всего числа, либо определенных его битов?
Например, пусть первые 28 бит будут ID, а последние четыре бита - числом от 0 до 15 для идентификации различных типов сделок (например, если советник может открывать 3 различных типа ордеров: начальный, уровень1, уровень2 и хедж).
хм... Я использую часть времени, потому что я думал, что MN для каждого ордера, открытого советником, должен быть уникальным по отношению к другим ордерам, открытым в то же время тем же советником на разных графиках.
Предпосылкой было бы: Если советник открыл два (более) ордера одновременно с одним и тем же магическим номером, они не могут иметь одинаковый MN, иначе это будет конфликтовать при обработке ордеров и идентификации...
идентификации ордеров... возможно, я ошибочно путаю это с захватом OrderTicket (или нет?).
- включение стратегии в MN было бы следующим шагом, естественно.
- Я вижу, что ваше мастерство превосходит мое на световые годы: )). У меня пока нет возможности оптимизировать операции, поэтому я и запостил это... Теперь я знаю, что проверка с помощью побитовых операций будет быстрее.
Спасибо. Возможно, позже мне придется обратиться к вам за разъяснениями :)))
хм... Я использую часть времени, потому что я думал, что MN для каждого ордера, открытого советником, должен быть уникальным по отношению к другим ордерам.
Нет, они могут быть какими угодно. так же как и комментарий. рассматривайте их как своего рода числовой комментарий. Все ручные сделки, открытые с помощью обычного пользовательского интерфейса MT4, будут иметь магическое число 0, поэтому вы можете, например, перебрать все ордера и закрыть/удалить все ручные сделки и ордера, оставив все сделки советника нетронутыми.
Все мои советники создают свой собственный номер, уникальный для (имя советника + символ + таймфрейм), поэтому я потратил так много усилий на поиск хорошей и простой хэш-функции для создания этого номера. Этот хэш даже настолько хорош, что я могу легко отрезать последние несколько битов этого хэша, чтобы освободить место для подномеров (если мне это нужно, но мне это редко нужно), и это все еще будет достаточно безопасно от столкновений.
Но большинство моих советников используют хэш напрямую и не имеют поднумерации, потому что у них только один тип сделок и все сделки обрабатываются одинаково.
Для уникальной идентификации только одного определенного ордера всегда есть номер тикета.