QuikSharp - интерфейс Quik Lua полностью в .NET

Представляю вашему вниманию библиотеку для работы с Quik из C#/F#/.NET — QuikSharp.

Последняя неделя показала, что мне нельзя торговать руками на такой волатильности, и заставила задуматься о более серьезном подходе к автоматизации. В итоге — пока нет доступа к Plaza, Fix и другим нормальным API — я набросал эту библиотеку.

Главная идея библиотеки — всё, что написано в руководстве к Луа работает из .NET без изменений интерфейса. Quik и Lua — недружественная территория по сравнению с .NET, хочется свести их использование к абсолютному минимуму.

Реализован и протестирован механизм обмена данными на основе TCP sockets. Ping/Pong roundtrip с Квиком занимает 190 микросекунд на моем компьютере. Также реализованы сервисные функции и несколько функций обратного вызова.

Установить библиотеку в свой .NET проект можно из NuGet. В проекте будет создана папка lua, из которой нужно запускать в Квике скрипт QuikSharp.lua.

Примеры использования находятся в юнит-тестах здесь.

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

Цель — реализовать и оттестировать 100% из функционала QLUA из руководства. Если найдутся желающие помочь дописать эту библиотеку, пишите здесь а лучше на ГитХабе в Issues.

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

Пользуйтесь на здоровье и следите за обновлениями на ГитХабе! (+ оставляйте отзывы и предложения)

Update (v.0.1.3):

Немного подкрутил и время туда-обратно снизилось с 200 микро- до 60 микросекунд! :)
Добавил еще три простых функции и пару событий. Копипаст шаблона уверенно и легко работает для новых фукнций.

План:
1. Все функции обратного вызова
2. Функции взаимодействия скрипта Lua и Рабочего места QUIK (включая функции для работы со свечами)
3. Функции для заказа стакана (сделано)
...
Самым последним в планах — сделать Функции для работы с таблицами Рабочего места QUIK, так как это слишком специфично для Квика.

quik Lua algo

buybackoff

386

с 29 сентября 2010

67 Комментариев

crazyFakir
21 декабря 2014, 07:27
>>пока нет доступа к Plaza

почему нет? — есть.

и что за дурь делать из говна конфету?
+1
- buybackoff
  21 декабря 2014, 07:34
  crazyFakir, у меня нету
  0
  - crazyFakir
    21 декабря 2014, 08:19
    buybackoff, у всех есть, у него нету.
    
    религия не позволяет?
    -1
    - buybackoff
      21 декабря 2014, 08:23
      crazyFakir, нужды пока нет. есди делать что-то очень быстрое, нужен сервер на М10, иначе законы физики. Мой сервер в Ирландии, оттуда пинг такой, что мне этого решения с Lua хватит надолго. Идея снизить зависимость от Квика до минимума, чтобы потом можно было переехать на любую платформу.
      +2
      - crazyFakir
        21 декабря 2014, 08:39
        buybackoff, www.lua.org/pil/contents.html#P4
        0
        buybackoff
        21 декабря 2014, 08:49
        crazyFakir, единственная причина использовать C/C++ — это писать FPGA для ultra-HFT (мало памяти, счет на микро секунды). Для всего остального .NET/JVM более чем достаточно. Стрелять в ноги себе с C/C++ не хочу. А вы кажется не поняли суть и цель библиотеки, перед тем как писать.
        +1
Алексей Ван <o-s-a.net>
21 декабря 2014, 08:21
Привет.
Идея хорошая. С удовольствием забрал бы в свои проекты по готовности.
Но чесно, не совсем понял зачем тестировать инструкцию по скриптовому языку и переносить функционал ЛУА в .Net. Просто набить руку… Ну или я не так понял просто.
Для олд скул программистов нет нормального и бесплатного Api к Quik. Всё из костылей…
Если бы ты сделал хорошее Api, вроде SmartCom (без косяков только))), с простыми вызовами базовых функций свойственных для Api к бирже(а не какого-то непонятного скриптового языка) тебя бы на руках носили лет десять.
Вот описание Смарт Ком: www.itinvest.ru/software/smartcom/ как стандарт.

