Выпущен MetaTrader 4 Client Terminal build 600 с обновленным языком MQL4 и Маркетом приложений - страница 76

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

Ну... Давай на "слабо" меня брать не будем да?

Канэчна же я ни разу не закрыл... не то чтобы частично, даже и полный объём как закрыть не в курсе. О чём речь вообще? Я тута первый раз, и то проездом...

(ЗЫ. Я не теоретизирую, я намекаю на нормальный быстрый выход, и он, кстати, да-а-авным-давно уже написан и работает во многих советниках на реале. "А вам слабо?")

А массив с тикетами куда у тебя девается после перезапуска терминала? А если зависнет? Каждый раз по-новой тикеты переписывать в массив? А как будешь узнавать отличие своего массива тикетов до крэша и после? Опять все тикеты пересчитывать и просматривать два пула для сравнения? А нахрена тогда массив, если и так все тикеты есть, и в гораздо более надёжном хранилище, чем массив в твоей программе.

Учись писать надёжно. Потом поговорим. После сдачи экзаменов.

 
Ещё раз повторяю: Не хочу тебя обидеть и не пытаюсь показать твою неосведомлённость, но тебе трое говорят что так сделать можно, но НЕУДОБНО а ты продолжаешь упорствовать и переходишь на другую тему, видимо с целью затролить вопрос так, чтобы Ренат его не увидел. На сим я с тобой прощаюсь.
 
AlexeyVik:
Ещё раз повторяю: Не хочу тебя обидеть и не пытаюсь показать твою неосведомлённость, но тебе трое говорят что так сделать можно, но НЕУДОБНО а ты продолжаешь упорствовать и переходишь на другую тему, видимо с целью затролить вопрос так, чтобы Ренат его не увидел. На сим я с тобой прощаюсь.

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

За сим ... в сторонке посижу, понаблюдаю...

 
artmedia70:

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

За сим ... в сторонке посижу, понаблюдаю...



Артем, в том то и проблема, что предложенный Вами способ не работает универсально. Да, его можно применить у пары-тройки ДЦ. Но когда речь идет именно об универсальности программы, когда не хочется писать, что программа работает вот с этими ДЦ, а у других - не знаю, как будет, то такой подход нельзя назвать хорошим. Да и не стоит забывать о том, что сам ДЦ, у которого это до сих пор работало, вдруг что-то немного изменит в своем подходе, и программа перестанет работать правильно.

Еще раз. Для решения не подходят:

1. Тикеты (ибо ролловер).

2. Магики (ибо не обязательно ордер открыт этой же программой).

3. Комментарии (почему - указано в справке и неоднократно напоминалось разработчиками, что не нужно так делать).

Таким образом, на сегодняшний день нет универсального способа определения зависимости между родительским и дочерним ордером. Все, что сейчас используется в этом направлении, это костыли, которые в любой момент могут сломаться. Они есть у многих (в том числе и у меня) и на данный момент работают у тех ДЦ, для которых они разработаны, без сбоев. Но питать иллюзии о том, что это надежно, не стоит.

 
Scriptong:


Артем, в том то и проблема, что предложенный Вами способ не работает универсально. Да, его можно применить у пары-тройки ДЦ. Но когда речь идет именно об универсальности программы, когда не хочется писать, что программа работает вот с этими ДЦ, а у других - не знаю, как будет, то такой подход нельзя назвать хорошим. Да и не стоит забывать о том, что сам ДЦ, у которого это до сих пор работало, вдруг что-то немного изменит в своем подходе, и программа перестанет работать правильно.

Еще раз. Для решения не подходят:

1. Тикеты (ибо ролловер).

2. Магики (ибо не обязательно ордер открыт этой же программой).

3. Комментарии (почему - указано в справке и неоднократно напоминалось разработчиками, что не нужно так делать).

Таким образом, на сегодняшний день нет универсального способа определения зависимости между родительским и дочерним ордером. Все, что сейчас используется в этом направлении, это костыли, которые в любой момент могут сломаться. Они есть у многих (в том числе и у меня) и на данный момент работают у тех ДЦ, для которых они разработаны, без сбоев. Но питать иллюзии о том, что это надежно, не стоит.

+
 
Scriptong:


Артем, в том то и проблема, что предложенный Вами способ не работает универсально. Да, его можно применить у пары-тройки ДЦ. Но когда речь идет именно об универсальности программы, когда не хочется писать, что программа работает вот с этими ДЦ, а у других - не знаю, как будет, то такой подход нельзя назвать хорошим. Да и не стоит забывать о том, что сам ДЦ, у которого это до сих пор работало, вдруг что-то немного изменит в своем подходе, и программа перестанет работать правильно.

Еще раз. Для решения не подходят:

1. Тикеты (ибо ролловер).

2. Магики (ибо не обязательно ордер открыт этой же программой).

3. Комментарии (почему - указано в справке и неоднократно напоминалось разработчиками, что не нужно так делать).

Таким образом, на сегодняшний день нет универсального способа определения зависимости между родительским и дочерним ордером. Все, что сейчас используется в этом направлении, это костыли, которые в любой момент могут сломаться. Они есть у многих (в том числе и у меня) и на данный момент работают у тех ДЦ, для которых они разработаны, без сбоев. Но питать иллюзии о том, что это надежно, не стоит.

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

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

Какгрится - из двух зол...

ЗЫ. Естественно, я за введение двух дополнительных параметров ордера. Было бы отлично не иметь таких головных болей с плясками вокруг комментариев, тикетов, списков ордеров, цен и времён их открытия/закрытия и пр., пр., пр., из чего можно вынуть наследственность одного от другого.

 
artmedia70:

А вот массив, хранящийся в памяти - он до первого сбоя компьютера, в памяти которого эти массивы находятся.


А что мешает после креша пробежаться по всем ордерам и восстановить структуру наследования ордеров?

Причем наследование "вверх" - от существующих сейчас - вверх по дереву?

ПС Наличие параметров "дитя/родитель" и функций для работы с ними - приветствую.

 
artmedia70:

ЗЫ. Естественно, я за введение двух дополнительных параметров ордера. Было бы отлично не иметь таких головных болей с плясками вокруг комментариев, тикетов, списков ордеров, цен и времён их открытия/закрытия и пр., пр., пр., из чего можно вынуть наследственность одного от другого.

Ну слава богу, уговорили всем миром.

Понимаешь, видимо ты не так понял чем вызвана была просьба о внедрении дополнительных свойств ордера. У меня нет проблем в работе с комментариями к ордеру, где это надо там это работает, а ты мне начал рассказывать как это сделать...

artmedia70:

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

А с чего ты решил что я именно так пользуюсь массивами хранящими тикеты ордеров???

Или ты считаешь что лучше перебирать ВСЕ открытые ордера по ВСЕМ инструментам на каждом тике, да ещё и перебирать ордера в истории, на всякий случай, а вдруг надо будет что-то определять...

 

вышеприведенное обсуждение немного напоминает фрагмент из всем известного фильма

Микки: - песиков-песиков любишь ?

Томми (по прозвищу титька): - чего ? а, собак ? собак я люблю..

 

tara:

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

Сто раз делился. Детишки просто пугаютца, начинают креститься и призывать духов.

// "Говно не может быть невкусным - миллионы мух не могут ошибаться !..." :)

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