Визуальный интерфейс VCLua в QUIK (Страница 7 из 11)

Мне удалось добиться стабильной работы, тьфу*3. Помогло - в форме сперва задаем grid-ы, затем уже все кнопки (не наоборот!), не косячим в коде, не допускаем исключений, закрываю вот так

function OnClose()
    is_run = false
    sleep(200)
    settingForm:Free()
    mainForm:Free()
end 
    
    
function OnFormClose(...)
    is_run = false
    sleep(200)
    settingForm:Free()
    mainForm:Free()
end

Версия VCLua от swerg, остальные, что пробовал - криво работают с моими навороченными формами.
swerg, ешё раз спасибо за труды! Я бы предложил вам допилить прежнюю или допилить и скомпилировать последнюю VCLua под Lua5.1, как я понял там нужно затереть указание версии под последнюю Lua, и она начнет запускаться, и за деньги раздавать свою каверверсию. Я бы например 1 тыр заплатил, да и немало таких как я найдется, думаю. )

Как-то интерфейс в 0.5.0 версии заметно изменился.

Например, для Memo для добавления строк было

Memo:Add("Text")

стало

Memo.Lines:Add("Text")

Ну и прочие мелкие приколы, из-за которых то тут, то там - не работают скрипты имеющиеся.
Самое смешное - ранее всё добавлялось в namespace  (так назовём) VCL, то теперь автор изменил на vcl маленькими буквами - опять все не работает!

Приходится во всех скриптах вместо

require "vcl"

заменять на

VCL = require "vcl"

чтобы старые скрипты работали (где было большими буквами написано обращение), например

mainForm = VCL.Form("mainForm")   

Ох и затейник автор!

Добивая всякие мелочи, попутно разбираюсь. Как будет готово - выложу поправленный по-крайней мере для русского языка вариант.

А можно как-то заставить VCLua беспроблемно вызываться из main() потока? Очень уж он (вывод в форму) задерживает колбэки, а соотв. и весь Квик...
luacom ведь не тормозит основной поток..

swerg,
Основной визуальный интерфейс - доска опционов, обычно 50 бумаг. Выводится 25 параметров, итого grid 50х25. Все параметры нужно контролировать, но визуальный контроль время от времени. Строки таблицы обновляются с каждым изменением в стаканах бумаг. Итого в горячую пору могут быть сотни обновлений в секунду.  Недавно додумался поставить выключатель вывода. Постоянно тормозить перестает.
Поскольку, как вы и говорите, работа с vclua из main нежелательна, я сперва сделал всю обработку и вывод графики в колбэке. Получил жуткие тормоза в колбэках и как следствие main (стоит индикатор - вертушка).
Затем перестроил, как и советовали на параллельном форуме - колбэк только снимает срез стакана, бросает инструмент в таблицу-очередь, main читает очередь и каждую итерацию выполняет всю математику, логику, пуляет заявки и бросает инструмент в другую таблицу-очередь на вывод  в vclua. Колбэк теперь, кроме приема среза стаканов, если в очереди что-то есть - отображает.
Добавил таймер на вывод - теперь выводит графику раз в секунду, не чаще. Эту секунду очередь на вывод наполняется. И мне это показалось интересным, ведь vlua не начнет прорисовку, пока колбэк не отработает. И за эту итерацию колбэка мы можем присваивать разные значения одной и той же переменной vclua хоть сколько раз, vclua выведет на экран только последнее значение, когда завершится колбэк.
Жизнь наладилась. В основном индикатор очереди показывает что практически всегда main успевает обсчитать всю очередь. Но вот колбэк периодически подвисает на 1-2 сек, если в очереди на вывод толпа. Это я вижу по индикатору-вертушке main.
Повторюсь, с наличием выключателя вывода это всё стало не критично. Просто думаю, может быть вы или кто подскажет более рациональную схему, раз нельзя вывести vclua в какой-н. третий поток и синхронизировать межпоточный доступ к её переменным. ))
Сейчас вот так:

function main()
  while is_run do
     if #tabchange~=0 then
        --индикация кол-ва в очереди
        local code=table.remove(tabchange,1)   --берем бумагу из очереди на обработку
        -- чтение ТТП 
        -- математика и логика
        -- отправка транзакции
        --table.insert(taboutscreen,code)  --кладем в очередь на вывод
     end
  end