Да, и что такое GPL3 — можно будет в коммерческих проектах такую штуку применять или только за бесплатно всё должно быть?
0
- crazyFakir
  21 декабря 2014, 08:36
  Алексей Ван,
  >> Если бы ты сделал хорошее Api, вроде SmartCom
  еше один фантазер.
  ты реально не представляешь что ты говоришь.
  0
  - Алексей Ван <o-s-a.net>
    21 декабря 2014, 08:41
    crazyFakir,
    Ещё один тупой троль, не понимающий о чём речь.
    да. Посмотри мой блог, земеля.
    0
- buybackoff
  21 декабря 2014, 08:39
  Алексей Ван, задача минимизировать контакт с Lua/Quik и работать с классом .NET. Издержки на сокет минимальны, к тому же я использую мультиплекс и async/await. Учитывая родную latency Квика дополнительная 0.1 мс мне кажется незаметной. В перспективе наверняка будет не Квик, а что-то быстрое с хорошей API, поэтому весь функционал лучше делать в .NET с прицелом на переезд и использованием абстракций поверх имплементации. Идеология близка к StockSharp, если бы Stock# был с открытым кодом, я бы не писал свое (мне не нужно 90% из S#, только коннектор).
  
  Кусок кода лежал с прошлого года, «набить руку» тоже имело место :)
  
  GPL требует публикации изменений, если изменения поставляются ползователям. Для частного использования нет ограничений.
  0
- buybackoff
  21 декабря 2014, 08:54
  Алексей Ван, если вдруг нужна другая лицензия, всегда можно договориться. Только покажите мне тех, кто пишел коммерческое ПО, завязанное на Квик, кроме авторов Квика!? :)
  0
Алексей Ван <o-s-a.net>
21 декабря 2014, 08:35
да… и по твоей ссылке всё на не понятном иностранном языке. Что такое? Квик за пределами этой страны вроде не используют))
0
- buybackoff
  21 декабря 2014, 08:40
  Алексей Ван, все на английском в коде, потому что меня бесит пестоянно переключать на английский с русского и наоборот чтобы написать Квик, ЕБИТДА, Луа и прочие термины. Для программирования и финансов английский — родной. А мне особо без разницы + практика письма. На вопросы могу отвечать на русском.
  +1
  - Алексей Ван <o-s-a.net>
    21 декабря 2014, 10:01
    buybackoff, У меня есть короче подключение к SmartCom (обёртка для их Api) и Quik(DDe(закрытое лицензией)+Trans2Quik) свои + к стокшарп сделал порт на прошлой неделе (это закрытая лицензия конечно). Все подключения доступны из одного класса контроллера. Очень удобно. Подключаешь к проекту, цепляешь на этот контроллер робота/привод и можно выбирать прям из одного места, к какому порту перекинуть соединение. Без лазанья в коде. С менюшкой простой.
    Свободное из всего этого только SmartCom. Но каркас с архитектурой уже понятны хотябы.
    Менюшка переключения соединения и мой привод:
    
    Была тоже давно идея сделать открытое Api для подключения к куче бирж, но забросил эту идею давно. Да и на тот момент мало практики было.
    Короче не теряйся. Open Source жив. ГовноКомментаторов не слушай.
    Надо подумать, может вместе попробовать что-нить делать.
    0
    - buybackoff
      21 декабря 2014, 10:11
      Алексей Ван, мне как раз не хватает пока времени и идей сделать универсальную модель объектов / API. Типа как S#, но мне она местами не очень нравится и она закрытая. Или типа OpenGamma. Когда есть интерфейсы для портфеля, сделки, ордера, и т.д. И всё open source.
      0
