19-значные номера заявок и сделок на MOEX

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: 1 2 След.
RSS
19-значные номера заявок и сделок на MOEX
 
#1
02.12.2019 14:14:42
Добрый день, разработчики терминала!

Прочитал уведомление "Уведомление в связи с обновлением торговой системы срочного рынка Московской биржи (Spectra 6.3)", где говорится о 19-значных номерах заявок и сделок.

Там было написано так: Внимание! Это крайне важно!

В связи с этим вопросы:

1) Если внутри QLua для номеров заявок и сделок используются переменные числового типа, то появятся ли отрицательные значения в этих переменных?

2) Если появятся, то будет ли корректно работать постановка/снятие заявок через sendTransaction?

Просьба добавить любые другие подробности касательно того, с какими проблемами могут столкнуться роботописатели?
 
 
#2
02.12.2019 14:57:33
Нашёл тут на форуме комментарий Михаила Булычёва:
Цитата
Добрый день.
В Lua все числа хранятся как double, соответственно целые числа до 2^53 хранятся без потери точности.

2^53 = 9 007 199 254 740 992‬.

Тут 16 знаков. Получается, что не влезают новые 19-значные номера в Lua 5.1.

Как быть?
 
 
#3
02.12.2019 15:22:30
Здравствуйте,
Версия с поддержкой 19ти номеров еще не вышла и об этом явно сказано в уведомлении.
 
 
#4
02.12.2019 17:24:31
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
 
 
#5
02.12.2019 17:43:22
Цитата
_sk_ написал:
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
К сожалению мы не имеем права разглашать информацию до официального релиза.
 
 
#6
02.12.2019 17:52:04
Цитата
_sk_ написал:
2^53 = 9 007 199 254 740 992‬.
53 разряда, а не 2^53

Цитата
_sk_ написал:
к чему нам готовиться.
к худшему конечно, как обычно  :wink:  
 
 
#7
02.12.2019 18:04:34
Цитата
Sergey Gorokhov написал:
Цитата
_sk_ написал:
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
К сожалению мы не имеем права разглашать информацию до официального релиза.
Осталось 14 дней, а программа еще не готова?  Ее же не только вы должны выпустить, но и брокеры распространить.

А что будет с версиями 7.ХХ?

Как будут отрабатывать все текущие функции, которые возвращают таблицу, в которой присутствует номер заявки или номер сделки?
Ждем официального ответа по этому поводу.
https://trdrobot.ru - Роботы и индикаторы
Журнал сделок трейдера для QUIK
 
 
#8
02.12.2019 18:20:46
Работа с заявками и сделками - это базовые вещи, если вы начнете их менять на строку, то там вылезет у вас куча ошибок, и это точно вы не успеете за оставшиеся 14 дней, а нам придется переделывать все скрипты, которые торгуют.
https://trdrobot.ru - Роботы и индикаторы
Журнал сделок трейдера для QUIK
 
 
#9
02.12.2019 20:59:49
Цитата
Александр М написал:
и это точно вы не успеете за оставшиеся 14 дней
Александр, не могли бы сформулировать для обчего развития суть претензии к АРКА вида:

вы, нехорошие люди, давно должны были понимать,  что число в 19 цифер в номерах срочно было очень надо, тк .... _вставить нужное_ ...
и ничего не было сделано  - позор!
 
 
#10
02.12.2019 22:51:02
Цитата
_sk_ написал:
где говорится о 19-значных номерах заявок и сделок.
Там еще о партициях говорится, вот где веселье-то ожидается. А по 19 знакам как всегда, кто не ленился писать unsigned, те отдыхают, все прочие выходят на субботник. Не говоря уже о любителях даблов повсюду. Тксть 640к хватит всем 2.0.
 
 
#11
03.12.2019 10:34:45
Цитата
новичок написал:
Цитата
Александр М написал:
и это точно вы не успеете за оставшиеся 14 дней
Александр, не могли бы сформулировать для обчего развития суть претензии к АРКА вида:

