Частичное закрытие ордеров - страница 2

 
Aleksey Semenov:
родной магик не меняется при частичном закрытии - производный ордер будет с родным магиком - с серией ордеров каждому изначальному ордеру нужен отдельный магик чтобы вести этот ордер и глобальная переменная с этим магиком в имени с описанием состояния ордера: 0 - не закрывался, 1 - первое частичное закрытие, 2 - второе частичное закрытие, и присваивать новое значение в глоб переменную во время этого самого частичного закрытия

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

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

 
Viktar Dzemikhau:

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

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

Сразу упомяну подводный камень: глубина истории счета зависит от настроек, выбранных пользователем. Если не хватает истории (не удалось найти родительский ордер), то в общем случае придется генерировать фатальную ошибку. В частном случае (если разрешены вызовы dl-функций) историю можно подгрузить при помощи WinAPI.

 
В каких задачах нужно восстанавливать цепочку закрытия?
 
fxsaber:
В каких задачах нужно восстанавливать цепочку закрытия?

писал когда то , примерно такое: торговая панель, где каждый ордер сопровождается по своим "галкам", для некоторых ордеров было так:...после того как цена пройдет виртуальный ТП, закрыть ХХ % ордера, а остаток этого ордера трейлить с шагом...

 
Ihor Herasko:

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

Сразу упомяну подводный камень: глубина истории счета зависит от настроек, выбранных пользователем. Если не хватает истории (не удалось найти родительский ордер), то в общем случае придется генерировать фатальную ошибку. В частном случае (если разрешены вызовы dl-функций) историю можно подгрузить при помощи WinAPI.

О каком единственном рабочем варианте идёт речь? Я вижу, по крайне мере, 2 варианта:

1) Генерация каждому ордеру отдельный магик и используя глобальные переменные терминала, либо переменные, которые будут писаться в файл. Им присваивать значение уровня, на котором уже закрыта часть позиции.

2) Тот вариант, где нужно бегать по истории и писать дополнительные N-строк кода, что весьма даже не кстати.

 
fxsaber:
В каких задачах нужно восстанавливать цепочку закрытия?

Кому вопрос?

Изначально это предложено для частичного закрытия позиции на определённых уровнях, как я написал выше.

 
Viktar Dzemikhau:

Кому вопрос?

Изначально это предложено для частичного закрытия позиции на определённых уровнях, как я написал выше.

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

 
fxsaber:

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

Мне тоже не приходилось. Вы тоже считаете, что это лучше сделать при помощи переменных как я выше написал?

 
Viktar Dzemikhau:

Мне тоже не приходилось. Вы тоже считаете, что это лучше сделать при помощи переменных как я выше написал?

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

 
Viktar Dzemikhau:

О каком единственном рабочем варианте идёт речь? Я вижу, по крайне мере, 2 варианта:

1) Генерация каждому ордеру отдельный магик и используя глобальные переменные терминала, либо переменные, которые будут писаться в файл. Им присваивать значение уровня, на котором уже закрыта часть позиции.

Глобальные переменные или файл привязаны к определенному терминалу. Запустить советник на другом терминале без переноса этих данных не получится. Таким образом, такой вариант подходит только для более узкого круга задач. С историей счета универсально получается.

2) Тот вариант, где нужно бегать по истории и писать дополнительные N-строк кода, что весьма даже не кстати.

Эту мысль не понял.