неужели OnParam самый быстрый?

Страницы: 1
RSS
неужели OnParam самый быстрый?
 
Тестирую три колбека на предмет прихода цены последней сделки. Удивительно, но OnParam всегда реаигрует быстрее. Не было случая чтобы его кто то опередил.
Код
function OnAllTrade (alltrade)
    if string.find(ticker_list,alltrade.sec_code)~=nil then
    last_price[alltrade.sec_code]=alltrade.price
    
    if alltrade.sec_code==speed_check then
        time_diff=os.clock()-remember_time
        remember_time=os.clock()
        local datatime_table=alltrade.datetime
        toLog (log, speed_check.." пишет OnAllTrade "..alltrade.price.." time="..datatime_table.hour..":"..datatime_table.min..":"..datatime_table.sec.." "..datatime_table.ms.." "..datatime_table.mcs.." time_diff="..math.ceil(time_diff*1000))
    end
    
    end
end

 function OnParam (class, sec)
     if string.find(ticker_list,sec)~=nil then --and class=="TQBR" нужен если есть классы с такими же акци¤ми.
     
        if sec==speed_check and last_price[sec]~=getParam(sec,'last') then
            time_diff=os.clock()-remember_time
            remember_time=os.clock()
            toLog (log, speed_check.." пишет OnParam "..getParam(sec,'last').." time_diff="..math.ceil(time_diff*1000))
        end 
        
        if last_price[sec]~=getParam(sec,'last') then
            last_price[sec]=getParam(sec,'last')
        end

     end
 end

 function mycallbackforallstocks(class,sec,index)         
    local num_candles=ds[sec]:Size() 
    if index==num_candles then        
        if sec==speed_check then
            time_diff=os.clock()-remember_time
            remember_time=os.clock()        
            toLog (log, speed_check.." пишет DataSource "..ds[sec]:C(num_candles).." time_diff="..math.ceil(time_diff*1000))
        end 
        last_price[sec]=ds[sec]:C(num_candles)     
     end


end

function DataSource(class,sec,interval)
   ds[sec] = CreateDataSource(class,sec,interval)
   ds[sec]:SetUpdateCallback(function(...) mycallbackforallstocks(class,sec,...) end)
   return ds[sec]
end
вот логи с результатами (выборка). Единственное что плохо и странно - в некоторых случаях OnParam не срабатывает, хотя должен:

Код
01/09/17 10:59:18,762 APTK пишет OnParam 10.32 time_diff=2437 --долго не было сделки
01/09/17 10:59:18,794 APTK пишет DataSource 10.32 time_diff=32
01/09/17 10:59:18,794 APTK пишет OnAllTrade 10.32 time=10:59:18 668 668769 time_diff=0
01/09/17 10:59:18,794 APTK пишет OnAllTrade 10.32 time=10:59:18 668 668769 time_diff=0


01/09/17 11:01:26,475 APTK пишет OnParam 10.35 time_diff=39949 --долго не было сделки
01/09/17 11:01:26,585 APTK пишет OnAllTrade 10.33 time=11:1:26 537 537267 time_diff=109
01/09/17 11:01:26,585 APTK пишет OnAllTrade 10.34 time=11:1:26 537 537267 time_diff=0
01/09/17 11:01:26,585 APTK пишет OnAllTrade 10.34 time=11:1:26 537 537267 time_diff=0
01/09/17 11:01:26,585 APTK пишет OnAllTrade 10.35 time=11:1:26 537 537267 time_diff=0
01/09/17 11:01:26,803 APTK пишет DataSource 10.35 time_diff=219

01/09/17 11:01:36,314 APTK пишет OnParam 10.36 time_diff=3827 --долго не было сделки
01/09/17 11:01:36,314 APTK пишет DataSource 10.36 time_diff=0
01/09/17 11:01:36,314 APTK пишет OnAllTrade 10.36 time=11:1:36 196 196312 time_diff=0
01/09/17 11:01:36,314 APTK пишет OnAllTrade 10.36 time=11:1:36 196 196947 time_diff=0