вы, нехорошие люди, давно должны были понимать,  что число в 19 цифер в номерах срочно было очень надо, тк .... _вставить нужное_ ...
и ничего не было сделано  - позор!
Чтобы что-то формулировать, надо получить ответ, что ДА проблема есть во всех существующих версиях, будет релиз, в котором будет сделано ....
И что будет сделано надо писать заранее, а не по факту. Если будут изменены типы полей на строку например, то это однозначно изменение в скриптах.
https://trdrobot.ru - Роботы и индикаторы
Журнал сделок трейдера для QUIK
 
 
#12
04.12.2019 12:38:29
Беда откладывается до февраля 2020 года.

Цитата
... по просьбам пользователей в ближайшем релизе будет установлено  временное ограничение на максимальную длину номеров – 14 десятичных  цифр.

https://www.moex.com/n26101/?nt=107
 
 
#13
04.12.2019 12:53:43
Цитата
_sk_ написал:
Беда откладывается до февраля 2020 года.

Цитата
... по просьбам пользователей в ближайшем релизе будет установлено  временное ограничение на максимальную длину номеров – 14 десятичных  цифр.

https://www.moex.com/n26101/?nt=107
Спасибо за информацию, Новый Год пройдет спокойно и душевно.
https://trdrobot.ru - Роботы и индикаторы
Журнал сделок трейдера для QUIK
 
 
#14
04.12.2019 12:55:46
Мне кажется, что наиболее подходящим решением для Lua будет возврат номеров заявок и сделок в виде строки. С этими номерами арифметические операции вряд ли кто-то производит. Номера используются в качестве ключей в таблицах. Если ключей много и хочется экономить память, то уже писатели скриптов могут этим заняться, разбивая длинные строки на более короткие подстроки и преобразовывая их в числа для формирования составных ключей.

Теоретически, можно как-то через userdata выкручиваться, чтобы сразу экономить память, но там ещё разбираться надо.
 
 
#15
04.12.2019 15:17:49
Цитата
_sk_ написал:
С этими номерами арифметические операции вряд ли кто-то производит.
еще как пользуются
Цитата
_sk_ написал:
возврат номеров заявок и сделок в виде строки
поздравляю, #ВСГ
 
 
#16
04.12.2019 22:34:34
Цитата
_sk_ написал:
Теоретически, можно как-то через userdata выкручиваться, чтобы сразу экономить память, но там ещё разбираться надо.
Для 64-битного квика можно пушить непосредственно номер как LUA_TLIGHTUSERDATA (по-хорошему это пойнтер, но кто мешает скастить, луа-то все равно) и навесить на это поле метаметод, возвращающий что-нибудь читаемое из луа, строку там или таблицу. Соответственно, кто не дергает номера, никакого оверхеда не имеет. Из сей же можно будет выдергивать голое 64-битное значение через rawget тоже без оверхеда. Но, увы, на 32-битном квике такой костыль не сработает.
 
 
#17
05.12.2019 06:42:22
Цитата
новичок написал:
Цитата
_sk_ написал:
С этими номерами арифметические операции вряд ли кто-то производит.
еще как пользуются
Цитата
_sk_ написал:
возврат номеров заявок и сделок в виде строки
поздравляю, #ВСГ
Приведите, пожалуйста, примеры того, как Вы работаете с номерами заявок и сделок, чтобы потребовались арифметические операции (+, 0, *, /) с этими номерами. Интересно.
 
 
#18
05.12.2019 07:36:03
Цитата
_sk_ написал:
примеры того, как Вы работаете с номерами заявок и сделок,
извините, но нет

Цитата
_sk_ написал:
чтобы потребовались арифметические операции
есть арифметика, есть и другие моменты
то, что можно озвучить: системы хранения и выборки должна быть вполне быстрой

но даже более тут главное - все эти вопросы совершенно пустые ... надуманные, тк лонг в qlua должен быть доступен и по массе других причин