ace-fltrade
21 декабря 2014, 10:28
Хотел на праздниках писать коннектор к квику, похоже задача упростилась… Будем тестировать. Думаю смогу вклад в проект внести. Какой самый удобный для тебя формат обратной связи ( куда писать?)
0
- buybackoff
  21 декабря 2014, 10:32
  ace-fltrade, github pull requests & issues — самый удобный способ для публичного обсуждения кода. если что-то личное то тут в личку или я везде с этим ником
  0
П М
21 декабря 2014, 10:45
пользуясь случаем, пропиарю и свою поделку
On-Line получение данных из Quik в Java и не только
для доступа к Lua используется named pipe
скорость на реальном счете
18 миллисекунд — подключение к Lua (createpipe), затем 1 миллисекунда на каждый запрос (получение свечей, статуса соединения с сервером, времени сервера, стакана по любому инструменту)
Код на github рабочий как Proof Of Concept, но я с тех пор внёс несколько изменений для улучшения стабильности. Как нибудь выложу и их тоже.

Код состоит из части на Lua (server) и Java. Вместо Java можно использовать C# или любой другой язык с доступом к WinAPI, в том чиcле через FFI прокси.
+1
- buybackoff
  21 декабря 2014, 10:54
  ПBМ, видел и даже скопировал Ваш код для изучения и дальнейшего интегрирования (благо Apache 2!). ffi и pipes слишком сложно по сравнению с сокетами, а так в целом подход почти одинаковый. У меня он более универсальный и гибкий (extensible).
  0
  - П М
    21 декабря 2014, 11:34
    buybackoff, насчёт более универсальный и гибкий, чем докажешь? :)
    художника легко обидеть.
    уж не знаю чем привязка к С# универсальнее и гибче.
    а скрипт на Lua легко дописать.
    не нашел у тебя в примерах получение свечей или стаканов. поэтому сложно оценить разницу.
    если ты про то что к Soсket можно подключиться удалённо, то я специально сделал Named Pipe локальным. Паранойя, знаешь ли.
    
    кстати я запушил только что последние изменения к себе.
    0
    - buybackoff
      21 декабря 2014, 11:38
      ПBМ, у меня пока только proof of concept с минимальной реализаций (сейчас пишу остальные функции и события). А гибкий значит очень легко добавлять функционал на основе этого шаблона с обеих сторон — Луа и c#
      0
      - П М
        21 декабря 2014, 11:54
        buybackoff, т.е. пока ничего нет. ясно. ну, у меня-то уже всё написано.
        по поводу гибкости — последним коммитом добавил получение немедленного слепка стакана.
        до этого было ожидание, пока стакан изменится, чтобы получить свежую информацию, теперь два варианта.
        всё для гибкости и универсальности.
        больше не отвлекаю. пост плюсанул.
        
        0
        buybackoff
        21 декабря 2014, 12:00
        ПBМ, Ваш файл лежит в моем репо с самого начала и ждет, чтобы его разобрали и использовали лучшие практики из него :) Можно сказать Ваш пост во многом спровоцировал меня обновить и довести до ума мою старую идею.
        
        0
buybackoff
21 декабря 2014, 13:50
Немного подкрутил и время туда-обратно снизилось с 200 микро до 60 микросекунд! :)
Добавил еще три простых функции и пару событий. Копипаст шаблона уверенно и легко работает для новых фукнций
+1
SL
21 декабря 2014, 18:15
Здравствуйте, я пока так ничего и не понял как этим воспользоватся, как например подписаться на получение всех сделок или стакана? Нужна какая то хотя бы минимальная документация, что б можно было что то потестировать.
Спасибо.
0
- buybackoff
  21 декабря 2014, 18:25
  SL, из кода должно быть все понятно. Сегодня я выложил только шаблон proof of concept с некоторыми примерами. Еше не все функции реализованы. Вы можете добавить пропущенные функции сами по примеру существующих и присоединиться таким образом к разработке, или подождать. Основные функции я добавлю на следующей неделе.
  
  План (по QLUA.chm):
  1. Все функции обратного вызова
  2. Функции взаимодействия скрипта Lua и Рабочего места QUIK (включая функции для работы со свечами)
  3. Функции для заказа стакана
  ...
  Самым последним в планах — сделать Функции для работы с таблицами Рабочего места QUIK, так как это слишком специфично для Квика.
  +1
