Просьба добавить возможность изменять количество линий индикатора при изменении настроек. Например, добавить возможность возвращать новое количество линий как результат выполнения OnChangeSettings ()
Старатель написал: Может лучше попросить дать возможность задавать количество дополнительных линий через диалог? С одним общим набором свойств: типа линии, толщины, цвета.
Общие для всех линий свойства и сейчас можно запросить и задать в OnChangeSettings (хотя изменять параметры линий я OnChangeSettings, теоретезирую, но запросить точно можно). Так что и это есть уже.
На самом деле проблема именно в долгом открывании диалога при большом количестве линий, так бы и фик бы в ними. Но т.к. просить ускорить открытие диалога очевидно бесполезно, я и предлагаю такой вот метод, который отлично исправит проблему долгого открытия диалога без ущерба функциональности (для случая, когда параметры линий через диалог задавать в самом деле не требуется).
Есть ли возможность в момент добавления самописного Lua-индикатора на график заставить систему спросить параметры индикаторы до его добавления? Сейчас выглядит так, что индикатор сначала обязательно безусловно добавляется на график, и только этого после можно открыть редактирование параметров. Не всегда можно приемлемые параметры установить в скрипте заранее.
Бывают индикаторы, где приходится для выразительности выводить 100...200 и более линий. Очевидно, что параметры этих линий задаются в скрипте автоматически и пользователь точно не будет их изменять руками через диалог.
Однако, если открыть диалог редактирования параметров такого индикатора - то диалог открывается долго, т.к. свойства всех линий в него запихиваются. но там эти линии не нужны! не будет их пользователь править!
Предлагаю в таблицу Settings добавить свойство, что-то наподобии Settings.DisableLinesEdit = true / false -- по умолчанию false
Если это свойство true - то параметры линий в диалоге вовсе не отображать, далог тогда будет открываться быстрее Если это свойство false или не задано (по умолчанию) - то параметры линий в диалоге отображать как сейчас.
Anton написал: Забегу-таки вперед паровоза. Без второго потока пользовательский мейн вообще нельзя было бы выполнить от слова никак. Были бы только колбеки, как в индикаторах.
На мой взгляд, задумка оказалась неудачной. У разработчиков, очевидно, была необходимость сделать замену QPILE с его раз в секунду выполнением, причем в отдельном потоке. Для чего и была сделана main(). Но дальше началась мутная каша.
На мой взгляд, надо было сделать две категории скриптов Lua (помимо индикаторов): 1) Чисто событийный скрипт. С нем могут быть только обработчики событий. Срабатывает что-либо в нём только по событиям, в одном потоке (не обязательно основном, но в одном). Для особо скучающих добавить еще периодическое настраиваемое событие таймера, что просто. 2) Скрипт, выполняющий бесконечный цикл исключительно в отдельном потоке. Но опять же только в одном потоке, пусть и отдельном. Это будет просто полноценная замена QPile и радость любителям постоянно что-то колбась без остановки.
А вот замешивание в одну кашу двухпоточности в рамках одного скрипта лишь добавляет слишком сложных глюков, при этом постоянно получая кашу в анных, да еще и залезая в дедлоки порой. Никакой пользы при этом это не приносит совершенно, считаю.
Вы документацию уже прочитали про индикаторы? Впрочем, изменять количество линий через параметры индикатора - нельзя, количество линий одноразово определяется значением, возвращаемым из Init() Единственный трюк - это вернуть из Init() достаточно большое заранее достаточное количество, при этом фактически назначать значение только нужному в данный момент количеству линий, остальным линиям возвращать nil, тогда они не будут рисоваться.
На любой график добавляем метку вида "Картинка из файла". (Может с другими типами тоже есть проблема, проверял только на этом типе меток) Выбираем какую-нибудь картинку в параметры. Задаем руками точное значение "Цена"
Метка установилась.
Мышкой на вертикальной оси "тянем вверх", увеличивая масштаб графика.
Встаем на метку, "Редактировать" Почему значение "Цена" изменилось?! Мы же руками его явно задали??
Если значение "Цена" восстановить руками и снова поизменять масштаб вертикальной оси - то значение "Цена" в параметрах метки снова уплывет (и метка сместится на новое значение) Как так?!
Удивительная программа QUIK В какой бы функционал не залез - там обязательно сразу наткнёшься на прорву багов и недоработок, причем гугление пофоруму (я к тому, что по остальным проблемам с графиками, на которые наткнулся, я уже нашел соотв. тему на форуме)
Константин написал: Но все равно остается костыль в виде разбора Lua массивов и т.д.
Сделайте один раз свою обёртку, разбирающую все это - и пользуйтесь на здоровье. Очевидно же, что это ваше пожелание реализовано не будет до 2050 года, смысл тогда желать?
Константин написал: Так же как и с Lua, сделать возможным написания своих программ для QUIK на этих языках. Возможные варианты подключения exe, или dll своих программ. Если допустим при использовании dll то чтоб QUIK вызывал функции OnInit, OnStart, OnDeinit и т.д., и т.п. в зависимости от того скрипт написан, или индикатор.
Конечно данное обновление потребует время. Но даст возможность отказаться от кастрированного Lua. И избавит от танцев с подключением к нему DLL. Конечно сейчас можно подключаться через костыль в виде lua5.X.lib/dll. Но все-же это костыль, который ограничивает некоторые возможности обмена данными.
В чем костыль? И какие такие "новые возможности обмена" предоставит вам другой язык? вы о чем? У "другого языка" будет ровно такое же весьма ограниченное API. И что для вас это изменит? Ну вот в самом деле?
Lua-интерфейс позволяет делать свои какие угодно DLL.А trans2quik и вывод информации через DDE позволяет делать свои exe. Что ж еще требуется-то??
Деньги брокеру платятся. С него и требовать есть смысл. Удивительно как ловко брокера отпинывают пользователей "это QUIK" и пользователю почему-то покорно идут на форум квика. Ну и смысл? Очевидно же, что в проблемах СМС разобраться может только брокер, т.к. это все у него хозяйство настроено. Но брокер ловкий.
Anton написал: Я тоже сейчас посмотрел внутрь (скачал сорцы у swerg) и есть подозрения, что работать эти функции не будут через w32. Например, PeekMessage
Код
long lwnd = MYP2HCAST luaL_optinteger( L, 1 , 0 ); // раз косяк
lua_pushnumber( L, ( long) msg.hwnd); // два косяк
lua_pushnumber( L, msg.wParam); // три косяк
lua_pushnumber( L, msg.lParam); // четыре косяк
На 64 битах HWND это void *, WPARAM и LPARAM - uintptr_t и intptr_t соответственно. Тут их режут до 32 бит и потом еще в даблы упихивают.
Часть функций после появления Int64 для Lua в QUIK я поправил (PostMessage, SendMessage), функции типа PeekMessage мне не нужны, их и не правил пока.
Ноги у либы растут из Lua 5.1 и x86, очевидно, и видимо автору хватало lua_number (который, как известно, в зависимости от сборки Lua может быть int или double; в QUIK это было double). Для Lua5.1 на x64 в этих функциях по уму надо был переходить на user data, чтобы не терять ничего, но после появления нормального int64 в Lua5.3 в QUIK надобность в этих извращениях, по счастью, отпала.
Anton написал: Дайте угадаю, в мейне есть вызов какой-то сишной функции? Так-то, если в нем один луа-цикл без никто, мейн лок захватит и все, квик на первом же колбеке встанет колом, о чем тут и сообщают.
Не надо ничего угадывать. Я взял буквально тот скрипт, который здесь был приведён. Вот полный текст:
Код
function OnStop ()
is_run = false
end
function main ()
is_run = true
a = 0
while is_run do
a = a + 1
end
end
Едрёна-батона... А я еще подумывал сменить комп на поновее-получше. Неужто опять враньё с этими ядрами/гигагерцами?!
Запустил скрипт этот с бесконечным цикл на своем Intel Pentium E2180 2ГГц, два ядра, прошу заменить. 2Гб оперативы. Да, проц грузится на 50%, это понятно, но QUIK совершенно без задержек реагирует на мышь, графики едут, к северу подключаюсь / отключаюсь, таблички сделок моргают, рукописные Lua-индикаторы работают. Неужели у вас на указанном железе в самом деле висит?! Определённо обманываете.
Anton написал: одно ядро полностью будет занято, это скорей теоретическая возможность, чем то, что надо делать. Даже слип(0) уже получше будет, поток будет сниматься и вставать в конец очереди, давая прочим потокам тоже ядро поюзать. Но тоже из области поиграть с этим.
Мы таки про прозвучавшие в вопросе минимальные задержки говорим или просто рассуждаем?
BlaZed написал: Другими словами, конструкция без слипа, типа такой
Код
function main ()
a = 0
is_run = true
while is_run do
a = a + 1
end
end
может легко повешать квик.
Нет. Если процессор одноядерный - да, это будет заметно в скорости общей работы. Если процессор многоядерный (а это нынче стандарт де-факто) - то никто ничего даже не заметит, кроме термометра на процессоре.
Михаил Филимонов написал: Это колонка в таблице "Клиентский портфель"
С точки зрения программирования на Lua и, тем более, событий, надо опираться на другие, базовые таблицы. Из информации которых формируются уже "Клиентский портфель" и "Таблица состояния счета".
Для срочного рынка:
Ограничения по клиентским счетам --> OnFuturesLimitChange
Позиции по клиентским счетам --> OnFuturesClientHolding
Для рынка ценных бумаг и валютного рынка:
Таблица лимитов по денежным средствам --> OnMoneyLimit
Михаил Филимонов написал: Я же уже писал, что торгую на Един. Бр. Счете, а изменение средств (свободных) для этого типа счета видны только в таблице "Состояние счета" и "Клиентский портфель"
Михаил Филимонов написал: Ответ (здесь на форуме) Романа Азарова (сотрудник Арка )
""Ликвидная стоимость" и "Прибыль дня" являются параметрами таблицы " Состояние счета ". Доступ к параметрам данной таблицы с помощью Lua не представляется возможным."
Вот и все, приехали
Зачем она вам?? "Ликвидная стоимость" - это остаток по деньгам (из лимита по денежным средствам, оно же получается через getMoneyEx), вероятно минус заблокированное из того же источника.
При этом на картинке в исходном посте вы выделили совсем другой параметр. Вы напишите толком что требуется - может и будет ответ предметный, а так скакать между табличками и параметрами - толку не будет. Большинство параметров, которые отображаются в "Состоянии счета", доступны или напрямую в других таблицах (и доступны из Lua), или легко вычисляются на основании других таблиц. По сути "Состояние счета" - это просто агрегированная информация из разных таблиц QUIK.
Отнюдь. Это в самом деле стандартное поведение контрола Windows "Вкладки". Просто в QUIK в здравом уме никто не делает столько вкладок, чтобы они в одну строку не помещались. Потому ваша проблема "уникальна". А значит быстро чинить её никто не будет. Даже если "рассмотрят и признают целесообразным". Сократите наименование на вкладках - и будет вам счастье. Более того, вы ведь этак придете и скажете, что QUIK есть слишком много ресурсов при 5 открытых графиках. А на самом деле у вас 100 вкладок по 5 графиков, а это уж совсем другое, согласитесь.