очевидно пришло время апнуть луа до 5.3 и не потому, что 5.1 это мало, просто экосистема такова на текущий момент ( кстати  - так себе экосистема, imo )
 
 
#19
09.12.2019 21:06:08
У меня есть сравнения <> номеров сделок, заявок. Если они будут текстовые, то можно будет сравнить через "костыли", которые конечно будут работать медленнее. В сейчашнем  lua 14 Знаков "помещается", а 5.3 как ?
 
 
#20
16.12.2019 14:54:11
Цитата
Sergey Gorokhov написал:
Цитата
_sk_ написал:
С этим не поспоришь. Только лучше бы знать, к чему нам готовиться. Время то уже тикает, до 16 декабря не так уж много времени осталось. Хотя бы спецификации уже есть? Номера будут строками приходить, раз они в Lua NUMBER не укладываются? Или будет обновление Lua до 5.3, где есть поддержка long на 64-бита?
К сожалению мы не имеем права разглашать информацию до официального релиза.
Не имеете право разглашать, до выхода какого релиза? Квика нового или имеется ввиду обновления Spectra ?
 
 
#21
17.12.2019 13:24:51
Цитата
Vladimir написал:
Не имеете право разглашать, до выхода какого релиза? Квика нового или имеется ввиду обновления Spectra ?

До выхода терминала QUIK который будет приурочен к обновлению Spectra с 19ти значными номерами.
Биржа говорит что это произойдет не раньше февраля 2020 г.
 
 
#22
25.02.2020 19:44:11
Цитата
Sergey Gorokhov написал:
До выхода терминала QUIK который будет приурочен к обновлению Spectra с 19ти значными номерами.Биржа говорит что это произойдет не раньше февраля 2020 г.
Подскажите, изменения не скоро случатся?
На СПБ хоть и не 19ти значные номера, а 17-ти, но тоже не помещаются в number без потери точности
 
 
#23
26.02.2020 14:24:07
Цитата
Владимир написал:
Подскажите, изменения не скоро случатся?

В промышленной системе изменение запланировано на апрель 2020 года, см. https://www.moex.com/n26656/?nt=107
 
 
#24
27.02.2020 13:08:25
Цитата
Sergey Gorokhov написал:
Цитата
Владимир написал:
Подскажите, изменения не скоро случатся?

В промышленной системе изменение запланировано на апрель 2020 года, см.  https://www.moex.com/n26656/?nt=107
Это у Мосбиржи запланировано на апрель, а у вас когда запланировано? Обновление QUIK должно выйти заранее, как минимум за 2-3 недели (а лучше больше) до перехода у Мосбиржи. Еще брокеры обновить ПО должны, потом клиентам выслать.
https://trdrobot.ru - Роботы и индикаторы
Журнал сделок трейдера для QUIK
 
 
#25
28.02.2020 03:39:22
Цитата
Александр М написал:
Цитата
Sergey Gorokhov написал:
 
Цитата
Владимир  написал:
Подскажите, изменения не скоро случатся?
 
В промышленной системе изменение запланировано на апрель 2020 года, см.   https://www.moex.com/n26656/?nt=107  
Это у Мосбиржи запланировано на апрель, а у вас когда запланировано? Обновление QUIK должно выйти заранее, как минимум за 2-3 недели (а лучше больше) до перехода у Мосбиржи. Еще брокеры обновить ПО должны, потом клиентам выслать.
Добрый день.

Обновления обязательно выйдут заранее, чтобы брокера успели обновить свои системы.
 
 
#26
29.02.2020 01:21:43
а в старых версиях квика можно будет работать с текстовыми номерами заявок?
 
 
#27
02.03.2020 11:17:58
Поскольку разработчики терминала имеют возможность проверить поведение терминала на тестовом полигоне МосБиржи и это не связано с релизом 8-й версии, просьба к ним дать ответ на вопросы.

В рамках QLua,  если используются 19-значные номера сделок, что терминал версии 7.xx возвращает в полях:
* trade_num таблицы, приходящей в функции обратного вызова OnTrade;
* order_num таблицы, приходящей в функции обратного вызова OnTransReply;
* order_num таблицы, приходящей в функции обратного вызова OnOrder?
Желательно с примером, какой был номер на бирже и как этот номер отображается в QLua.