end

function OnQuote(sec, code)
  --читаем срез стаканов
  table.insert(tabchange,code)  --кладем в очередь на обработку
-- === блок вывода в vclua ===--
  if #taboutscreen~=0 then
     local code=table.remove(taboutscreen,,1)
     -- выводим графику из очереди на вывод
  end
end

везде LIFO
Не знаю как ещё оптимизировать...

Подскажите, что за функция Refresh() для объекта Shape? Не могу найти ее описание. Для чего она нужна?

Замучился. Квик падает, если постоянно (в моем случае раз в секунду) менять ширину прямоугольника Shape. Хотел сделать несколько "баров" которые бы во времени меняли свою ширину. Но, поработав некоторое время, квик падает. Такое ощущение что чем выше интенсивность и количество изменяемых баров, тем быстрее упадет. Может минут 10 проработать если не очень интенсивно.
Попытался даже просто присваивать постоянно константную ширину (например 10) в цикле - все равно падает со временем. Если закомментить изменение ширины Shape - все стабильно.

arrStakanV_shapes_B[i].Width = 10; -- Если это закомментить, то проблема исчезает. Массив объектов Shape, из 4 элементов.

Пока работает, ширина меняется, все красиво как надо.

Что делать?

Нет, в main c VCL не работаю. Дело обстоит еще хуже, как оказалось. Потестил подольше. Оказалось она в любом случае падает. Просто в том безопасном варианте, как я думал, она работает дольше. Час проработала - упала. А если Shape.width менять активно, то гораздо быстрее. Чет идет к тому что другую библиотеку брать нужно.
А вы как график гридом рисуете, просто очень мелкую сетку берете?

Да, мелкий размер ячеек.
qvcl действительно стабильнее, да и swerg в нем русский язык наладил.

И не забываем про жесткую выгрузку с версии 6.16., может помочь завершающий sleep в main.

function main() 
while is_run do 
sleep(1) end 
sleep(300) 
end

Подскажите как использовать контрол ListView, на форме он создается, а вот какие методы для добавления Item-в и и колонок не могу понять, все перепробовал, результат "....attempt to call method 'AddColumn' (a nil value)" пробовал и AddColumn, AddNewItem и AddItem.

Вот как раз AddColumn, AddNewItem и AddItem были взяты из исходников

function AddNewItem(L: Plua_State): Integer; cdecl;
var
  lItems: TListItems;
  newItem: TListItem;
begin
  CheckArg(L, 1);
  lItems := TListItems(GetLuaObject(L, 1));
  newItem := lItems.Add;
  lua_pushtable_object(L, newItem, -1);
  Result := 1;
end;

function AddColumn(L: Plua_State): Integer; cdecl;
var
  lColumns: TListColumns;
  newColumn: TListColumn;
begin
  CheckArg(L, 1);
  lColumns := TListColumns(GetLuaObject(L, 1));
  newColumn := lColumns.Add;
  lua_pushtable_object(L, newColumn, -1);
  Result := 1;
end;

function AddItem(L: Plua_State): Integer; cdecl;
var
  lItems: TListItems;
  newItem: TListItem;
begin
  CheckArg(L, 2);
  lItems := TListItems(GetLuaObject(L, 1));
  newItem := TListItem(GetLuaObject(L, 2));
  lItems.AddItem(newItem);
  Result := 0;
end;

Но интерпретатор говорит, что таких методов нет "....attempt to call method 'AddColumn' (a nil value)", в этом то и дело, может есть какие-то подводные камни?

swerg,
StringGrid на форме определяется как контрол Window1 и средствами скриптов AutoIt никак не получается извлечь из грида значения, стоит задача выводить данные из скрипта Lua на форму и считывать их. А вот ListView определяется как SysListView и есть возможность считать данные с формы скриптами, поэтому и пытаюсь разобраться с этим контролом.

swerg,
Спасибо, что попытались помочь, все таки правда будет правильным направление выводить данные допустим в файл, а уже из него читать и принимать решения о дальнейшей работе скрипта AutoIt.