OnParam не пришёл!!!!
01/09/17 11:05:55,150 APTK пишет OnAllTrade 10.37 time=11:5:55 349 349008 time_diff=158045
01/09/17 11:05:55,259 APTK пишет DataSource 10.37 time_diff=109

01/09/17 11:11:47,931 APTK пишет OnParam 10.35 time_diff=352672  --долго не было сделки
01/09/17 11:11:47,931 APTK пишет OnAllTrade 10.35 time=11:11:48 153 153625 time_diff=0
01/09/17 11:11:48,025 APTK пишет DataSource 10.35 time_diff=95
01/09/17 11:12:21,931 APTK пишет OnAllTrade 10.35 time=11:12:22 265 265944 time_diff=33906
01/09/17 11:12:22,024 APTK пишет DataSource 10.35 time_diff=95
01/09/17 11:15:27,376 APTK пишет OnAllTrade 10.35 time=11:15:27 778 778281 time_diff=185352
01/09/17 11:15:27,470 APTK пишет DataSource 10.35 time_diff=94

Вопрос 1: почему OnParam не всегда срабатывает, хоть и было изменение цены? (у меня в ОнПарам фильтр - не реагировать если цена прежняя). Я бы отказался от других колбеков, раз они медленные, но получается ОнПарам иногда даёт сбои.
Вопрос 2: у других участников форума тоже OnParam срабатывает первым? Или это зависит от брокера?
Спасибо.
 
Цитата
Космонавт написал:
Вопрос 1: почему OnParam не всегда срабатывает, хоть и было изменение цены? (у меня в ОнПарам фильтр - не реагировать если цена прежняя). Я бы отказался от других колбеков, раз они медленные, но получается ОнПарам иногда даёт сбои.

OnParam обновляется срезами (раз в период), а не при изменении. Так было всегда и по другому настроить нельзя.

Цитата
Космонавт написал:
Вопрос 2: у других участников форума тоже OnParam срабатывает первым? Или это зависит от брокера?
Спасибо.
Это ни от чего не зависит, порядок срабатывания колбэков не определен.
 
https://forum.quik.ru/messages/forum10/message5260/topic559/#message5260
Надо делать так, как надо. А как не надо - делать не надо.
 
Сергей, значит есть закономерности, которых Вы не знаете.
Ведь по какой то причине ОнПарам опережает все другие колбеки, хотя и обновляется срезами.

Возможно это как раз зависит от брокера. Мой брокер - например - обновляет Текущую таблицу часто раз в 25 миллисекунд, а другой брокер раз в 100 миллисекунд. Но причина по которой ОнПарам быстрее обезличенных сделок и ДатаСорса по прежнему не ясна.
 
Цитата
Космонавт написал:
Сергей, значит есть закономерности, которых Вы не знаете.
Ведь по какой то причине ОнПарам опережает все другие колбеки, хотя и обновляется срезами.
Весь комплекс QUIK состоит из очень большого количества разных настроек.
Возможно что действительно Ваш брокер что-то у себя подкрутил, а возможно что это просто совпадение.
Но настроек влияющих на приоритет OnParam по сравнению с остальными колбэками не существует.
 
Полагаю, что все общие данные такие как ТВС и ТТП передаются блоками по таймеру.  Но в ТВС помещаются все данные за интервал передачи, а в ТТП лишь данные на момент передачи.
Интервал передачи ТТП меньше чем интервал ТВС, так как ТТП содержит более быстро меняющиеся данные такие как лучшая цена.
Поэтому onParam будет срабатывать чаще.
 
тестирую эти же колбеки на другом брокере - Открытие.
Всё то же самое, но чуть чуть отличается.
ОнПарам по прежнему самый быстрый.
OnAllTrade приходит вторым , но цифра в миллисекундах почти всегда загадочно совпадает с приходом ОнПарам
Вот так:
Цитата
01/10/17 13:10:18,792 APTK пишет OnParam OB 10.31 time_diff=56687
01/10/17 13:10:18,792 APTK пишет OB OnAllTrade 10.31 time=13:10:18 675 675329 time_diff=0
01/10/17 13:10:18,885 APTK пишет OB DataSource 10.31 time_diff=95
редко-редко OnAllTrade приходит с другой цифрой в миллисекундах - на квант позже:
Цитата
01/10/17 12:49:45,674 APTK пишет OnParam OB 10.31 time_diff=288303
01/10/17 12:49:45,690 APTK пишет OB OnAllTrade 10.31 time=12:49:45 485 485692 time_diff=15
01/10/17 12:49:45,690 APTK пишет OB DataSource 10.31 time_diff=0
Ну и колбек ДатаСорс всегда третий. Он самый тормозной у Открытия, но успешно конкурирует (не уступает) с OnAllTrade у предыдущего брокера (НетТрейдер)

