init, main... on_order_closed - было бы полезно - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
А вот количества функций реально не хватает. Вон в соседней ветке человек просит по кнопке менять символы. Просьба редкая, в общую функциональность включать незачем. Текущими средствами языка - делать сложно. А дать ему CreateChart(symbol) - и пусть на коленке ваяет, что ему нужно.
Фактически, то же самое, что сейчас приходится делать при необходимости onclose отследить - ведя массив открытых ордеров, сверяя его с реальным - и по результатам расхождения вызывая те же пользовательские on_open, on_close - но со спрятанными неаппетитными кишками.
Ведь подобие init тоже можно реализовать в start, заведя булевскую переменную first_run и выделив в start отдельный блок работы "при первом проходе". Но куда удобней, когда init лежит отдельно. Так же и с onclose.
А я эмулирую onclose проверяя историю ордеров. Мне кажется это экономнее. Хотя не проверял.
int AccTotal=OrdersHistoryTotal(); if (AccTotal != preAccTotal) { // Здесь перебор только появившихся после предыдущего тика ордеров for (i= preAccTotal; i<AccTotal; i++) { if(OrderSelect(i,SELECT_BY_POS,MODE_HISTORY)==false) { Print("Ошибка при доступе к исторической базе (",GetLastError(),")"); } ... } // for (i= preAccTotal; i<AccTotal; i++) preAccTotal = AccTotal; } // if (AccTotal != preAccTotal)Но с onclose конечно проще было бы.
А вот init, мне кажется, была введена совсем не для того, чтобы избавить пользователя от first_run, потому что во время выполнения init не гарантируются правильные значения предопределённых переменных, например Bars и Point.
(кстати, уж сколько копий сломано об OrderUserInfo с дополнительными пользовательскими данными об ордерах - ну понятно, нагрузка на сервер, но можно ведь сделать некое кэширование, если не прозрачное, так функцию SaveUserInfosToServer, запретить ее вызывать чаще раза в сутки )) - и овцы сыты и волки целы)
Rosh, мерси за ссылку (впрочем, почему-то не открывается (( ) - полагаю, каждый в этом треде, кому приспичивало, тем или иным образом подобную функцию написал и пользуется. Я больше ратую за приятную унификацию часто возникающих задач, чем за то, что подобную функцию нельзя написать ).
Rosh - ага, открыл ссылку - с контрольной суммой интересное решение ) - оно, правда, скорее на сам факт смены заточено, чем на отслеживание конкретного ордера - но интересно придумано.
Воистину, "голь на выдумки хитра" - уже три разных варианта со своими плюсами и минусами, и сколько можно еще напридумывать... )))
Это что, проверка связи? :)
Справедливое замечание. В принципе изменение настроек можно обработать запоминая тикет последнего обработанного ордера. А вот ситуация, когда ордер исчезнет из списка открытых и не появится в истории опасна и в этом подходе вроде не лечится. То есть если onclose нужно предпринимать критически важные действия, он не годится. Исходно же конструкция предназначена для сбора статистики - onclose сбрасываем на диск данные по этому ордеру (у меня обычно данные по рынку на момент открытия и характеристики ордера типа времени жизни или максимальной просадки за время существования). В этом случае таким редким событием как потеря ордера для истории можно наверное пренебречь. Для сбора же статистики в тестере этой опасности вообще нет и решающей становится скорость работы.
Типа того )). Мартингейл - классический пример, когда мы в том или ином виде эмулируем on_close )).
---
Candid Ага, для статистики можно игнорировать, да и по большому счету, с трудом можно представить ситуацию (и причину), когда в режиме работы советника уменьшаешь историю вообще до нуля. Если сам себе не враг, конечно ))).