ivanovr,
Я проверял, отображаются не корректно. Начало совпадает, а конец ( не путать с анотомическим органом) обрезан.
Но выход есть.
В транзакции есть поле, где пишется " Заявка № XXXXX успешно зарегистрирована". Там транслируется корректный номер заявки. Можно оттуда брать номер заявки.
_sg_, да, все так. Сделал преобразование double в int64 через round(). Но цифры в конце int64 не соответствуют исходному double. Мне главно чтобы уникальность соблюдалась, а с этим сомнения.
В тексте да, видел, но не всегда годится. Подписывают через trans2quik.dll на ордеры и трейды, у них IDшники double. Оба два пишутся в БД и потом сопоставляются по ID. При переходе на новые ID база стала ругаться на дубли. Возможно, база виновата что у нее точность double меньше.
Переделал на string 20 и IntToStr(round(id))
ivanovr,
то есть у Вас сейчас номера заявок небиржевые, а округленные и уникальные — и это работает?
Хитро.
Я тогда тоже может быть также сделаю, если это будет нормально работать.
Но риск нарваться на дубль, сами понимаете, есть.
_sg_, еще можно 8 байт double попробовать преобразовывать в 16 символов HEX-а. Но вроде ничего не выигрываем, кроме того что быстрей по производительности.
ivanovr, вчера покопал робота. Выяснил 1) когда выставляется сразу несколько сделок, часто OrderID округляется в одно и то же значение 2) робот не использует OrderID: при выставлении транзакции он передает кастомный TransId и он же потом приходит в OrderCallback и используется для связывания с Trans. Trades так нормально не привязать, но они не сильно и нужны.
Снять заявку тоже не получится, но это не получается даже через 32х-битный Quik почему-то.
Skifan,
Я думаю, что дело не только в Квике.
Вся технологическая цепочка «Квик — Сервер Брокера — Биржа» должна работать.
Поэтому желательно собрать как можно больше информации для того чтобы решить проблему.
Просто в таких проектах всегда есть заказчик и парочка эффективных манагеров. Надо вот их вычислить и им уже мозги пилить.
Просто не уверен, что брокеры в данный схеме участвуют.
А, что мешает использовать тип данных UInt64(ULong) при получении номера заявки. Весь год об этом вроде как талдычили, что на 19 значные номера перейдут. Давно уже можно было код поправить. Нормально все в таком варианте работает, глюков ни вчера, ни сегодня не было.
Anest, 99% достаточно просто обновить квик и не любить мозг :) Даже сбер уже несколько месяцев как обновился до восьмёрки и повесил баннер в окне квика, что всем клиентам это надо сделать. Но, оказывается, у многих винда 32-битная стоит ещё со времён царя Гороха. Или они просто принципиально сидят на 6-й версии, ждут, пока она совсем подключаться не перестанет.
1% использующих qlua надо просто потратить полчаса времени на пару правок (обычно это вставка string.format на цену при формировании транзакции), о которых на форуме квика всё расписали ещё с полгода назад :)
По сабжу — если люди не заметили этой возни за полгода, то они и дальше продолжат долбиться в глаза и никакого топика с настройкой квика не заметят, а будут и дальше плодить посты :) Потому что чукча не читатель.
Денис Г., а ты часом не знаешь для чего на 19-значные заявки биржа перешла и почему в квиках 6 версии, на которых куча народа как выяснилось сидит, это не пофиксить, там делов то на пару часов кодинга.
А 7-е версии Квика норм работают или нет?
dim800, этот вопрос надо бирже задавать :) Кмк, они хранят архив всех заявок, просто перестало хватать старых чисел.
Что касается квика, обычно никто не фиксит версии, которым сто лет в обед, тем более апдейт бесплатный. В семёрке уже должно работать. Восьмёрка нужна только тем, у кого скрипты, из-за lua 5.3.
У меня ещё smartx стоит, там вообще этот вопрос не поднимался :)
Пусть брокеры и разработчики Quik почитают «Обратную связь»Думаю, что так быстрееможно будет устранить все недочеты в работе связки Quik, Сервера Брокеров, Биржа
Плевать они хотели на ошибки. Их неисправят никогда. Представляю как они там угорают с того, что есть люди, которые серьёзно надеятся на устранение косяков.
khornickjaadle, сварено уже 280 км из 770 км это данные на конец второго полугодия 2024, но последние 180 км они два года строили. Очевидно морозят стройку.
Наталия Суханова,
Кончился пятый день ДЕКАМЕРОНА, начинается шестой.
В день правления Элиссы предлагаются вниманию рассказы о том, как люди, уязвленные чьей-либо шуткой, платили тем же или ...
Donbass, Газпром в убытки загнали не санкции, а чрезмерная любовь прислониться своим хоботом (газопроводом) к западной помойке. Моногамия противоистественна с точки зрения эволюции.
Я проверял, отображаются не корректно. Начало совпадает, а конец ( не путать с анотомическим органом) обрезан.
Но выход есть.
В транзакции есть поле, где пишется " Заявка № XXXXX успешно зарегистрирована". Там транслируется корректный номер заявки. Можно оттуда брать номер заявки.
В тексте да, видел, но не всегда годится. Подписывают через trans2quik.dll на ордеры и трейды, у них IDшники double. Оба два пишутся в БД и потом сопоставляются по ID. При переходе на новые ID база стала ругаться на дубли. Возможно, база виновата что у нее точность double меньше.
Переделал на string 20 и IntToStr(round(id))
после этого «дубли» исчезли?
то есть у Вас сейчас номера заявок небиржевые, а округленные и уникальные — и это работает?
Хитро.
Я тогда тоже может быть также сделаю, если это будет нормально работать.
Но риск нарваться на дубль, сами понимаете, есть.
Согласен.
Вот определил порог для (double)OrderNumber
public void TestQuikOrderNumber()
{
var quikOrderNumber = 8999999999999999d;
var ulongOrder = Convert.ToUInt64(quikOrderNumber);
Assert.AreEqual((ulong)8999999999999999, ulongOrder);
quikOrderNumber = 9999999999999999d;
ulongOrder = Convert.ToUInt64(quikOrderNumber);
Assert.AreNotEqual((ulong)9999999999999999, ulongOrder);
}
для уникальности можно не округлять, а просто хэшировать.
Тогда уникальность более надежная будет
я про округление написал. Округлить можно в одно то же значение.
Снять заявку тоже не получится, но это не получается даже через 32х-битный Quik почему-то.
нужно не только создать ветку,
необходимо, чтобы туда писАли «золотоискатели».
Тогда хоть какой-то толк будет.
Я думаю, что дело не только в Квике.
Вся технологическая цепочка «Квик — Сервер Брокера — Биржа» должна работать.
Поэтому желательно собрать как можно больше информации для того чтобы решить проблему.
Просто в таких проектах всегда есть заказчик и парочка эффективных манагеров. Надо вот их вычислить и им уже мозги пилить.
Просто не уверен, что брокеры в данный схеме участвуют.
1% использующих qlua надо просто потратить полчаса времени на пару правок (обычно это вставка string.format на цену при формировании транзакции), о которых на форуме квика всё расписали ещё с полгода назад :)
По сабжу — если люди не заметили этой возни за полгода, то они и дальше продолжат долбиться в глаза и никакого топика с настройкой квика не заметят, а будут и дальше плодить посты :) Потому что чукча не читатель.
А 7-е версии Квика норм работают или нет?
Что касается квика, обычно никто не фиксит версии, которым сто лет в обед, тем более апдейт бесплатный. В семёрке уже должно работать. Восьмёрка нужна только тем, у кого скрипты, из-за lua 5.3.
У меня ещё smartx стоит, там вообще этот вопрос не поднимался :)
7-ки работают. Заявки выставляются и снимаются.
Алгомудуль для выставления заявок не работает.
любое 32-разрядное Приложение может работать как на Win32 так и на Win64.
если собрать все в одном месте и показать им где все это лежит, то, может быть, и прочтут.