Бывает, что всё втроём приходят одновременно (Открытие), но не было случая, чтобы ОнПарам пришёл НЕ первым.
Цитата

01/10/17 13:19:17,807 APTK пишет OnParam OB 10.31 time_diff=8750
01/10/17 13:19:17,807 APTK пишет OB DataSource 10.31 time_diff=0
01/10/17 13:19:17,807 APTK пишет OB OnAllTrade 10.31 time=13:19:17 737 737640 time_diff=0
 
Цитата
Космонавт написал:
тестирую эти же колбеки на другом брокере - Открытие.
Всё то же самое, но чуть чуть отличается.
ОнПарам по прежнему самый быстрый.
OnAllTrade приходит вторым , но цифра в миллисекундах почти всегда загадочно совпадает с приходом ОнПарам
Вот так:
Цитата
01/10/17 13:10:18,792 APTK пишет OnParam OB 10.31 time_diff=56687
01/10/17 13:10:18,792 APTK пишет OB OnAllTrade 10.31 time=13:10:18 675 675329 time_diff=0
01/10/17 13:10:18,885 APTK пишет OB DataSource 10.31 time_diff=95
редко-редко OnAllTrade приходит с другой цифрой в миллисекундах - на квант позже:
Цитата
01/10/17 12:49:45,674 APTK пишет OnParam OB 10.31 time_diff=288303
01/10/17 12:49:45,690 APTK пишет OB OnAllTrade 10.31 time=12:49:45 485 485692 time_diff=15
01/10/17 12:49:45,690 APTK пишет OB DataSource 10.31 time_diff=0
Ну и колбек ДатаСорс всегда третий. Он самый тормозной у Открытия, но успешно конкурирует (не уступает) с OnAllTrade у предыдущего брокера (НетТрейдер)

Бывает, что всё втроём приходят одновременно (Открытие), но не было случая, чтобы ОнПарам пришёл НЕ первым.
Цитата

01/10/17 13:19:17,807 APTK пишет OnParam OB 10.31 time_diff=8750
01/10/17 13:19:17,807 APTK пишет OB DataSource 10.31 time_diff=0
01/10/17 13:19:17,807 APTK пишет OB OnAllTrade 10.31 time=13:19:17 737 737640 time_diff=0
Не знаю как Вы тестируете, но надо делать так:
1) синхронизируете свой комп от атомных часов При этом надо настроить параметры синхронизации и дождаться когда рассинхронизация станет меньше 10 мс.
После этого делаете замеры относительно локального времени компа.
В результате Вы получите задержку времени относительно биржевого, а не относительно сервера брокера.
-----------------------------
2) можно дополнительно использовать rdtsc, чтобы измерить скорость исполнения отдельных функций.
-----------------------
вот тогда Вы увидите много интересного.
например можете увидеть,
что информация с различным временем приходит одновременно.
---------------------------
Повторю еще раз - информация приходит пакетами и в пакете может быть все и onparam и alltrade, а разбор их зависит в том числе и от порядка вызова функций, возможно onparam вызывается перед alltrade.
--------------------------
Но это все мало соответствует реальной задержки данных относительно биржевого времени.
 
Мой скрипт выложен вверху. Кто первый пришел и записался в лог тот и победил.
 
Цитата
Космонавт написал:
Мой скрипт выложен вверху. Кто первый пришел и записался в лог тот и победил.
А Вы внимательно посмотрите на время в ваших логах.
onparam приходит раньше не потому что в нем цена сделки, а потому что в нем цена из стакана.
Т е стакан меняется чаще и раньше чем совершается сделка.
Если время одинаковое то onparam  вызывается перед вызовом других колбеков.
Но оnparam  медленный колбек так как при работе в нем вы вынуждены ходить в хранилище за нужными параметрами.
Поэтому полагаю, что  onparam - это самый затратный колбек.
 