Я предполагаю, что номера сделок с потерей числовой точности. Если да, то выходит, что алготрейдинг в 7-й версии терминала с использованием QLua станет невозможным на срочном рынке.
 
 
#28
02.03.2020 12:08:13
Цитата
_sk_ написал:
выходит, что алготрейдинг в 7-й версии терминала с использованием QLua станет невозможным на срочном рынке.

ранее мы уже говорили что в старых версиях есть проблема и она будет исправлена, но исправление точно будет не в 7х версиях.
так что да, можно говорить о том что на старых версиях корректная работа будет невозможна.
 
 
#29
02.03.2020 12:16:49
Цитата
Sergey Gorokhov написал:
ранее мы уже говорили что в старых версиях есть проблема и она будет исправлена, но исправление точно будет не в 7х версиях.так что да, можно говорить о том что на старых версиях корректная работа будет невозможна
но текстовый номер заявки всё равно приходит в сообщении о транзакции? Его можно будет использовать, хоть он и 19 значный?
 
 
#30
02.03.2020 12:22:37
Цитата
Дмитрий написал:
но текстовый номер заявки всё равно приходит в сообщении о транзакции?
Да приходит.

Цитата
Дмитрий написал:
Его можно будет использовать, хоть он и 19 значный?
да можно, при условии что нигде в коде не будет преобразования строка->число или обратно
Нам не известно какая логика у Вас в скриптах, если для Вашей логики подойдет такое решение, значит Вам повезло.
 
 
#31
02.03.2020 12:28:32
Цитата
Sergey Gorokhov написал:
да можно, при условии что нигде в коде не будет преобразования строка->число или обратноНам не известно какая логика у Вас в скриптах, если для Вашей логики подойдет такое решение, значит Вам повезло.
Спасибо успокоили. Нигде не преобразовывается.
А ещё подскажите по поводу второго изменения биржи о так называемом раздельном учёте заявок по коду актива. Надеюсь клиентских терминалов это не коснётся и все изменения будут на уровне сервера?
 
 
#32
02.03.2020 12:30:38
Цитата
Дмитрий написал:
А ещё подскажите по поводу второго изменения биржи о так называемом раздельном учёте заявок по коду актива. Надеюсь клиентских терминалов это не коснётся и все изменения будут на уровне сервера?

не коснется
 
 
#33
02.03.2020 12:59:53
Цитата
но текстовый номер заявки всё равно приходит в сообщении о транзакции? Его можно будет использовать, хоть он и 19 значный?

Такое есть только в OnTransReply, но нет в OnTrade, OnOrder, так что эта информация особенно не поможет, т.к. на одном OnTransReply далеко не уехать.
Цитата
что терминал версии 7.xx возвращает в полях:
* trade_num таблицы, приходящей в функции обратного вызова OnTrade;
* order_num таблицы, приходящей в функции обратного вызова OnTransReply;
* order_num таблицы, приходящей в функции обратного вызова OnOrder?
Желательно с примером, какой был номер на бирже и как этот номер отображается в QLua.

Вопрос остался без ответа. Можете привести реальный пример типа: на бирже был номер заявки 9876543210987654321, внутри QLua это будет видно как ... (и привести значение, которое в QLua получится). Тогда явно будет видно, с какими проблемами столкнёмся.
 
 
#34
02.03.2020 13:02:06
_sk_,

Зачем? разве одного только факта что они будут некорректные не достаточно?
Какая разница в чем именно будет заключаться некорректность, она просто будет и всё.
 
 
#35
02.03.2020 13:05:38
Цитата
_sk_ написал:
на бирже был номер заявки 9876543210987654321, внутри QLua это будет видно как
Уже есть конкретика, как это будет видно: https://forum.quik.ru/messages/forum10/message41712/topic5021/#message41712
 
 
#36
02.03.2020 13:09:15
Цитата
Зачем? разве одного только факта что они будут некорректные не достаточно?

Возможно, что по некорректным значениям из QLua можно с помощью каких-либо преобразований и внешней информации восстановить-таки корректные значения.

