Prophetic
Prophetic личный блог
26 декабря 2016, 12:09

Предновогоднее обновление QuikSharp

Хочу поделиться новостью о предновогоднем обновлении библиотеки QuikSharp.

Обновление привнесло ряд новых функций, а также демонстрационное приложение на WinForm, о котором так часто просили пользователи.

Берем тут: https://github.com/finsight/QuikSharp

QuikSharp — это динамически подключаемая библиотека, для обеспечения связи ваших роботов, написанных на C#, с терминалом Quik.

QuikSharp — это «Open source-проект», который развивается благодаря участию других пользователей. Отдельный «респект» хочу выразить автору проекта, т.к. это именно то, что я долго искал когда понял, что уперся в некоторые существенные ограничения QLua.
Легче всего с этой библиотекой будет освоиться тем, что уже пробовал реализовать свои торговые стратегии на QLua, т.к. большинство функций взяты именно из QLua. Но по сравнению с QLua, мы получаем значительно большие возможности, в том числе по производительности. Когда у меня количество одновременно запущенных роботов на QLua превысило десяток, то я столкнулся с очень большими проблемами производительности. Квик стал жрать память в каких-то неимоверных объемах, а загрузка ЦП выросла до 80% (в спокойное время). Перейдя на QuikSharp (правда, перед этим пришлось заняться изучением C#) я одномоментно решил большинство проблем производительности, получил удобный инструмент для создания пользовательских интерфейсов, а также более удобное средство разработки самих роботов. Сейчас у меня одновременно крутятся в реальном времени более 4-х десятков роботов (если считать отдельным роботом сочетание ТС и конкретного инструмента), и при этом я не испытываю НИКАКИХ проблем с производительностью (терминал и роботы крутятся на ноутбуке).

Чтобы начать пользоваться данной библиотекой, необходимо скачать проект по указанной ранее ссылке и скомпилировать его (рекомендую использовать Visual Studio не ниже 2015).
После этого, из папки «bin» необходимо скопировать папку «lua» со всем ее содержимым, туда, где у вас обычно лежат роботы на QLua.
В терминале Квик в диалоговом окне «Lua скрипты...», необходимо добавить файл QuikSharp.lua из ранее скопированной папки «lua» и запустить этот скрипт.
Возможно, потребуется сначала установить LuaForWindows.
Далее, в папке «Examples\QuikSharpDemo\bin\Release» находим exe`шник, и запускаем его. Остальное должно быть понятно интуитивно.
Данная демка не является роботом, а лишь демонстрирует простейшие примеры работы с библиотекой, что в сочетании с открытостью исходников, позволяет без особого труда научиться использовать эту библиотеку в своих целях.
Возможно, позже будет реализован и какой-нибудь простейший робот, в качестве наглядного примера (может я сделаю, а может кто-нибудь еще)
94 Комментария
  • Евгений
    26 декабря 2016, 12:25
    Вы наступили на горло Осе. Так держать. Конкуренция это хорошо. 
    • Евгений Черных
      26 декабря 2016, 13:54
      Евгений, Подобные проекты погибают смертью храбрых, поскольку есть LUA. С его выходом кофите, сток шарп, осы и подобное суть бестолковая вещь
      • Евгений
        26 декабря 2016, 13:57
        kbrobot.ru, бестолковая вещь — это вы. Потому что кбробот шарлатан и обманщик.
  • Евгений
    26 декабря 2016, 13:19
    Оса появилась неделю назад.

    Мне ваши оба проекты нравятся. А только за то, чтобы вы лучше делали.

    Оса сырая и непонятная. Может ваш проект (проект, в который вы вносите посильный вклад) подстегнет коллег сделать человеческое.
      • Евгений
        26 декабря 2016, 17:39
        Prophetic, а вы смотрели в сторону транзака или плазы? Там так же Си. Попробуйте, может это лучше будет для вас, чем доделывать проект чужой.
          • Евгений
            26 декабря 2016, 18:29
            Prophetic, как на ваш взгляд проекты Тс лаб, стокшарп, питон? Чем они могут не подходить в торговле?
              • Евгений
                27 декабря 2016, 09:38
                Prophetic, если робота отдельно, то стокшарп или питон. Тс лабе все внутри, что плохо, соглашусь. Тыкание в кубики влияет на живую торговлю.
                  • Евгений
                    27 декабря 2016, 11:11
                    Prophetic, стокшарп позиционирует себя как бесплатный проект. Там есть платные вещи как Плаза, но с Квиком он бесплатен. С другой стороны, вам самому Плаза не интересна. Лично мне от стокшарп интересен только тестер.

                    Питон более популярен среди трейдеров. Си больше среди программистов. Вы программист или трейдер? :-)
                      • Евгений
                        27 декабря 2016, 12:44
                        Prophetic, любую стратегию, запущенную на живых деньгах, можно протестировать. Ваш же мозг позволяет их закодировать. Позволит и протестировать.

                        Мое мнение, вы сильно обеспокоены экзекьюшеном и кодированием, чем поиском альфы. И это плохо. Но это ваше решение, и к чему оно приведет будет известно только вам.
                    • buybackoff
                      29 декабря 2016, 17:59
                      Евгений, серьезно!? Питон!? :) Это же дико медленная штука, которую можно наверное эффективно использовать для бэктеста с момощью Pandas/NumPy/etc (batch processing), но можно даже не надеятся создать систему в реальном времени, где будет крутиться много стратегий (GIL, дико неудобная concurrency story по сравнению с .NET). Придется переписывать код для запуска в продакшн.
                      • Евгений
                        30 декабря 2016, 09:05
                        buybackoff, вы наивно полагаете, что Lua Quik и еще с десяток прокладок от брокера будет быстрым решением.

                        Быстрые решения делаются совершенно не так.
                        • buybackoff
                          30 декабря 2016, 12:20
                          Евгений, расскажите же как! Я очень НЕ наивно написал здесь несколько раз обратное про QS, но вы наверное не читали.
                • ch5oh
                  27 декабря 2016, 23:43
                  Евгений, для «тыкания кубиков» делается копия скрипта. Например, в торговле версия 5, а модификация идет в версии 7.
                  • Евгений
                    28 декабря 2016, 10:52
                    ch5oh, сам подход достаточно пагубный. Роботы должны быть отдельно (причем без всякой шелухи, только прямое подключение к брокеру), а тестирование отдельно в программе.
  • Сергей Гаврилов
    26 декабря 2016, 13:39
    Lua — это маленький и элегантный язык… Для тех, кто уже знает какой-либо язык изучить Lua -дело нескольких дней… Мне, например, lua сильно понравился..., но писать на чистом lua большие проекты не есть комильфо… Кстати луа, даже его автором позиционируется как «клей» — промежуточный слой, который помогает связывать некую систему с более мощным языком…
    • Пафос Респектыч
      26 декабря 2016, 16:23
      Сергей Гаврилов, а у Lua же наверное есть сетевая библиотека? Тогда сам скрипт может просто общаться с бэк-эндом через сокет, отправляя данные и получая инструкции, какие ордера выставлять-снимать и статус. А сам бэк-энд пиши на чём хочешь. У меня так робот в MT5 работает, сам советник чисто как прокся.
      • ch5oh
        26 декабря 2016, 21:53
        Zweroboi, Этот проект так и сделан.
  • ch5oh
    26 декабря 2016, 14:57

    Луа сам по себе легкое порно, а "Луа внутри Квик" — уже хардкор.


    Авторам библиотеки QuikSharp хотелось бы пожелать больше тестировать её на нормальных боевых задачах.При нормальном потоке тиковых данных.

      • ch5oh
        26 декабря 2016, 15:51

        Prophetic, =) разумеется, я это проделал. И тесты производительности и всё прочее. Очень сыро. Видно, что именно на серьёзных промышленных задачах эту либу мало используют.

         

        И ещё Вы путаете "производительность отдельной операции в одном синтетическом тесте" и "общую стабильность связки под нагрузкой".

        • vito333
          26 декабря 2016, 17:47
          ch5oh, какие результаты тестов? можно подробнее? годится таки или нет?
        • buybackoff
          29 декабря 2016, 11:25
          ch5oh, это глупо даже пытаться претендовать, что для тиков и HFT стоит использовать QS. Хотя, даже по Ри/Си тиков не так много по сравнению с заявками, миллион за 8 часов — это всего 34 в секунду. Главный вопрос латентности — от QS до квика это всего 60 микросекунда, но от Квика до сервера брокера и от него до биржи — сотни миллисекунд. Если нужны тики, то Plaza/Twime/Fix, QuikSharp же создавался как самый простой интерфейс поверх Луа, там специально нет и не будет какого-то дополнительного функционала, как тестирование стратегий и т.п. Но то, что есть — просто, открыто, быстро и удобно!
          • PavelS
            29 декабря 2016, 14:25
            buybackoff, Ведь тики это стандартный функионал Квика, почему же нельзя на них претендовать? На ХФТ через квик я думаю никто и не претендует, для этого действительно есть Плаза и тд, речь про стабильность работы под нагрузкой... 60 микросекунд это скорость при пустом сообщении, но чем больше данных мы вкладываем в передаваемое сообщение тем медленнее оно работает.
            • buybackoff
              29 декабря 2016, 14:37
              PavelS, я уверен, что QS сам по себе не добавляет серьезной нагрузки, а сериализация и сокеты — как есть, это не мой код, а встроенный стек и JSON.NET. Быстрее уже не получится, если приходится работать с JSON и гонять данные через прослойку Луа. У меня Квик сам по себе обычно жрет много ресурсов, когда открыта таблица всех сделок и много стаканов. С тиками QS легко справится, только зачем это нужно, если реагировать на них можно с задержкой почти полсекунды!? Можно извращаться и использовать LuaJit, Jil вместо JSON.NET, thread-safe cjson всместо dkjson. Но все это упрется в медленность Квика и цепочки до биржи через брокера. Цель QS — дзен простота для быстрого прототипирования и работы со стратегиями, для которых секуда задержки не важна. Не получится сделать быстрее, чем Луа, если эта прослойка присутствует, и я не уверен, что те стратегии, о которых Вы пишете, работают супер быстро в Луа. Кстати, QS удобен и в связке с Plaza, так как позволяет получить данные об инструментах, состоянии счета и т.д., многих таких данных нет в основном потоке Плазы. А для рынка акций мега скорость не так важна, даже по Сберу не так много сделок.
              • PavelS
                29 декабря 2016, 15:05
                buybackoff, Про медленность квика и цепочки до биржи через брокера речь не идет, тут все понятно. Про какие либо стратегии тоже речи нет. Как раз проблема (не постоянная, но достаточно частая) в том что я фиксирую время когда луа дал ответ и когда этот ответ пришел в робота, и так как приходится иногда одновременно работать с десятками заявок, то бывает такое: Отправка заявки и выполнение ее квиком 0.2 млс, получение колбека OnTransReply на прослойке Луа и отправка в квикшарп 64 млс, а получение квикшарпом 800 млс.

                В Plaza2 CGate все эти данные есть.
                • buybackoff
                  29 декабря 2016, 15:18
                  PavelS, если там идет большой поток, то все сообщения выстраиваются в очередь, может поэтому. Вообще 800 млс я бы рассматривал как баг, интересно подробнее узнать про ситацию. Может быть это stop-the-world GC, по умолчанию GC на десктопе не в concurrent режиме. Как минимум нужно добавить array pool для JSON.NET, эта возможность появилась в 9-й версии, а также изменить настройки GC на server concurrent.
                  • PavelS
                    29 декабря 2016, 15:39
                    buybackoff, В дополнение вот например куск моего лога с нагрузкой.
                    (в скобках это время ответа луа, до скобок время получения этого ответа в C#)



                    • buybackoff
                      29 декабря 2016, 15:42
                      PavelS, насколько часто повторяются такие паузы? Это похоже на GC, на Ваш взгляд?
                      • PavelS
                        29 декабря 2016, 15:53
                        buybackoff, Видите как прыгает время ответа, большую часть времени цифры до скобок и в них либо одинаковые либо отличаются на 1 млс. Таких ситуаций процентов 5-10.
                        Похоже или нет к сожалению не знаю, не могу понять где это происходит. Но идею Вы дали, буду пробовать, разбираться. Но врятли сделаю это быстрее Вас.
                        • buybackoff
                          29 декабря 2016, 15:57
                          PavelS, в идеале бы запустить perfview при реальной нагрузке и посмотреть статистику github.com/Microsoft/perfview
                        • buybackoff
                          29 декабря 2016, 16:18
                          PavelS, я внес изменения, которые должны существенно снизить GC. Не тестировал и в ближайшее время не смогу. Попробуйте обновить и проверить есть ли еще длинные паузы.
                          • PavelS
                            29 декабря 2016, 18:04
                            buybackoff, Запустил, пока все работает нормально, посмотрим.
                    • buybackoff
                      18 января 2017, 23:00
                      PavelS, скажите, есть ли в итоге заметное улучшение после изменений?
                      • PavelS
                        18 января 2017, 23:55
                        buybackoff, Да, стало лучше, правда я снизил нагрузку, сейчас запущено мало роботов. Но все равно подобные ситуации повторяются. Один раз было прямо очень плохо, задержки дошли до 50 секунд, но наверное это не в библиотеке, не знаю, перезапуск все вылечил, больше такого не повторялось. 
                        • buybackoff
                          19 января 2017, 00:09

                          PavelS, 50 секунд даже Питон наверное висеть не будет, вероятно дело не (только) в GC — так долго мусор не может собираться при любом раскладе. Учитывая, что вся библиотека — это по сути TCP сокет + (де)сериализация, не могу с ходу придумать где я что-то еще мог пропустить. Рад слышать, что стало лучше — надеюсь Вам не показалось :)

                          Пишите, пожалуйста, на ГитХаб все такие проблемы, если они будут повторятся — мы их поправим!

                • buybackoff
                  29 декабря 2016, 15:22
                  PavelS, добавил issue, если есть возможность, опишите подробнее где именно сообщение зависает на так долго
                  github.com/finsight/QuikSharp/issues/89#issue-197999438
                  • PavelS
                    29 декабря 2016, 15:44
                    buybackoff, Это не только транзакции, но и OnOrder. В OnTrade не знаю, его не замеряю.
              • PavelS
                25 мая 2017, 14:18
                buybackoff, Добрый день! Вернулся к вопросу подвисания потоков...
                Подвисает все в QuikService, поток callbackTask. А конкретно вот тут: var lineOrCancelledTask = await Task.WhenAny(readLineTask, _cancelledTcs.Task).ConfigureAwait(false);
                Подвисает не постоянно в среднем на 2-5 секунд, но может доходить до нескольких минут.
                Подскажите почему такое может происходить, как можно это исправить?
                • buybackoff
                  26 мая 2017, 05:19
                  PavelS, видимо он ждет ответа от readLineTask, который читает колбэки с сокета. Если посмотрите выше, то там идет напрямую вызов StreamReader(NetworkStream()).ReadLineAsync(), что является кодом .NET. То есть проблема может быть только в том, что пакеты не приходят, что в свою очередь может быть вызвано неполадками на стороне Квика. В коде QuikService я не вижу возможных проблем в этом случае.

                  Было бы неплохо сделать логирование на стороне Lua и в этом месте и посмотреть, где именно зависает. То есть если Lua скрипт вызывает нужный метод вовремя, то нужно разбираться в сокетах. Иначе проблема может быть в самом Квике или к коде Луа. Скажите, пакеты все в итоге приходят или некоторые теряются?
                  • PavelS
                    26 мая 2017, 09:19
                    buybackoff, Бывает что позиции резко разошлись с квиком, как будто в какой то момент не пришли колбеки со сделками. 
                    Сильно подвисать начинает после одного-двух дней непрерывной работы, колбеки начинают тормозить на 2-5 минут каждый, тоесть если это началось, то так и будет работать пока не перезагрузишь. При этом примерно в 7 раз возрастает объем используемой опер.памяти и нагрузка на ЦП.  Квик при этом часто тоже подвисает.
                    • buybackoff
                      26 мая 2017, 09:38
                      PavelS, а какой процесс есть много памяти и если QUIK#, то не делали profiling? Несколько дней непрерывной работы — звучит амбициозно :) Когда еще руками использовал Квик перезагружал хотя бы раз в день… За несколько дней может накопиться много мусора в разных местах, я вообще ничего не могу сказать о такой ситуации удаленно. Есть такая удобная штука: https://github.com/Microsoft/perfview, она позволяет профилировать уже запущенный процесс (dotTrace/dotMemory тоже, но они платные; второенный в VS профайлер не позволяет присоединиться к запущенному процессу). Когда в следующий раз начнутся проблемы со скорость и памятью, можете запустить и посмотреть что съедает память?
                      • PavelS
                        26 мая 2017, 10:25
                        buybackoff, Память начинает жрать сам робот, не quik. Profiling не делал. Когда все это происходит, то перезагружаю только робота, quik не трогаю, он месяцами работает без перезапуска. Если при появлении этих тормозов подвисал и quik, то при закрытии робота quik сразу восстанавливается.
                        • buybackoff
                          26 мая 2017, 11:06
                          PavelS, тогда точно профайлинг поможет. Я еще ни разу не делал полноценный нагрузочный тест и публично не раз тут писал, что Q# создан для удобства, а не для замены Плазы/FIX, поэтому я в свое время остановился на том, что он «вполне достаточно» быстр… Без профайлинга не понять в чем причина — в Q# или в коде робота.
                        • buybackoff
                          26 мая 2017, 12:10

                          PavelS, есть одна мысль — вы случайно не используете блокирующие методы слишком часто? (по сравнению с асинхронными). Есть такая тема как ThreadPool starvation: https://stackoverflow.com/questions/7600774/threadpool-not-starting-new-thread-instantly. Когда все потоки ThreadPool заняты, то пул ждет одну секунду перед тем, как добавить новый поток. Если у вас в коде много блокирующих методов, то потоки в пуле могут закончится и пул будет ждать секунду. При этом если есть очередь из тасков, то последний может ждать довольно долго.

                          Q# асинхронный, проверье не используете ли Вы везде Task.Result или Task.Wait() вместо await...

                           

                          • PavelS
                            26 мая 2017, 12:59
                            buybackoff, Resut использую только в запросах к квику, например: classCode = _quik.Class.GetSecurityClass(«SPBFUT», secCode).Result;

                            и таких запросов около 10 на весь код, 6 из них работают в цикле в отдельном потоке с паузой 10 мс (это загрузка параметров по инструментам и стаканов, а также графиков). 4 это отправка транзакций например res = _quik.Orders.CreateOrder(order_new).Result;

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


                            • buybackoff
                              26 мая 2017, 13:18
                              PavelS, тогда надо думать. То, что Квик тормозит когда тормозит робот, но отвисает после перезапуска робота, может говорить о том, что Квик пихает в сокет данные, но буффер сокета переполнен по какой-то причине — читатель не успевает все считать. Попробуйте еще без WhenAny() если не используете CancellationToken, где-то недавно в issues CoreFx видел репорт о баге с утечкой памяти где-то там WhenAny/WhenAll.
                              • PavelS
                                26 мая 2017, 13:39
                                buybackoff, Сейчас вообще убрал var lineOrCancelledTask = await Task.WhenAny(readLineTask, cancelledTcs.Task).ConfigureAwait(false);
                                if (lineOrCancelledTask == _cancelledTcs.Task) { break; }

                                Что делает этот код, зачем он нужен?
                                Второй день работаю без него, пока все нормально. Только начали наблюдаться задержки 2-10 сек в строке var readLineTask = reader.ReadLineAsync(); но не так часто.
                                • buybackoff
                                  26 мая 2017, 14:10
                                  PavelS, это поддержка отмены операции, так как асинхронные методы сокетов не поддерживают CancellationToken.
          • PavelS
            29 декабря 2016, 14:37
            buybackoff, Подскажите, не могу понять для чего Вы делаете цикл в цикле (в потоках отправки, приема и колбек) например:




            • buybackoff
              29 декабря 2016, 14:39
              PavelS, внешний цикл — это реконнект. Мы в него выходим из внутреннего только после IOException.
  • PavelS
    26 декабря 2016, 18:26
    А что нового в библиотеке? Просто дописали реализацию недостающих функций из QLua?
      • PavelS
        27 декабря 2016, 11:28
        Prophetic, С графиками работаете? Как грузите?
          • PavelS
            27 декабря 2016, 13:53
            Prophetic, Сколько времени займет получение всего графика, например М1? В предыдущих версиях получение около 3000 свечей (примерно столько дает квик) занимало от 3 до 6 секунд (это очень долго). Причем в цепочке Сериализация-сокет-десериализация-луа-сериализация-сокет-десериализация обработка команды самим ЛУА и выдача им результата занимает 0,5 милисекунды. Вот в этом проблема. Библиотека не справляется с потоком больших пакетов. Может уже исправлено? Кстати в ваших примерах ошибки, чтобы скомпилировать пришлось дорабатывать.
          • PavelS
            27 декабря 2016, 14:01
            Prophetic, Я давно пользуюсь этой библиотекой, правда от нее осталась только идея, все остальное переписано, добавлена логика работы с плазой и метатрейдером, но проблема с большим потоком данных при работе с квиком все равно осталась. У меня крутится около ста роботов и у каждого в управлении по 4 заявки и если ко всему этому добавить например колбеки стакана и обезличенных сделок, то начинаются большие задержки, периодически получить транзакцию занимает несколько секунд.
            • buybackoff
              29 декабря 2016, 11:30
              PavelS, пулл реквесты принимаются, всегда можно исправить что вас не устраивает. Большие потоки данных и Квик как-то плохо сочетаются в принципе… Библиотека сосдавалась в первую очередь для простоты, хотя по скорости она оптимальна в текущей архитектуре и отпрофилирована.
          • PavelS
            27 декабря 2016, 14:04
            Prophetic, Получение различных параметров пришлось объединить в небольшие пакеты, получилось на 2 милисекунды быстрее чнм все их получать по отдельности, как это делаете Вы.
              • PavelS
                27 декабря 2016, 14:52
                Prophetic, 1. Это понятно что полная загрузка происходит один раз, у меня так же. Если для Вас скорость работы не критична это не значит что и всем тоже, надо развивать проект...
                2. Пишу с телефона, поэтому не могу точно указать на ошибку. Но если примерно то Вы пытаетесь получить некоторые поля таблици, которые не описаны в библиотеке квикшарп. И еще так как нет скомпилированной библиотеке квик шарп, то слетают ссылки в Вашем демо, пришлось собирать библиотеку, и заново указывать ссылки
                  • PavelS
                    27 декабря 2016, 18:21
                    Prophetic, У меня Ваш Демо зависает на этапе подключения.
              • PavelS
                27 декабря 2016, 14:55
                Prophetic, У меня к сожалению тоже не хватает знаний что бы докапаться до проблемы. Уже давно с ней мучаюсь, так как для меня скорость обмена данными очень важна. Например грузим в отдельном потоке параметры инструментов. 50 инструментов по 20 параметров, на каждый запрос уходит около 0.5 млс итого 500 млс, а квик обновляет данные с интервалом 30 млс и пока мы грузим один раз все инструменты параметры могут уже несколько раз поменяться
                  • PavelS
                    27 декабря 2016, 18:29
                    Prophetic, Нет, я не гружу все параметры, только необходимые мне.
                    OnParam не пользуюсь, не получается сделать это без проблем, с этим колбеком приходит код и клас инструмента по которому были изменения, что Вы с ними делаете дальше? Если я обращаюсь обратно к квику за параметрами по данный бумаге (из этого же потока или из другого, не важно), то очень скоро поток который обращается к квику зависнет.
  • ch5oh
    26 декабря 2016, 21:53
     Да, что нового добавили?
      • PavelS
        27 декабря 2016, 19:26
        Prophetic, А Вы выставляете заявки и контролируете их выставление так же как в Демо примере?
          • PavelS
            28 декабря 2016, 09:43
            Prophetic, Тоесть колбеками  OnTransReply, OnOrder и OnTrade не пользуетесь, а все время проверяете в цикле через запросы в квик?
  • pantov
    28 декабря 2016, 12:35
    Пример зависает на Подключаемся к терминалу Quik...
    запущен или нет QuikSharp.lua  значения не имеет.
    Чтото-не так с дллками, трудно понять.
    Может подскажете, что где проверить?
    Спасибо.
    • PavelS
      29 декабря 2016, 10:49
      pantov, Если у Вас к библиотеке квикшарп подключена Newtonsoft.Json версии 9.01, то скорее всего из за нее, откатите на 8.03. У квик шарпа есть проблемы с более новыми версиями Json. Еще есть проблемы с колбеками, в частности с Events.OnConnectedToQuikCall(_responsePort) в QuikService.cs, из за него падает поток.

      Еще есть проблемы с сепаратором в Demo. 
        • PavelS
          29 декабря 2016, 12:37
          Prophetic, Ну у меня так получается. Если взять Ваш проект по ссылке, то со свежим Json он выдает исключение, откатываю на 8.03, данная проблема исчезает.
          По колбеку ошибка не постоянная, но ловил ее уже несколько раз.

          А по сепаратору, Вы насильно даете ему "," а если у кого нибудь в региональных стандартах разделитель стоит "." то будет исключение. 
          Поэтому если уж так нужно менять разделитель то лучше заменить System.Globalization.CultureInfo.CurrentCulture.NumberFormat.CurrencyDecimalSeparator[0];

          на System.Globalization.CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator[0]; тогда он берет его из локальных региональных настроек

            • PavelS
              29 декабря 2016, 13:05
              Prophetic, на русской версии виндовс Ваша команда берет то что принято стандартом для России, а у нас это ","
              Это я опытным путем вычислил)) у меня виндовс с русской локализацией а разделитель стоит точка и эта команда выдает все равно запятую.
      • buybackoff
        29 декабря 2016, 11:35
        PavelS, создайте плиз Issue на ГХ, если проблема повторяется.

Активные форумы
Что сейчас обсуждают

Старый дизайн
Старый
дизайн