Чтобы узнать, кто пришёл раньше, атомные часы не нужны. Есть такое понятие, как точка отсчёта.
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Чтобы узнать, кто пришёл раньше, атомные часы не нужны. Есть такое понятие, как точка отсчёта.
    Скрытый текст          
По оси х отложено время получения колбэка (в мс) с момента начала отсчёта.
В OnParam - только параметр LAST, никаких стаканОв.
Данные с боевого сервера - незадолго до окончания торгов.
Вас не смущает задержка в 160 мс? Это на сервер в москве!!!
О какой скорости вы тогда говорите?
Это даже не велосипед, а скорее телега какая-то.
---------------------------------
Как Вы узнали что в OnParam нет лучшей цены?
Вы в ТТП отключили все параметры кроме LAST?
 
Цитата
Николай Камынин написал:
Вас не смущает задержка в 160 мс?
Здесь нет задержки. По оси y отложена цена инструмента из пришедшего колбэка.
Что касается задержки, то вы никакими супер-атомными часами не получите время задержки для OnParam в QUIK. Вы ведь не серьёзно про часы-то?  :wink:
Цитата
Николай Камынин написал:
Как Вы узнали что в OnParam нет лучшей цены?
На график в OnParam выведены только изменения по LAST.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Цитата
Николай  Камынин   написал:
Вас не смущает задержка в 160 мс?
Здесь нет задержки. По оси y отложена цена инструмента из пришедшего колбэка.
Что касается задержки, то вы никакими супер-атомными часами не получите время задержки для OnParam в QUIK. Вы ведь не серьёзно про часы-то?  
Цитата
Николай  Камынин   написал:
Как Вы узнали что в OnParam нет лучшей цены?
На график в OnParam выведены только  изменения  по LAST.
Вообще-то я серьезно.
Подобными Вашим измерениями я последний раз лет семь назад.
Суть таких измерений не в том, чтобы выяснить какой колбек быстрее, так как это, говоря образно," ловля блох".
Суть таких измерений в том, чтобы выяснить на сколько запаздывают данные на компе относительно реальных событий на бирже.
Никто не мешает брокеру создать специально задержку данных, поступающих на ваш комп и показывать Вам вчерашний день.
А Вы будете быстро быстро постоянно присылать на биржу с запаздыванием на десятки и сотни миллисекунд при этом радуясь, что делаете это на микросекунды быстрее.
Подумайте над этим.
 
Цитата
Николай Камынин написал:
Никто не мешает брокеру создать специально задержку данных, поступающих на ваш комп и показывать Вам вчерашний день.

Со стороны QUIK нет такой настройки, которая бы позволила внести искусственную задержку.
 
Цитата
Николай Камынин написал:
Вообще-то я серьезно.
OnParam даёт время события с точностью до секунд. Поэтому можете хоть песочными часами время синхронизировать ))
Надо делать так, как надо. А как не надо - делать не надо.
 
Подниму старое.
Сегодня брокер выдал в OnParam по фьючерсу RIZ0 цену последней сделки из прошлого.
В 17.37 цена была одна, а колбек выдал цену где-то на пол часа назад, очень далекую от текущей.


Вопрос: поможет ли как-то время последней сделки в этот же момент в колбеке. Т.е. будет ли время сделки TIME соответствовать тому, что получается из параметра LAST?

Уж очень не хочется переходить на обезличенные, тем более, что там порядок сделок тоже не соблюдается иногда.
 
Полагаю,что есть единственный способ знать как давно была совершена сделка.
------------------
Ранее уже говорил,
что единственный способ не торговать по вчерашним сделкам,
это синхронизация времени компьютера по серверу реального времени или GNSS
и сравнение времени сделки с точным временем.
-----------------
В итоге мы будем всегда знать на сколько запоздала информация о сделке.
Другого способа не существует.
 
