Как получить список моих активных ордеров и список сделок по моим ордерам?

Спасибо, помогло. Но возник еще вопрос..
Функция TRANS2QUIK_START_ORDERS асинхронна? В течении какого времени гарантированно придут все активные ордера в CallBack???

И еще вопрос возник. Допустим я прикупил некий фьючерс, затем закрыл quik и мою торговую программу. Через неделю все включил. Как мне получить мой целиковый баланс ( свободные рубли, заблокированные на ордерах средства, фьючесы, акции )?


ps: сильно не пинайте, я просто начинающий

Добрый день.


Да, должен получить все имеющиеся заявки/сделки.




Можно смотреть в таблице состояние счета. Пункт меню Создать окно, таблица Состояние счета.

Для просмотра фондового/срочного рынка необходимо будет открыть две такие таблицы и в настройках таблицы указать соответствующую фирму.

Добрый день.
Получить свои заявки и сделки можно функциями: TRANS2QUIK_SUBSCRIBE_ORDERS, TRANS2QUIK_START_ORDERS и TRANS2QUIK_TRADE_STATUS_CALLBACK и TRANS2QUIK_START_TRADES
По ссылке можете воспользоваться готовым примером по работе функций: https://arqatech.com/upload/iblock/80a/Trans2QuikAPI_1.3_x64.zip

Да, в чем у Вас именно вопрос.

Где ответ? Не делайте вид, что вопрос не читали.

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

Отличным решением было бы информирование о получении всех ордеров в каллбэк (или не получении по истечении таймаута). Как сейчас, если я правильно понимаю, я даже не могу понять все пришло или ждать еще чего..

Все не верно.

1. Не нужно разрешать отправлять заявки во время проверки и это было бы правильно.
2. Куда сыпяться заявки меня не волнует, в каллбеке они должны быть только тогда, когда я их там жду (в нашем контексте). Если программисты квика не знают как это сделать, я подскажу ( хотя это очень просто ).
3. Таймаут не у меня, а у квика, и квик должен меня о его истечении информировать.
4. Таймаут я прикрутить не могу, тк. не знаю все заявки пришли или нет.

5. Не оправдывайте не умение программировать и продумывать систему до мелочей. На моей основной работе за такое программирование в лучшем случае выгонят.

Откуда появилась проверка? Кем она была инициирована?
Какие "все"? В каком месте вы начали атомарную транзакцию с группой заявок, чтобы требовать ее атомарного завершения?
У них QuikFIX есть, чет тут вопросов о нем не видать. А квик продумывать уже поздно, ему больше 20 лет, уже и биржи нет, для которой он писался, и вообще чудо, что он до сих пор в строю. Напишите свой, до мелочей продуманный, может вытесните его с рынка.
Тогда можно считать, что таймаут всегда является истекшим. Действительно, начните с этого предположения. Вы отправили что-то, таймаут истек. Ваши действия?

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

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

О факте успешного получения информации как раз и говорит дернутый колбек, невозможность получения информации - это по-хорошему нонсенс, крэш соединения. А вот что рабочее место не всегда колбек дергает, это тот самый косяк. Более того, из неофициальных, тксть, источников, ответ-то от сервера оно при этом получает. Тупо где-то ветка кода упущена.
А тут я согласен, и насчет костылей тоже, если говорить о работе чисто через апи. При наличии экспортируемых таблиц обойти можно, но в целом решение будет громоздким и неудобным для енд юзера, лучше сразу со стороны луа заходить. Там тоже не фонтан, только что возможностей для воркэраундов побольше.

Не поэтому только, а по самой природе распределенной системы. Ровно в ту микросекунду, когда рабочее место дернуло ваш код с докладом обо всех заявках, на сервер может подъехать еще одна ваша заявка и опа у нас опять неконсистентность. Запретить отправлять до получения ответа, как вы выше писали, нельзя, это равно синхронной отправке заявок по одной, то есть плюс два пинга на заявку минимум, многие такого "улучшения" не оценят. Правильным решением было бы добавление сущности "группа заявок" с атомарной обработкой, но чета я сомневаюсь, что в народный квик перетащат весь фикс. Даже если арка решит слить свой другой продукт, мамба такого альтруизма может не понять. Впрочем, мы по кругу уже пошли.

Вот тут корень, похоже. О каком текущем моменте речь, как его идентифицировать? Давайте нарисуем фейковый лог.

> 10:30:22.555 sell GAZP 1 ...
> 10:30:22.666 buy RIZ9 1 ...
> 10:30:22.777 sell SBER 1 ...
- 10:30:22:888 первый пакет достигает сервера, заявка передана на мамбу, получено подтверждение о постановке в стакан
< 10:30:22.888 ok GAZP accepted 1 filled 0 ...
- 10:30:22.999 второй пакет достигает сервера, заявка передана на фортс, ответа еще нет
- 10:30:23.111 третий пакет достигает сервера, заявка передана на мамбу, получено подтверждение о постановке в стакан
< 10:30:23.111 ok SBER accepted 1 filled 0 ...
- 10:30:23.222 получено подтверждение с фортса об исполнении
< 10:30:23.222 ok RIZ9 accepted 1 filled 1 ...
и т.д.

Фортс в примере подтормозил и прислал ответ на вторую заявку позже, чем мамба на третью. Что должен был сделать сервер? Сериализовать заявки и отвечать в порядке их поступления? Или он все правильно сделал?

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

Нет. Это текущий поток, это не совсем то.. Все инициализировано и работает. Работает, работает. Вдруг у меня (моей проги) возникла необходимость проанализировать все мои текущие ордера. Я делаю так :  TRANS2QUIK_SUBSCRIBE_ORDERS( "", "" ); TRANS2QUIK_START_ORDERS(); , а затем собираю их из калбека по одному. Но как мне понять, что я закончил принимать??? А как мне узнать, что я все принял??? Никак?  

C квиковской длл по другому незя)))