Ilya
21 декабря 2014, 18:42
Вечер добрый, buybackoff!
Можно ваш контакт скайп или маил в случае вопросов работы с интерфейсом?
Недавно сам тоже приступил к реализации своего проекта и очень понравился вариант от ПВМ, так как в моем проекте необходимо делать выгрузку данных ленты принтов с последующей ее обработкой и выводом на график в сам Quik. Pipe подошел в данном случае из-за универсальности обмена в обе стороны. Единственное прийдется переписать QAPI от ПВМ, так как на .NET у меня Pipe сервер, а скрипт для выгрузки и скрипт индикатора будут подсоединяться как клиенты.
Ваш вариант тоже интересен на будущее.
С уважением,
0
- buybackoff
  21 декабря 2014, 18:52
  Ilya, вопросы/контакты на ГитХабе или тут. Я сначала тоже делал Квик клиентом, но очень нестабильно и Квик выдавал ошибки при попытках переподключения. Когда Квик сервер — всё очень стабильно и надежно.
  
  Sockets не менее универсальны для обмена данными в обе стороны (full duplex) и я как раз это использую. У меня реализован multiplexing — вызов функции со стороны C# не блокирует канал, а создает Task, в течение обработки которого по каналу можно послать новые сообщения и принять результаты для уже созданных Tasks. Балгодаря этому производительность повышается в 3 раза по сравнению с блокирующим request/response. 60 микросекунд в обе стороны — это практически предел для железа.
  0