когда пытаетесь измерять время исполнения колбеков,
то учитывайте минимальный квант винды для задачи,
либо сначала уменьшите его чтобы.
 
Я не очень понимаю, что Вы так зацепились к этому времени, что в каждой теме призываете его синхронизировать.
Мне не надо измерять реакцию колбека. Мне просто надо узнать диапазон колебания цены за квант времени. Т.е. начал измерять в реальном времени и закончил. Что там было в прошлом не интересует.
Проще всего это сделать с OnParam и колбеком DataSource. Запоминаешь цены, сбрасываешь, когда данные не нужны.

Но если OnParam выдает неактуальные данные, то их надо либо фильтровать, либо не использовать этот колбек. Вот и возникает вопрос фильтрации по времени, если пришли данные из прошлого, то пропустить их.

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

Колбек DataSource самый медленный, возможны пропуски данных.
 
Nikolay, Добрый день!

Если у вас есть сомнение в соответствии цены к времени, то по этому вопросу следует обратиться к Вашему брокеру.

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

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


Но все же, параметры TIME и LAST синхронизированы? Т.е. если мне брокер прислал в колбеке цену по времени пол часа назад, то параметр TIME укажет это?
 
Цитата
Roman Azarov написал:
Nikolay, Добрый день!

Поэтому для таких задач все же рекомендуем рассмотреть вариант работы с таблицей обезличенных сделок, она в этом плане точнее и актуальнее. Биржа гарантирует хронологический порядок записей в данной таблице. Если же наблюдается обратное, это повод обратиться к брокеру, потому что такое поведение некорректно.
Если в таблицу обезличенных сделок добавить классы TQBR и SPBFUT, то можно убедиться, что время не будет монотонным. Внутри класса TQBR -- да, а всё вместе -- нет, т.к. эти классы торгуются в разных биржевых системах.

Я не проверял ещё, что после нововведений на срочном рынке внутри класса SPBFUT время останется монотонным. Возможно, что сейчас это пока так, но сохранится ли это в будущем -- неясно.
 
Вот пример, где 3 класса: фьючерсы, валюта и акции. После столбца времени идёт столбец с микросекундами. Монотонность нарушена.
 
 
_sk_, добрый день!

В случае работы с одним классом, а тем более - с одним инструментом, монотонность времени гарантируется и она есть.
Именно этот случай обсуждался выше.

Разумеется, что если в таблице инструменты с разными режимами торгов  (например срочный и фондовый рынок), то время может идти не синхронно.
 
Nikolay, добрый день!

Повторимся:
Цитата
Параметры TIME и LAST соответствуют одной сделке
 
Цитата
Nikolay написал:
Сегодня брокер выдал в OnParam по фьючерсу RIZ0 цену последней сделки из прошлого.
В 17.37 цена была одна, а колбек выдал цену где-то на пол часа назад, очень далекую от текущей.
Можете подробней? Как это произошло?
Вы только запустили робота и получили старый результат? Или работал себе робот, получал актуальные данные, и тут раз и однократно проскакивает цена из прошлого?
Сам колбек OnParam возвращает только класс и код инструмента, в котором произошли изменения. Каким образом получаете котировку?
Надо делать так, как надо. А как не надо - делать не надо.
 
Да, конечно, OnParam это просто сигнал. Котировка получается через параметр LAST внутри колбека.
Я не добавлял логирование в этом месте, по понятным причинам. Но реакция на значение была отмечена в другом месте.
 
Понятней не стало )) Мож, ваша ошибка, мож, баг квика, мож, кривые ручки брокера...

Цитата
Nikolay написал:
Но все же, параметры TIME и LAST синхронизированы? Т.е. если мне брокер прислал в колбеке цену по времени пол часа назад, то параметр TIME укажет это?
Если ошибка не на вашей стороне, то какие тут могут быть гарантии?
Надо делать так, как надо. А как не надо - делать не надо.
 
Вот я и не знаю. Лога получения нет, пытаюсь смоделировать. Надо ждать сильных движений а рынке, чтобы брокеры нагрузились.
Может и у меня проблема, но эта часть кода уже столько времени работает...