Если происходит потеря точности, когда последовательные номера отображаются в одинаковые числа, тогда уже всё пропало.
 
 
#37
02.03.2020 13:10:38
Цитата
Anton написал:
Цитата
_sk_ написал:
на бирже был номер заявки 9876543210987654321, внутри QLua это будет видно как
Уже есть конкретика, как это будет видно:  https://forum.quik.ru/messages/forum10/message41712/topic5021/#message41712
Если это действительно так, то спасибо за пример.
 
 
#38
02.03.2020 14:05:17
Цитата
_sk_ написал:
Такое есть только в OnTransReply, но нет в OnTrade, OnOrder, так что эта информация особенно не поможет, т.к. на одном OnTransReply далеко не уехать.
зачем вам "даблы" для номеров транзакций? эти номера не предназначены для каких либо вычислений
 
 
#39
02.03.2020 16:01:27
Цитата
Дмитрий написал:
зачем вам "даблы" для номеров транзакций?
Проблема не столько в числах, хотя, если скрипт подгружает длл, парсить в ней строки будет печально. Дело еще в том, что квику придется запихивать в луа номера трейдов не только ваших, но и из ТВС, а их там очень много и они не повторяются. То есть все вот эти миллионы строчек будут аллоцированы из кучи в режиме "по одной". Получим оверхед как по расходу памяти, так и по нагрузке на процессор, причем получим все, и кому эти номера нужны, и кому нет. Выше предлагал пушить номера в числовом виде как LUA_TLIGHTUSERDATA, скастив к указателю,  и добавить поле-метаметод для получения строки из этого поля на лету. Также можно заменить старые поля с номерами в таблицах метаметодами, возвращающими даблы для совместимости. В итоге: кто не берет номеров - оверхеда не имеет, кто берет из сей - оверхеда не имеет, кто берет строками - имеет только на тех номерах, которые взял. Хак не заработает на версии 7 и ниже, дык вроде их фиксить и не собираются.
 
 
#40
02.03.2020 16:16:11
Цитата
Anton написал:
Дело еще в том, что квику придется запихивать в луа номера трейдов не только ваших, но и из ТВС
мне не нужны номера сделок и искать их в таблице всех сделок мне точно не нужно. А с заявками всё просто
 
 
#41
02.03.2020 16:21:48
Цитата
Дмитрий написал:
мне не нужны номера сделок и искать их в таблице всех сделок мне точно не нужно
Оно вам не нужно, а память и процессор жрать будет как не в себя, о чем и речь. А мне, например, нужны номера сделок из ТВС, и вариант "их там не будет" меня не устраивает.
 
 
#42
02.03.2020 16:30:11
Цитата
Anton написал:
Оно вам не нужно, а память и процессор жрать будет как не в себя, о чем и речь.
так если не обращаться к таблице всех сделок откуда процессор то, что то я не улавливаю
 
 
#43
02.03.2020 16:40:15
Цитата
Дмитрий написал:
если не обращаться
Хм, ну если только квик генерирует луа-таблицы в момент обращения, тогда да, что-то такой очевидный вариант я упустил из виду. Но тогда весь оверхед мой. В общем, надо пыль с одбц сдуть на всякий случай.
 
 
#44
03.03.2020 02:00:03
Для арки - как бы могло выглядеть предлагаемое выше изменение в коде квика (ровно две строчки). Очевидно, этот примитив можно выкатить за пару дней, он ничего не сломает, главное не пропустить все места, где пушится номер сделки или заявки. На выходе - кому не надо, тому и не надо, две строчки без аллокаций не оверхед, кому надо - из луа поля можно копировать, сравнивать, использовать как ключ в таблицах, преобразовывать в строку (про метаметоды я погорячился, там из коробки все есть); из сей можно просто получить void * и скастить обратно в число.
Код
void call_OnAllTrade(lua_State * s, const quik_all_trades_table_entry * pentry)
{
   // пушим вызываемую функцию
   lua_getfield(s, LUA_GLOBALSINDEX, "OnAllTrade");
   // пушим таблицу для передачи в OnAllTrade
   lua_newtable(s);
   // trade_num оставляем для совместимости
   lua_pushnumber(s, static_cast<double>(pentry->trade_num));
   lua_setfield(s, -2, "trade_num");
// НАЧАЛО ИЗМЕНЕНИЙ
   // поле номера сделки, условно "raw_trade_num"
   lua_pushlightuserdata(s, reinterpret_cast<void *>(pentry->trade_num));
   lua_setfield(s, -2, "raw_trade_num");
// КОНЕЦ ИЗМЕНЕНИЙ
   // далее все как было раньше
   lua_pushnumber(s, pentry->flags);
   lua_setfield(s, -2, "flags");
   // ...
   // и делаем вызов
   lua_call(s, 1, 0);
}
 
 
#45
05.03.2020 10:49:17
По америке начали возвращать номер заявки в 15-ти знаках. брокер Финам
Код
a=317934958413900
message (tostring(a))