Ilya
21 декабря 2014, 18:59
buybackoff, хотябы маил (на GitHub маила не увидел), в личку здесь я не могу писать, рейтинга не хватает)))
0
- buybackoff
  21 декабря 2014, 19:17
  Ilya, код публичный и обсуждение тоже публичный :)
  0
  - П М
    21 декабря 2014, 22:48
    buybackoff, в порядке дружеской колкости, у тебя в коде вижу ты время измеряешь в миллисекундах
    Console.WriteLine(«MultiPing takes msecs: » + sw.ElapsedMilliseconds);
    а в посте пишешь про микросекунды (10^-3 и 10^-6)
    что на самом деле в результатах-то? микро или милли?
    BTW, выставление заявки, я позавчера наконец проверил точно, через Trans2Quik.dll занимает ОТ 57 миллисекунд. За это время она успевает дойти до биржи, зарегаться там и в программу приходит ответ. От отправки до ответа — 57 миллисекунд. (Сервер естественно не у брокера) Так что сильно ускоряться смысла нет, imho. Quik хорош для дней, часов, ну, мб минут, но на тиках надо уже брать что-то пошустрее, так что скорость важна постольку, поскольку.
    
    0
    - buybackoff
      21 декабря 2014, 22:55
      ПBМ, В тестах я 10 раз гоняю 10000 сообщений, чтобы получить в среднем 600 миллисекунд на 2-10 раунды (когда JIT двигатель прогревается и фаервол успокаивается) — устраивает такая математика?
      
      Скорость важна в моем случае, чтобы полностью переместить процессинг данных из Квика в .NET. События типа AllTrade идут потоком и на каждое событие добавится 30 микросекунд в одну сторону + время на сериализацию. 57000 по сравнению с 60 — мне кажется можно не париться об этих 60 и даже о сериализации…
      0
      - П М
        21 декабря 2014, 23:17
        buybackoff, можно попробовать заявки отправлять через Lua, может у тебя будет быстрее. Но думаю порядка 50 миллисекунд всё равно будет на заявку уходить.
        
        а так удачи, не обижайся. про микросекунды теперь понятно. мой вариант действительно однопоточный и однонаправленный. это его недостаток. если имеется большой массив клиентов и постоянный поток в обе стороны, то конечно лучше замерять среднее время и твой способ должен быть гораздо быстрее.
        я не стал с этим заморачиваться по той причине, что не хотелось слишком сильно залезать в потоковую модель Quik Lua — как там происходит синхронизация данных, освобождение ресурсов и так далее. поэтому только 1 поток, 1 клиент.
        
        сериализацией точно можно принебречь. если ты только не десяти КБ гонять собираешься
        0
        buybackoff
        21 декабря 2014, 23:24
        ПBМ, В Квике у Луа только два потока — главный, в котором мы обрабатываем request/response loop, и поток с функциями обратного вызова, которые у меня посылают данные независимо от главного цикла request/response. Больше потоков и не нужно, так как потоки внутри Луа которая внутри Квика… — это как игла в яйце, яйцо в сундуке… Нафиг нафиг :)
        
        При наличии 4-х процессоров: 1 на info.exe, 1 на функцию main, 1 поделенный на GUI и функции обратного вызова, и 1 остается на .NET. В самый раз!
        +1
        П М
        21 декабря 2014, 23:34
        buybackoff, ну, а если многопоточно обращаться к Lua с запросами ответами..
        на каждого клиента нужен поток.
        или там просто очереди на вход и выход и 1 поток клиента 1 сервера? если с очередями, то хорошо получится, но не сильно маштабируемо, т.е. скорость высокой не будет.
        хотя некоторый выигрыш будет в двунаправленной неблокирующей обработке.
        я может быть тоже про неё прочитаю, должно получиться и с pipe.
        спасибо за наводку :)
        0
        buybackoff
        21 декабря 2014, 23:51
        ПBМ, очереди на стороне .NET (явным образом созданная для отправки сообщений, и неявная через TPL/async/await при получении сообщений). Главное не блокировать канал, и задача Луа сводится к тому, чтобы максимально быстро получить и отправить данные.
        
        Есть такой проект StackExchange.Redis — там сделано по примерно такому же принципу мультиплекса, и это самый быстрый клиент для.НЕТ. Используются Correlation Ids сообщений при отправке и при получении — мы отправляем сообщение и на время забываем о нем, а когда приходит ответ — по ИД находим кому его отправлять. Используя Tasks, нам не нужно много потоков, thread pool & TPL & async/await все делают за нас (сочувствую java прогерам, что у них нет этих ништяков :) )
        
        Кстати я пока писал это понял, что есть логическая ошибка в коде — нужно обрабатывать полученное из Луа сообщение в новом Task, иначе мы не получаем новые сообщения пока ждем обработки полученного.
        
        спасибо за наводку :)
        0
        buybackoff
        22 декабря 2014, 02:50
        ПBМ, еще нашлось 30% производительности после фикса.
        
        Добавил спецификацию транзакции — самое сложное, что в этой библиотеке вообще есть. Класс с 71 полями. Эхо пустой транзакции со всеми полями занимает 225 микросекунд (включает сериализацию — сокет — десериализацию — сериализацию — сокет — десериализацию). Если игнорировать пустые поля, то снова прекрасные 75 микросекунд. Компьютеры шустры в наши дни!
        
        Сейчас самое важное проверить функцию sendTransaction в боевом режиме.
        0
buybackoff
22 декабря 2014, 14:33
Уже работают OnAllTrades, OnQuote(сразу возвращает стакан), и sendTransaction(еще не тестировал на реальном счету) — то есть уже смело можно пользоваться для получения данных и начинать тестировать заявки.
+1
- SL
  22 декабря 2014, 18:02
  Это события изменения стакана и всех сделок или функции для получения таких?
  0
  - buybackoff
    22 декабря 2014, 18:03
    SL, события и подписка. OnQuote сразу возвращает стакан в C#, поэтому не нужно еще раз вызывать функцию getQuoteLevel2
    +1
wyg
19 января 2015, 11:08
"… мне как раз не хватает пока времени и идей сделать универсальную модель объектов / API.
Типа как S#, но мне она местами не очень нравится и она закрытая. Или типа OpenGamma.
Когда есть интерфейсы для портфеля, сделки, ордера, и т.д. И всё open source." buybackoff