Написал тестовый скрипт, чтобы отловить это. Раз было сказано, что TIME соответствует LAST, то, по идее, время не может стать меньше. Если поймается ошибка, то будет очевидно где проблема.
 
Вот сегодня брокер сбербанк выдал такую цену и время по SRH1:
price = 26588, time = 184459

Это было примерно в такое время 2021-01-29 16:03:01

Возвращаясь к вопросу - это как понять? Почему время, полученное в колбеке OnParam через getParamEx(class_code,  sec_code, 'TIME') - будущее. Хотя, судя по цене, это прошлое. Но т.к. здесь мы имеем только время, то равновероятно прошлое и будущее.

Можно ли утверждать, что время в параметре 'TIME' не может быть больше чем время последней записи getInfoParam('LASTRECORDTIME')?
Хотелось бы верить, что хотя бы это выполняется.
 
Охота вам фигнёй маяться? Имеем:
1. Ваш Квик и ваш брокер справляются с работой вполне удовлетворительно - в противном случае вы бы не работали с этим брокером и/или с этим софтом.
2. А раз так - какого хрена вы пытаетесь всё время что-то там контролировать? Заняться больше нечем?
3. Цена последней сделки в Квике есть ВСЕГДА - даже если отрублена связь. Так ПОВЕРЬТЕ ему, блин, считайте эти данные априори актуальными и достоверными, не занимайтесь хернёй! Я вот вообще за все эти месяцы моей работы с Lua НИ РАЗУ не выводил время. ВААПЩЕ НИ РАЗУ! Есть LAST - какого рожна вам ещё надобно? И никаких коллбеков не использую - тупо считываю последнюю цену ОПРОСОМ! Её обновление - проблемы Квика и брокера, а не мои - смотри пункт первый.
4. Я собираюсь (пока не реализовано из-за идиотской кучи прерываний на одно событие) снимать заявки, если они не срабатывают в течение 5 минут - для этого мне ТОЖЕ не нужны никакие часы сервера или клиента - я и сам в состоянии это посчитать.
5. OnParam не использую и даже не знаю, что это такое. И знать не хочу!
 
Владимир, Вы опять за свое.

Колбек OnOParam здесь используется просто как триггер, не более.

Цена берется последняя из параметра LAST в момент срабатывания колбека. Так что это тоже самое, что делаете Вы.

Но вот незадача, последняя цена кривая. Поэтому время и анализируется, чтобы понять почему она кривая. Иначе просто опрашивая цену,  получаем ту, что была вчера. Ну так отправил брокер.
 
Nikolay, А я опрашиваю эту цену раз в секунду, и насрать мне на все коллбеки! И (может быть, именно поэтому) цена у меня всегда прямая.  :smile:  
 
Так такая ситуация бывает редко. Иначе бы это было явно видно. Просто когда выходит цена из прошлого, то она зачастую гораздо выше(ниже) текущей.
Некоторые алгоритмы анализируют диапазон изменения цены и такие выпады мешают.
 
Nikolay, КАКАЯ "ситуация бывает редко"? У меня цена ВСЕГДА определяется ТОЛЬКО опросом и ТОЛЬКО по LAST. И цена у меня всегда "из настоящего". И все сделки я делаю ТОЛЬКО по ней. И нет проблем!
 
Верну вопрос, т.к. он потерялся за потоком бессмысленных сообщений:

Можно ли утверждать, что время в параметре 'TIME', полученное в колбеке OnParam через getParamEx(class_code,  sec_code, 'TIME')  не может быть больше  чем время последней записи getInfoParam('LASTRECORDTIME')?
 
Опять поднимаю тему.

Сегодня брокер Сбербанк вернул по инструменту GAZP в параметрах
LAST =  287.79
TIME = 122304

Такой цены не было 19 сессий.

Возвращаюсь опять к вопросу: как контролировать корректность|актуальность значений, получаемых через getParamEx?
 
Nikolay, видимо, у вас не проверяется класс инструмента.
Это сделка из класса неполных лотов:
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Nikolay, видимо, у вас не проверяется класс инструмента.
Это сделка из класса неполных лотов:
Да, в этом месте было без проверки. Спасибо.
Страницы: 1
Читают тему
Наверх