TGB, Вы правильно понимаете: мой скрипт знает все подробности о текущих сделках. Когда эта информация становится ненужной, он о них забывает. Зачем мне бегать по таблице сделок (дополнительный "геморрой"), когда есть нормальные коллбеки, за которыми и следить-то не надо. Мало того, тот факт, что ты посмотрел на строчку в таблице, ещё не означает, что ты её обработал: это таблица для чтения у скрипта, но для записи у Квика, и могут возникать конфликты. Я точно знаю, например, что getItem МОЖЕТ возвращать nil - и что в таком случае делать будем? Наконец, эта таблица КВИКА, а не таблица ЛУА, т.е. на порядок более глючная и тормознутая конструкция. Да, мне тоже иногда приходится бегать по таблице 'orders', но это лишь в ИСКЛЮЧИТЕЛЬНЫХ случаях, пару раз за сутки, когда я хочу снять заявку, по которой не было ни одной сделки, и я тупо НЕ ЗНАЮ её номер. Да и не критично это всё: ну, допустим, скрипту не удастся снять неудачную заявку - да и хрен с ним: брокер потом снимет, если она до того времени не сработает - подумаешь, беда какая. А вот информация о сделках ВАЖНАЯ, её упускать нельзя. А полный код своего OnTrade я приводил - проще просто не бывает: сбрасываю данные в стек прерываний, И ВСЁ! Почти полный - там я тоже контролирую поля на nil на всякий пожарный. Да, "QUIK точно не HFT терминал", но не так уж редко бывают ситуации, когда весь рынок вдруг встрепенулся, и пара десятков ваших тикеров кинулись подавать заявки. А у меня хоть сотня сделок придёт - не беда: желания тикеров отправляются в стек заявок и выбираются оттуда по одной каждые полсекунды. Сделки немедленно попадают в стек прерываний и выбираются оттуда 4 раза в секунду, обычно по одной, но если там дубль уже обработанной (тоже тот ещё маразм: несколько прерываний на одно событие!), то по 2 или 3 элемента за раз. Даже если на рынке случится истерика, скрипт спокойно всё разгребёт за 10-20 секунд или там за минуту. Сказка! Ну и, наконец, стек активных заявок - там элементы существуют от момента подачи заявки до её закрытия или снятия. Он тоже почти всегда пустой, искать там что-либо очень быстро, и нужен он, главным образом, для отлова дублей прерываний и обработки ситуаций, когда заявка реализуется через множество сделок.
Пользователь
Сообщений: Регистрация: 22.02.2023
09.07.2023 13:49:04
swerg, мои слова, процитированные Вами, были ответом Владимиру. Для себя я все выяснил, о чем и высказывался уже в этой ветке. Видимо, Вы поступили как в том анекдоте: "чукча - не читатель, чукча - писатель!"
Пользователь
Сообщений: Регистрация: 02.02.2015
миру мир!
10.07.2023 09:35:11
Ziveleos, и? Я что-то неправильно написал? Тогда напишите в чем я неправ.
Один FTP и HFT путает, другой недоволен, что его не там процитировали. А по делу-то что в итоге?
Пользователь
Сообщений: Регистрация: 12.05.2020
10.07.2023 10:16:55
Цитата
Владимир написал: Сделки немедленно попадают в стек прерываний и выбираются оттуда 4 раза в секунду, обычно по одной, но если там дубль уже обработанной (тоже тот ещё маразм: несколько прерываний на одно событие!), то по 2 или 3 элемента за раз.
Можно выбирать 4 раза в секунду новые сделки из таблицы сделок и при этом не требуется ведения стека прерываний, борьбы с дублями колбеков, которые к тому же выполняются в потоке, отличном от main, а потому, по-хорошему, надо учитывать и то, что у вас со стеком ведется работа из двух потоков. Фрагмент эффективной обработки таблицы сделок:
Код
--- Инициализация -----
local NumberOf = 0 ---- сохраненная длина таблицы сделок --
local NumberOf_t --
local tbl_trades
-------
-- Фрагмент чтения новых сделок (4 раза в секунду ) ---
NumberOf_t = getNumberOf ('trades') --- быстрая операция ---
if NumberOf_t > NumberOf then -- обработка всех новых возникших сделок --
for i = NumberOf - 1, NumberOf_t - 1 do -- индексы в таблицах QUIK начинаются с 0 --
tbl_trades = getItem ('trades', i) -- быстрая операция (прямое чтение по индексу) ---
--- дальнейшая обработка новых сделок ---
----------------------------------------
end
NumberOf = NumberOf_t -- сохранение длины таблицы сделок --
end
Пользователь
Сообщений: Регистрация: 25.09.2020
10.07.2023 14:23:57
TGB, Да, можно выбирать 4 раза в секунду новые сделки из таблицы сделок, но ЗАЧЕМ? Зачем постоянно дрочить таблицу КВИКА, если можно вообще без обращения к ней иметь все данные уже внутри самого скрипта, в таблицах ЛУА? И что такое "ведение стека прерываний"?ВААПЩЕ НИЧЕГО! Любой из стеков инициализируется в начале мейна парой операторов, вроде: Stack={}; -- сам стек Stack[0]=0; -- его размер. И доступ к любому из его элементов мгновенный, по индексам, раз в сто быстрее, чем обращение к таблице Квика. Но это мелочь - куда важнее то, что избежать борьбы с дублями колбеков всё равно не удастся. Более того, эта борьба станет тысячекратно сложнее! Дело в том, что данные в этих "дублях" НЕ ВСЕГДА одинаковые, и то, что Вы считали данные из таблицы, отнюдь не гарантирует, что они там корректные. Те самые прерывания, которые поступают в Квик не только передаются скрипту в OnTrade, но и вызывают перезапись таблицы сделок - я сам видел нули в некоторых полях этой таблицы (в айдишках заявок, транзакций, в цене - кажется, когда-то об этом писал), так что данные в строках таблицы не всегда сразу "устаканиваются". И кто Вам сказал,, что ловля дублей прерываний "выполняется в потоке, отличном от main"? По-хорошему (т.е. как у меня), работа со всеми стеками ведётся именно в потоке main!
По Вашему коду: а) он вообще никак не учитывает нюансы, о которых я сказал выше и, следовательно, ОБЯЗАН время от времени "нарываться на неприятности". б) Он всегда вырабатывает ВСЕ появившиеся записи, даже если их придёт несколько десятков или сотен. А ведь надо и за рынком следить - курсы читать, свечи считать, решения принимать. в) В "секретной" части кода (то бишь в самой обработке) сидят потенциальные проблемы, и очень серьёзные: нужно ведь опознать, по какой ЗАЯВКЕ пришла эта сделка. У меня-то на этот случай есть стек активных заявок, а Вы что будете делать? Нужно ведь и деньги учесть, и портфель подкорректировать - да мало ли что ещё. А если это вообще "левая" заявка, поданная вручную, в обход скрипта через стакан?
Фрагмент четвертьсекундного обработчика ::Start:: -- метка на случай обработки ещё одного элемента i=a[0][7][0]; -- размер стека, он же индекс последнего элемента if i>0 then -- стек не пуст a[0][7][0]=i-1; -- новый размер стека прерываний ...
Не надо бегать по таблице сделок. Достаточно сохранять ее размер и только если он изменился, читать только новые записи.
колбек дает сигнал, когда размер таблицы изменится. Поэтому с колбеком даже не надо проверять размер таблицы. -------------------------------- Более того, можно в колбеке не разбирать таблицу на составляющие , а запоминать последний номер. В итоге в колбеке все будет очень просто и при этом не будет проблем с уборщиком мусора.
Пользователь
Сообщений: Регистрация: 30.01.2015
10.07.2023 15:37:01
относительно не использования библиотек C.. ================== Вот вам пример преимущества перед чистым СИ --------------------- Вы в срипте как курица с яйцом носитесь с sleep в main, Много поставите - раздуете стек или очередь мало поставите - лишняя пустая загрузка ядра процессора. ----------------- Делаем библиотеку на си для работы с событиями. В итоге поток main вызывается максимально быстро (примерно за 0.000001 сек) если надо и не вызывается никогда, если не надо. sleep вообще не нужен. ------------- И много чего еще можно сделать на СИ, например библиотека QLUA - вся исключительно на СИ или C++.
Пользователь
Сообщений: Регистрация: 30.01.2015
10.07.2023 15:37:32
пардон опечатка Вот вам пример преимущества перед чистым LUA
Пользователь
Сообщений: Регистрация: 15.06.2023
10.07.2023 16:12:07
Всем добрый день! Наконец дискуссия пошла в предметном русле русле.
swerg, Путать это мое Все. Так как моя личная подготовка слаба (уходит к истокам). Цель - уму разуму набираться. Не чего личного. Если чем то обидел прошу простить. Просто хочется от опытных пользователей предметного обсуждения вместо общих фраз.
Касаемо предмета. Переписал у себя т. всех сделок как показывает TGB, "и последний стал первым" - пока без нареканий. Обработку т. 'trades' веду в колбеке пример взял у Владимир, - работает. Но все ругают колбеки чего ждать от них не понятно,
Пользователь
Сообщений: Регистрация: 25.09.2020
10.07.2023 16:29:59
nikolz, Кто "носится"? sleep - это простейший способ эмуляции прерываний по таймеру, причём ЛЮБЫХ интервалов. Полскажите, будьте любезны, КАКИМ ОБРАЗОМ он может "раздуть стек или очередь" или ХОТЬ КАК-ТО загрузить процессор? Мой скрипт на дохленьком двухъядерном 2 ГГц процессоре без напряжения обслуживает сотни тикеров, а стеки почти всегда пусты. Это Ваш онанизм с библиотеками и работой с событиями нафиг никому не нужен. ЗА КАКИМ ХЕРОМ "поток main вызывать максимально быстро", если скрипт и так работает в нём 99% времени. Даже не работает, а скорее отдыхает. Весь код на девственно чистом LUA, и НИ ОДНОЙ поганой библиотеки.
nikolz написал: Вот вам пример преимущества перед чистым LUA
Наверняка что то есть полезное, но большинству пользователей хотя бы с луа разобраться. Просматривая ветки ведь основные нарекания идут на взаимодействие скрипта с терминалом (движок). Бросал свои рабочие скрипты потому что поиск ошибки становился затратным по Времени. Сейчас все тупо пишу в лог, и придерживаюсь чем проще тем лучше! Но Вопросов к реализации полно.
Пользователь
Сообщений: Регистрация: 18.12.2017
10.07.2023 16:40:47
По поводу getNumberOf ('trades') vs OnTrade: Всё зависит от того, где вы обрабатываете. Если из мэйна флаг изменения состояния OnTrade в цикле опрашивать, чтобы потом всё в мэйне обработать, то особой разницы между опросом в цикле изменения количества сделок getNumberOf ('trades') и этого флага в OnTrade практически нет, без OnTrade тогда проще. А если 2+2 непосредственно в OnTrade складываете и в мэйне обработки нет, то тогда не нужно с getNumberOf ('trades') заморачиваться. Всё зависит от трудоемкости обработки сделки, у каждого свой случай.
Пользователь
Сообщений: Регистрация: 25.09.2020
10.07.2023 16:50:10
Игорь М, Ну, я обрабатываю в мейне, на флаг изменения состояния OnTrade мне насрать - я даже не знаю, что это такое. OnTrade лишь записывает данные в стек, код я приводил.
Пользователь
Сообщений: Регистрация: 12.05.2020
10.07.2023 17:38:51
Цитата
VPM написал: Переписал у себя т. всех сделок как показывает TGB ,
В выложенном мною коде есть ошибка в строке:
Цитата
TGB написал: for i = NumberOf - 1, NumberOf_t - 1 do -- индексы в таблицах QUIK начинаются с 0 --
Должно быть: for i = NumberOf , NumberOf_t - 1 do -- индексы в таблицах QUIK начинаются с 0 -- --------------------------
Цитата
Владимир написал: раз в сто быстрее, чем обращение к таблице Квика. Но это мелочь
Согласен (хотя сто это "сильное" утверждение).
Цитата
Владимир написал: Те самые прерывания, которые поступают в Квик не только передаются скрипту в OnTrade, но и вызывают перезапись таблицы сделок - я сам видел нули в некоторых полях этой таблицы (в айдишках заявок, транзакций, в цене - кажется, когда-то об этом писал), так что данные в строках таблицы не всегда сразу "устаканиваются".
С этим я не сталкивался (все нужные мне поля для анализа сделки получаю), но если это так, то просьба к поддержке: подтвердить это. ----
Цитата
Владимир написал: Он всегда вырабатывает ВСЕ появившиеся записи, даже если их придёт несколько десятков или сотен.
Я не очень понимаю почему сделки нельзя обрабатывать "пачкой", но код легко изменить так, чтобы при его вызове обрабатывалось не более одной сделки.
Цитата
Владимир написал: проблемы, и очень серьёзные: нужно ведь опознать, по какой ЗАЯВКЕ пришла эта сделка. У меня-то на этот случай есть стек активных заявок, а Вы что будете делать?
Нет проблем. В считанной из таблицы сделок есть поле order_num. Это поле номер заявки, по которой выполнилась сделка. И вы легко можете опознать, по какой ЗАЯВКЕ пришла эта сделка.
Цитата
Владимир написал: А если это вообще "левая" заявка, поданная вручную, в обход скрипта через стакан?
Если в вашем стеке активных заявок, нет заявки, соответствующей считанной сделки, то можете, считать, что заявка подана вручную.
Пользователь
Сообщений: Регистрация: 22.02.2023
10.07.2023 18:04:22
Цитата
swerg написал: , и? Я что-то неправильно написал? Тогда напишите в чем я неправ.
Один FTP и HFT путает, другой недоволен, что его не там процитировали. А по делу-то что в итоге?
swerg, правильно, неправильно, не в этом дело. Захотелось высказаться - воля Ваша. Меня-то зачем приплетать?
Пользователь
Сообщений: Регистрация: 25.09.2020
10.07.2023 18:20:38
TGB, А мне кажется, даже побольше, чем в сто: реализации я, конечно, не знаю, но в одном случае должна быть лишь пара прыжков по косвенной адресации, а во втором - вызов метода, заполнение полей значениями оттуда. Впрочем, неважно - пусть будет в три раза.
Вряд ли поддержка здесь что-либо подтвердит или опровергнет.
При торговле с малым количеством сделок в сутки действительно пофиг, все ли записи обрабатывать или поштучно. Но при активной торговле лучше балансировать нагрузку - как при подаче заявок, так и при обработке сделок.
Я не про то: поле-то order_num есть, но оно В ТАБЛИЦЕ (в моём случае передаётся через OnTrade). А какую заявку подавал САМ СКРИПТ? Он же У СЕБЯ должен найти эту заявку. Или не найти. И опознать её можно только по ID транзакции, т.к. при подаче заявки скрипт не знает и знать не может номер заявки - не он его присваивает. Вот и представьте: у Вас 1000 тикеров в обслуживании - где искать совпадение будете? А у меня стек активных заявок, там их обычно 1-2, редко больше, а иногда и вовсе ни одной.
Я так и считал когда-то, что "если в стеке активных заявок не нашлим нужный номер, то это заявка подана вручную". Это может приводить к некоторым неприятным наводкам. И сейчас скрипт такие заявки просто игнорирует - он их НЕ ПОДАВАЛ, он не отвечает за криворукость подавшего, а просто пишет в лог: "Не нашли - левая сделка по бла-бла-бла.
Из Ваших публикаций на форуме, делаю краткий вывод: 1) Стратегия "скальперская" 2) Широкая диверсификация нужна на покрытие риска (> кол. тикеровв ) ну и конечно для заработка. 3) теперь понятна, грусть о потерянном рынке и подход "с высокой колокольне на все".
Я отошёл от таких подходов. Интересует средний срок и инвест. подход (Горизонт прогнозирования или цели). Именно о них я и рассуждаю в своих высказываниях. Именно здесь расхождение понятиях. Да и не считаю среднии, а фильтрую (Линия мгновенного тренда). отставание 1-3 периода данных в отличии 0.5 Периода. Это подходы Дхона Элерса. Надеюсь правильно на писал.
Пользователь
Сообщений: Регистрация: 15.06.2023
10.07.2023 23:13:56
Уважаемые, разработчики, для себя делаю вывод: не будет движка будем общаться на других форумах! Посмотрите по сторонам!
Спасибо за предметное развитие темы и поддержку. Не с логий норм у меня (пока). Николай дал свои наработки для примера, Попробовал по своему разумению. Не прошла фильтрация (от разработчиков)? опубликовал даже поругал, Ответ 0 or nil?
Собственно написал тоже что и Вашем примере.
Пользователь
Сообщений: Регистрация: 25.09.2020
11.07.2023 00:12:08
VPM, АРРИГИНАЛЬНО! 1) Нет у меня никакой "скальперской стратегии". 2) Широкая диверсификация никогда никому не мешала. 3) Что такое "грусть о потерянном рынке" и "подход с высокой колокольне на все", не врубился. 4) Про Джона Элерса впервые слышу.
VPM написал: Но все ругают колбеки чего ждать от них не понятно,
Так как не только использую все колбеки QLua, но и пишу свои дополнительные колбеки для скриптов Lua, то попробую объяснить что это за зверь. ------------------- колбек - это обычная глобальная функция на Lua (можно и на C), но с конкретным именем. --------------------- В терминале QUIK , при обработке полученных данных с сервера, перед тем как отправить данные в таблицы терминала, делается вызов функции Lua с именем колбека и ей передаются данные. -------------------------- Если такой функции нет, то ее нет в глобальном стеке Lua и ее вызов пропускается. =================== Резюме: Если Вы ругаете колбеки, то Вы ругаете "чистое" Lua, так как колбек -это функция на чистом луа. ------------- Колбеки обычно ругают те, кто луа не изучил толком и в функциях QLUA не разобрался. --------------- Но зеркало не виновато, в том ...
Пользователь
Сообщений: Регистрация: 15.06.2023
11.07.2023 08:39:16
Ziveleos, Огромное Вам спасибо! Очень ценно глубокомысленно талантливо!
Владимир, "Скальперский" это шаблон в подходах к организации торговле и удержанию позиции.
Что читать, не читать дело личное. Я лишь уточняю свой подход. John F.Ehlers (так правильно) опубликовал свой подход в четырех книгах в алгоритмах. Я одно время увлекся написав себе индикаторы, не которые до сих пор применяю в своих подхода. Отлично работает его "мгновенная линия тренда".
Это уже кому интересно, может посмотреть готовую реализацию не которых идей в свободном доступе у Николая.
Если Вы ругаете колбеки, то Вы ругаете "чистое" Lua, так как колбек -это функция на чистом луа. Колбеки обычно ругают те, кто луа не изучил толком и в функциях QLUA не разобрался.
Блестящая подборка клинического бреда. Как говорится: "Молчи - за умного сойдёшь".
VPM, А я тут при чём? Мне насрать на все "шаблоны в подходах к организации торговле и удержанию позиции". Как и на John F.Ehlers - подумаешь, "опубликовал свой подход в четырёх книгах в алгоритмах". Я сам алгоритмист, и ни один мой подход на 4 книги не растянуть: "кто неясно мыслит, тот неясно излагает". Индикаторы я никогда не писал и не собираюсь, и уж что-что, а "мгновенная линия тренда" мне уж точно нафиг не нужна.
Затраты - комиссии, конвертации. Чем шире и чаще тем больше.
Результат спред, тренды, ликвидность все разное.
На мой взгляд, диверсификация нужна когда инструменты двигаются в противоположных направлениях, тем самым сглаживая просадки.
Пользователь
Сообщений: Регистрация: 25.09.2020
11.07.2023 15:00:06
VPM, Сроду не обращал внимания ни на комиссию, ни на дивиденды, считая, что одно примерно компенсирует другое. Только когда Борьке понадобилось множество частых сделок с небольшой прибылью в каждой, да когда ввели это дурацкое правило про "пассивные сделки", что-то там прикрутил для снижения комиссии. На спред и тренды всегда плевал с высокой колокольни, а ликвидность лишь очень грубо оценивал для определения "качества" тикера: если там народ ковыряется, значит, и нам можно. А диверсификация нужна всегда - тупо для страховки: что бы такого ужасного ни произошло с парой-тройкой тикеров, на состоянии всего портфеля это мало повлияет.
Пользователь
Сообщений: Регистрация: 15.06.2023
11.07.2023 15:20:04
Цитата
Владимир написал: А диверсификация нужна всегда - тупо для страховки: что бы такого ужасного ни произошло с парой-тройкой тикеров, на состоянии всего портфеля это мало повлияет.
Нет такое я тоже пользую в портфеле Акций. Я не говорю что совсем не нужно я говорю про оптимальное количество к вопросу о количестве в портфеле
Цитата
Владимир написал: понадобилось множество частых сделок с небольшой прибылью в каждой
А что тут придумаешь в место рыночных лимитные ордера. Не знаю насчет отложенных.
Срочный он абсолютно другой, Во первых плечо 10. Ходит от клиринга до клиринга. Чем ближе окончание расчетов или поставки, тем ближе к своему активу.
Но главное клиринг - все обновит.
Пользователь
Сообщений: Регистрация: 18.12.2017
11.07.2023 15:33:48
Цитата
Владимир написал: , Ну, я обрабатываю в мейне, на флаг изменения состояния OnTrade мне насрать - я даже не знаю, что это такое. OnTrade лишь записывает данные в стек, код я приводил.
В коде у вас изменение размера стека. Это и есть флаг изменения состояния OnTrade.
Пользователь
Сообщений: Регистрация: 25.09.2020
11.07.2023 15:45:36
VPM, А оптимальное количество зависит от размера кошелька - чем больше, тем лучше. Я бы с удовольствием имел в портфеле 500-1000 тикеров, но где же столько бабла найти. Да и биржа накрылась медным тазом - по крайней мере, мой любимый долларовый рынок и не особо любимый евровый.
У меня все ордера только лимитные. А пассивные сделки - это сделки по заявкам, которые успели хоть немного полежать в стакане. А на срочном рынке плечо далеко не всегда 10, бывает и 3. Говорят, бывает ещё меньше, но я не видел. Да ещё клиринги, которые вымывают клиентов с малыми деньгами (точнее, с малыми резервами свободных денег.
Игорь М, Нет, изменение размера стека - это никакой не "флаг изменения состояния OnTrade" - это всего лишь указатель, что в стеке что-то есть. Выбирается стек в обработчике по таймеру, размер стека, ессно, меняется, а OnTrade при этом может и вообще не быть.
Пользователь
Сообщений: Регистрация: 15.06.2023
11.07.2023 16:23:12
Цитата
Владимир написал: оптимальное количество зависит от размера кошелька - чем больше, тем лучше
Нет это так не работает - зависимости не линейные.
Цитата
Владимир написал: Я бы с удовольствием имел в портфеле 500-1000 тикеров
А зачем ведь можно просто регулировать количество в открытой позиции. qty * price = Стоимость позиции. Да и управлять можно только qty. Главное чтоб рынок пропускал.
Мы на биржи за ним гоняемся. Или другие варианты они известны.
Цитата
Владимир написал: А на срочном рынке плечо далеко не всегда 10, бывает и 3
Не знал что гарантийное обеспечение разное. Но даже 3 требует других подходов.
Пользователь
Сообщений: Регистрация: 18.12.2017
11.07.2023 16:29:03
Вы писали, что используете OnTrade и обрабатываете в мэйне, хотя у вас в OnTrade аж 250 мс обработка, ну это ладно. Наверху большим количеством текста спорили с TGB , что лучше. Я кратко описал возможные варианты, даже не для вас, а для тех кто читает. В том варианте, что используете вы (только с одной функцией обратного вызова OnTrade), разницы между OnTrade и getNumberOf ('trades') с вашей скоростью опроса нет. Кому, что нравится, то он и делает.
Пользователь
Сообщений: Регистрация: 15.06.2023
11.07.2023 16:30:18
Проверил у себя да действительно старый брокер дает 10 а новый 3. Это видимо связано с квалификацией требованием ЦБ. А Вы говорите где взять.
Пользователь
Сообщений: Регистрация: 25.09.2020
11.07.2023 16:52:13
VPM, Это ТАК работает: чем больше, тем лучше. А на бирже нет никаких зависимостей - тем более, линейных.
А затем, что "регулировать количество в открытой позиции" - это ОДИН тикер. А я хотел бы иметь МНОГО тикеров. Но, увы, возможности моего скрипта многократно превышают мои финансовые возможности.
Нет, МЫ на бирже за баблом НЕ гоняемся. Мы снижаем риски.
Да, общего между фондовым и срочным рынком разве что нужно покупать дешевле, а продавать дороже.
Игорь М, Да, я писал, что использую OnTrade и обрабатываю в мэйне, но в OnTrade у меня НЕТ никакой обработки, да и в мейне она не "аж 250 мс", а стократ быстрее - это обработчик сделок вызывается раз в 250 мс. Да, я не согласен с TGB, хотя в наших подходах только одно различие: я говорю, что нужен ОДИН коллбек, а он - что НИ ОДНОГО. Всего в единичку разница!
Пользователь
Сообщений: Регистрация: 30.01.2015
12.07.2023 10:37:17
Самый бестолковый колбек это OnTrade. ------------------------------------ Нет смысла тратить на него вообще какое-нибудь время, так как совершение сделки отражается в заявках и в портфеле.
Пользователь
Сообщений: Регистрация: 25.09.2020
12.07.2023 11:21:06
nikolz, Лапуль, OnTrade - это ЕДИНСТВЕННЫЙ коллбек, на который можно потратить время: все остальные можно смело выбросить на помойку. А портфель нормальные люди ведут САМИ, а не читают его у брокера. Разве что для сверки портфелей, которая глючит со страшной силой, и лично я её тоже выбросил на помойку.