Возможно есть смысл полюбопытсвовать здесь:
bitbucket.org/SazanProject
на библиотеку эту (исходники C# под SmartCom) наткнулся здесь на этом портале,
автор smart-lab.ru/my/SergeyEgorov/blog/all/
виде по использованию библиотеки
www.youtube.com/user/codetraidingsystem/playlists
0
Valeriy
02 февраля 2015, 19:39
У меня карма не достаточная для личного сообщения, оставлю тут

Хотел попробовать использовать твою библиотеку для квика. Взял из нугета.
пытаюсь загрузить скрипт lua. Quik выдает ошибку
error loading module 'socket.core' from file '...\lua\clibs\socket\core.dll':

Не найден указанный модуль.

Библиотека по этому пути есть

0
- buybackoff
  06 февраля 2015, 16:35
  Valeriy, ответил на ГитХабе не знаю Вам или еще кому-то github.com/buybackoff/QuikSharp/issues/2
  
  Я тестирвоал на двух Квиках, но на одной машине — не могу удаленно сказать в чем дело. С загрузкой библиотек по относительному пути из Квика были проблемы, но все решилось используя функцию ЛуаКвика, которая выдает абсолютный путь к скрипту, от которого строится относительный. Меня смущают три точки, должно быть две. Это полное сообщение об ошибе, или обрезанное?
  
  0
  - Valeriy
    06 февраля 2015, 23:19
    buybackoff, я натравил Dependency Walker на библиотеку core.dll
    Dependency Walker, показал не найденую зависимость API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL. я не знаю что это за библиотека
    
    >>Это полное сообщение об ошибе, или обрезанное?
    Это полное сообщение.
    
    >>Вам или еще кому-то
    Не мне :)
    0
dav
02 сентября 2015, 15:16
проект развивается?
0
buybackoff
02 сентября 2015, 15:19
поддерживается. пока от квика не нужен был дополнительный функционал к тому, что уже сделано. но то, что есть — работает и используется.
+1
dork
24 сентября 2015, 14:07
Спасибо, друг! По описанию это то, что я искал. Будем смотреть. Хотел уже named pipes делать поднимать в qlua… Как прогер я слабоват, но шлю лучи поддержки и плюсики в профиль.
0
dork
24 сентября 2015, 19:26
У меня 1300 мсек в среднем со 2го по 10 раунды в тестах. Что сделать чтобы было 600?
0
- buybackoff
  24 сентября 2015, 19:42
  dork, Ну если вам 130 МИКРОсекунд медленно, попробуйте обновить железо :) Как я понимаю, речь идет о том, что печает тест для 10000 запусков в тесте MultiPingFast?
  +1
  - dork
    24 сентября 2015, 21:07
    buybackoff, сначала я запускал проект Profiler. А MultiPingFast действительно печатает 600. Спасибо. Буду изучать дальше.
    0
2:5020/1164
26 сентября 2015, 02:21
+++ (силы нет, поэтому ставлю тут). Респект автору. Вопрос: 3-4 опционных серии (SI, RI) потянет на получение рилтайм-котировок? (бид/аск/объем/время)? Всего тикеров 200 требуется.
0
- buybackoff
  26 сентября 2015, 11:59
  Eno, на обработку монстра — структуры транзакции с 70 полями, КвикШарп тратит 100 микросекунд (там вроде есть тест, который замеряет скорость). На 200 таких структур нужно 20 миллисекунд. Котировки гораздо легче, чем транзакции. При этом, КШ обрабатыват полученные данные параллельно, делите на число свободных процессоров. Учитывая, что латентность Квика больше 150 миллисекунд и там есть ограничения на объем данных, КШ хватит на гораздо большее, чем способен отдать Квик.
  0
  - 2:5020/1164
    02 октября 2015, 13:30
    buybackoff, работает отлично, читаю котировки 4-х опционных досок. Спасибо за решение. Ощущение большей простоты и надежности, чем SmartCOM. А об универсальности и говорить не приходится.
    0
    - buybackoff
      02 октября 2015, 21:57
      Eno, шлите pull requests если что. Я уже к Транзаку написал коннектор с нуля на такой же инфраструктуре, но не могу его пока выложить. К Плазе потихоньку подбираюсь )
      0
      - buybackoff
        02 октября 2015, 21:58
        buybackoff, то есть на такой же архитектуре, а не инфраструктуре.
        0
