Вопрос к программистам QLUA

Nazar Mironov, присоединяюсь к тем, кто посоветовал обойтись штатными возможностями QLUA.

QLUA.chm
Функции для работы с таблицами Рабочего места QUIK, созданных с помощью скриптов на языке LUA.

Аккуратно посмотрите, что можно и чего нельзя. Там хороший набор функций. Мне хватило возможностей и для управления, и для отображения состояния.

Единственно — добавил сохранение и восстановление размеров и положения окна с таблицей.

Nazar Mironov, не разбирался, но у него вижу окошко, которое создано средствами lua. Остается добавить в него поле для ввода, кнопку и обработчик нажатия на кнопку. А у вас лог пишется в какое-то стандартное окно квика. Подозреваю, что совет обойтись средствами qlua — здравый, надо думать, такое решение будет работать стабильнее.

а так, визуальный интерфейс на луа пишется довольно просто, вот простейший пример:

<code>local wx = require 'wx'

local PATH_TO_APPLICATION = [[notepad.exe]]     -- Windows assumed for sake of exemplification

local ans = wx.wxMessageBox( "Should the application be started?", "Hi there!",
    wx.wxOK + wx.wxCANCEL + wx.wxICON_QUESTION )
if ans == wx.wxOK then
    wx.wxExecute( PATH_TO_APPLICATION )
end</code>

stackoverflow.com/questions/18056592/how-can-i-make-an-gui-application-in-lua

Проблема только в том, что гуевина может конфликтовать с квиком, блокировать скрипт, например.

Nazar Mironov, на самом деле Albus тоже похоже стандартными средствами qlua пользуются. А подключение модуля wx тупо может повесить квик. Вон какой у него код, который создает окно:

--создаем таблицу
t_id = AllocTable()
AddColumn (t_id, 0, 'Security',true,QTABLE_STRING_TYPE,10)
AddColumn (t_id, 1, 'Nazvanie', true, QTABLE_STRING_TYPE,15)
AddColumn (t_id, 2, 'Lotov BUY | SELL | Raznitsa %', true, QTABLE_STRING_TYPE,40)
AddColumn (t_id, 4, 'Razmer Begemota', true, QTABLE_STRING_TYPE,22)
AddColumn (t_id, 5, 'Lotov BUY '..best_number, true, QTABLE_STRING_TYPE,20)
AddColumn (t_id, 6, 'Lotov SELL '..best_number, true, QTABLE_STRING_TYPE,20)
AddColumn (t_id, 8, 'Zayavok BUY | SELL | Raznitsa %', true, QTABLE_STRING_TYPE,40)
CreateWindow(t_id)
SetWindowCaption(t_id, «Poisk Begemota»)
InsertRow(t_id, i)

В общем, Вам правильно посоветовали насчет стандартных средств qlua. Удачи!

Viacheslav Merten, Как уже написали выше, VCL — единственный вариант для Вашего случая. Не могу сказать что он простой. да и ограничений немало, но работать можно.
Однако, если Вы понимаете, что существует хотя бы небольшая вероятность увеличения количества одновременно работающих роботов, или значительное увеличение количества обрабатываемых одновременно инструментов, то максимум через годик Вы поймете, что QLua — это тупик.
Настоятельно рекомендую уже сейчас смотреть в сторону C#. Я все это уже прошел, а у Вас есть возможность сэкономить время (как минимум, год).

Prophetic, а как сишарп соединяется с терминалом, есть описание где-то? Наверняка ведь есть, те же стокшарп как-то ведь пишут коннекторы к квику) Или говоря про С# вы не обязательно имеете ввиду стокшарп и использование их коннекторов? У меня у самого нет планов переходить на сишарп, т.к. функционал роботов на С++ написан. Хотелось бы найти некий некривой путь обмена данными с терминалом. Сейчас это скрипт луа, а дальше либо длл, либо длл + сокеты…

tranquility, Я пользуюсь коннектором QUIKSharp.
github.com/finsight/QUIKSharp/issues
Это единственный абсолютно бесплатный проект, с открытым исходным кодом.
На сколько мне известно, ребята из TSLab положили в основу своего коннектора именно этот проект.

Prophetic, посмотрел видео с гитхаба:
www.youtube.com/watch?v=DKkCvKeSFoc
из него понятно, что этот коннектор соединяется с квиком через сокеты по протоколу json. В принципе, это концептуально то же самое что я делаю, только более общо) По скорости мой подход должен быть несколько быстрее, т.к. параметры средствами луа передаются в dll, а не преобразуются внутри луа скрипта в json, а потом уже передаются по тем же сокетам. У меня не передается лишнее, конверсия в числа происходит средствами луа и только тех полей, которые необходимы. К чему это я? К тому, что получается, это то же самое использование qlua, только с переносом исходного кода робота с луа на си шарп. В моем случае — с луа на с++. Кроме бесспорных преимуществ разработки на с#/c++ над lua еще есть какие-то? В чем тупик у qlua, в том, что написав кучу кода, он при определенной сложности робота просто ляжет и будет «неподъемным» для интерпретатором луа, или есть еще что-то, что я не могу понять?

tranquility, Все верно. Вы же в курсе, что любые роботы на QLua работают внутри того же процесса, что и сам квик? Отсюда и ограничения. Прибавьте к этому 32-битность квика (64-бита разрабы пока делать не хотят, если верить их ответам на вопросы пользователей). В общем, когда у меня количество одновременно запущенных роботов превысило 10 (или 15), я понял что жутко тормозить стали не только работы, но и сам квик. Плюс к этому нестабильность кода робота легко могла обрушить весь квик.
В Вашем случае, конечно же никаких дополнительных преимуществ не будет, т.к. по сути Вы делаете то же самое, но для другой среды. На счет скорости ничего вразумительного сказать не смогу. Помню только что автор проекта утверждал, что скорость работы этого коннектора достаточно большая, чтобы не особо задумываться об этом. Мне скорости хватает, но я не работаю ни с тиковыми данными, ни с обезличенными сделками.
Условно (с учетом изменения структуры запуска роботов после перехода на С#), можно сказать, что сейчас у меня одновременно подключены к одному терминалу и работают в общей сложности 58 роботов + 1 служебный на QLua, и остается немалый запас по увеличению количества запускаемых роботов. На QLua я себе такого позволить не смог бы ни при каких обстоятельствах.

Prophetic, понятно. А я сразу ориентировался на работу с тиковыми данными, а потом еще и со стаканом. Поэтому риски того, что все рано или поздно ляжет от сложности меня изначально очень беспокоили. Но использование отдельного процесса и кода на с++ тут как раз дает хороший запас по ресурсам, даже суперкомпьютер пока покупать не надо, старого core i7 с 4 Гб памяти и SSD более чем достаточно))
*Кстати, раз коннектор использует сокеты, робота по идее можно не только в отдельный процесс вынести, но и на отдельную физическую машину. Если это в коннекторе еще не реализовано, это достаточно легко сделать, при необходимости. Если машины соединены проводом и стоят рядом, там пинг какие-то микросекунды будет, т.е. ноль считай.