Результат "3.179349584139e+014"

В результате уже сейчас нельзя отправить транзакцию на удаление данной заявки, т.к. там поле ['ORDER_KEY'] заполняется в виде строки.

Номер заявки брался напрямую из таблицы orders, как значение поля row.order_num

{["TRANS_ID"]="1593703383",["SECCODE"]="AMD.US",["ACTION"]="KILL_ORDER",["ACCOUNT"]="MCU1100",["ORDER_KEY"]="3.179349584139e+014",["CLASSCODE"]="STOCK_USA",}

Ответ по транзакции понятен:

"Ошибка транзакции 1593703383  Неправильно указан номер заявки: "3.179349584139e+014""

Что делать разработчики? Это не апрель, это уже сейчас.
https://trdrobot.ru - Роботы и индикаторы
Журнал сделок трейдера для QUIK
 
 
#46
05.03.2020 11:04:14
Цитата
Александр М написал:
По америке начали возвращать номер заявки в 15-ти знаках. брокер ФинамКодa=317934958413900
message (tostring(a))Результат "3.179349584139e+014"
Добрый день.
Попробуйте так

string.format('%0.17g', order_num)

Перед тем как задать вопрос, убедитесь, что решение Вашей задачи не описано в официальном мануале - 'Использование Lua в Рабочем месте QUIK.pdf' https://arqatech.com/upload/Public/quik_lua.zip
 
 
#47
05.03.2020 11:09:05
Цитата
Александр М написал:
Что делать разработчики? Это не апрель, это уже сейчас.

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

Попробуйте использовать другую функцию
Код
a=317934958413900
message(string.format("%.f",a))
 
 
#48
05.03.2020 11:46:48
Цитата
Sergey Gorokhov написал:
Цитата
Александр М написал:
Что делать разработчики? Это не апрель, это уже сейчас.

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

Попробуйте использовать другую функцию
Код
  a =  317934958413900 
 message ( string.format ( "%.f" ,a))
  
Я правильно понял ваш ответ, что после Вашего обновления и перехода на 19-ти значные номера заявок и сделок функцией tostring в рамках данных номеров пользоваться будет нельзя?
https://trdrobot.ru - Роботы и индикаторы
Журнал сделок трейдера для QUIK
 
 
#49
05.03.2020 11:52:22
Цитата
Александр М написал:
Я правильно понял ваш ответ, что после Вашего обновления и перехода на 19-ти значные номера заявок и сделок функцией tostring в рамках данных номеров пользоваться будет нельзя?


никто такого не говорил, не пытайтесь читать между строк.
Пока непонятно что будет с tostring
 
 
#50
05.03.2020 12:10:40
Цитата
Sergey Gorokhov написал:
Цитата
Александр М написал:
Я правильно понял ваш ответ, что после Вашего обновления и перехода на 19-ти значные номера заявок и сделок функцией tostring в рамках данных номеров пользоваться будет нельзя?


никто такого не говорил, не пытайтесь читать между строк.
Пока непонятно что будет с tostring
А когда станет понятно? Остался месяц, мы со своей стороны должны подготовить скрипты к корректной работе после изменения с Вашей стороны.
https://trdrobot.ru - Роботы и индикаторы
Журнал сделок трейдера для QUIK
 
 
Страницы: 1 2 След.
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2025,
ARQA Technologies
Наверх