Prophetic
02 октября 2015, 21:21
Господа, кто-нибудь из местных пробовал создавать Windows Form-приложение с подключением данной библиотеки?
Уже неделю мучаюсь. С консольным проблем нет, а в WindowsForm
строка типа _quik = new Quik();
не отрабатывает.
Попытка отследить точку проблемы через отладчик, привела к исключению Esent (что-то типа: база данных должна быть дефрагментирована или удалена)
Глубже нифига понять не смог.

Познания в C# неглубокие. Может кто-нибудь подсказать как ПРАВИЛЬНО создать простейшее WindowsForm- приложение, чтобы эта библиотека в нем работала?
0
- buybackoff
  02 октября 2015, 21:54
  Prophetic, попробуйте в другом потоке, не в потоке окна. Сам с формами не работаю, но коллега было прикрутил к формам.
  0
  - Prophetic
    02 октября 2015, 23:53
    buybackoff, еще бы знать как это делается...
    Но за идею спасибо, буду изучать.
    Кстати, Вы были правы на счет того, что студия глючит с путями к пакетам. Ручное отключения связей с ними, и последующее их восстановление решило проблему желтых восклицательных знаков.
    0
    - buybackoff
      03 октября 2015, 00:34
      Prophetic, это Вы были на гитхабе? Пишите там по техническим вопросам.
      0
      - Prophetic
        03 октября 2015, 11:46
        buybackoff, Да, это был я. Но боюсь, что это не столько технический вопрос, сколько недостаток знаний в моей голове. Поэтому и не стал на гитхабе этот вопрос задавать.
        0
- 2:5020/1164
  10 октября 2015, 01:13
  Prophetic, да, было такое) Но быстро понял в чем дело и ушел на консоль. Если получится решить задачу на WinFormz, отпишитесь пожалуйста, интересно. У меня этот проект лишь как драйвер большой БД котировок опционов, поэтому работает — да и ладно.
  0
  - Prophetic
    10 октября 2015, 13:25
    2:5020/1164, данную проблему решил. Правда, сам до конца не понял как. Очень долго танцевал с бубном (читай экспериментировал) и в какой-то момент все заработало. Остальная информация по моим изысканиям есть на гитхабе
    0
Dmitriy
29 октября 2015, 21:15
Подскажите, пожалуйста, как начать использовать QuikSharp? Я подключил его через nuget к проекту, но что дальше?
как хотя бы запустить тест ping?
0
Алимат Мирзо
25 сентября 2016, 18:53
Девелоперские платформы с API можно взять здесь (если кому-либо интересно): http://getanyplatform.com
0
Иван Ру
23 марта 2018, 23:15
Опыт в теме у меня небольшой, возможно что-то делаю нет. Не получается.
C...QuikSharp.csproj: error: пространством имен XML по умолчанию для этого проекта должно быть пространством имен MSBuild XML. Если проект создан в формате MSBuild 2003, добавьте xmlns=«schemas.microsoft.com/developer/msbuild/2003» в элемент <Project>. Если проект был создан в старом формате 1.0 или 1.2, преобразуйте его в формат MSBuild 2003. C:\Users\LOOD\Documents\Visual Studio 2015\Projects\QUIKSharp-master\src\QuikSharp\QuikSharp.csproj

После попытки сборки выдает около 200 ошибок. В основном — связанных с пространством имен.
0
- buybackoff
  23 марта 2018, 23:37
  Иван Ру, поддерживается только Visual Studio 2017. Ошибки с упоминанием MSBuild говорят, что вам нужно обновится. Это бесплатно :)
  0