тот самый (Все сообщения пользователя)

что мешает Вам самим написать аналоги стандартных индикаторов на qlua и использовать получившиеся функции к имеющимся у вас источникам данных? вам даже не придётся открывать для этого графики и строить индикаторы.

какая существует очередность при вызове колбеков и обработки user-кода (пользовательских скриптов)

к пример: OnAllTrades. Как вы забиндили у себя этот коллбек? как он у вас вызывается, в каком цикле, как работает/приостанавливается работа основного скрипта пользователя. если можно, как указал выше - напишите в "псевдокоде".

Михаил, не будем разводить тут "писанину" на 100 страниц - просто приведите если не затруднит в псевдо-коде" тот кусочек кода, который отвечает у вас за вызов и работу коллбеков. остальное, попытаюсь "додумать" сам...

но ведь вы же как-то периодических вызываете с помощью своих колбеков функции из user-кода?

значит ли это, что Вы в qlua переопределили стандартные макросы lua_lock/lua_unlock с пустышек на критические секции или, что/то в этом духе? и если да - то и нам можно теперь ими пользоваться?

я просто пока не могу понять, как скрипт прерывается при приходе очередного колбека (без всяких майнов и прочего). вот и всё. если у вас нет ответа на мой - я постараюсь найти его сам. но это очень прискорбно, что я не могу найти ответа на такой, казалось бы простой вопрос тут.

имеется ввиду не весь скрипт, а строчка из него, конечно

ну замечательно...

попытаюсь "ответить" за вас:
обычно, из примеров кода "из интернетов" - делают, что-то такое:

подозреваю, что возможно у коллбеков своё отличное от другой части скрипта состояние (дочернее). а с вашей стороны уже идёт в qlua учитывание всего этого (мы сейчас не про синхронизацию, про само переключение)

то есть, вопрос, по сути, можно развернуть так:
есть петля в теле скрипта (без майн), есть коллбеки. на время коллбеков петля в скрипте прерывается и идёт обработка коллбека. как?

в рамках реализации вызова require из основного тела скрипта (не из майн) - всё работает в одном потоке.

ну вот, опять main. я же говорю, что колбеки и петля в библиотеки работают независимо и псевдопараллельно. вопрос: как?

я сейчас про майн вообще молчу. с пётлёй в библиотеке скрипт не останавливается и без всякого майна.

вы не ответили.

как у вас происходит/реализовано программно прерывание работы скрипта на время обработки кода из коллбека?

Михаил, я уже объяснил вполне доступно: есть стандартный message loop в библиотеке, есть код в коллбеках - и то и то вполне себе параллельно работают. как? напрашивается ответ, что на время прихода коллбеках идёт переключение работы кода на них, а потом возобновление работы кода из message loop библиотеки. и причём, без потоков и корутин.

а в ответ - тишина...

чот не понял. в смысле.

насчёт вариантов реализации - то тут не особо много вариантов. если только не делать на стороне квика wathchdog по предельному времени работы колбека.

на самом деле, как Вы наверно поняли - я про vclua. там есть message loop, есть одна "мега"-оконная функция, которая ретранслирует по надобности сообщения другим контролам. вот и интересует механизм прерывания этой петли на время прихода колбека.

в) как происходит/реализован механизм переключения между прерыванием работы кода из подключенной библиотеки на момент прихода коллбека?

Такая ситуация:
1. имеем некую внешнюю C-библиотеку подключенную через "require". В ней создаётся объект и в "вечном" цикле идёт работа с его свойствами/методами.
2. в основном скрипте есть коллбеки в которых идёт своя работа
3. также, в основном скрипте есть код, который не находится в коллбеках и в "майне".
---------------------
а теперь, вопросы:
а)правильно ли я понимаю порядок выполнения этой программы:
Сначала выполняется п.3, потом, п.1. если есть/приходит колбек то, выполнение п.1 приостанавливается на время обработки коллбека и далее возобновляется?
б) если сделать "вечный" цикл в одном из коллбеков - то, работа "другого вечного цикла в библиотеке" приостановится на неопределённое время?

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

а потом для другой программы опять лезть в реестр?

p.s. вот у меня экран: 1920x1080, спрашивается, как я его увеличу на 125%? Он у меня и так на пределе.

флуд

ну в других же программах нет такого?

у них этот косяк - давно. можно попробовать по менять разрешение экрана.

если окно настроек диаграммы - то, никак.

нет, только руками.

ни тупайл ни qlua на данный момент САМИ не открывают графики и не строят.  Только таблицы. На qlua можно только задать функцию обработки расчёта свечек (что в принципе и делает OnCalculate в скриптах индикатора). Разработчикам уже не раз говорили на полную убогость данной ситуации. То, что Вы просите - реализовано у них в платном функционале системы серверных плагинов. Но разработчики пока не открыли для нас этот интерфейс, т.к. они сами пишут и продают плагины.

полагаю, всем нас...ть

если память не изменяет - в Windows для этого есть комбинация клавиш: Ctrl+"колесо мыши"

немного дополним:

а активная вкладка в данном случае - будет аналогом для нас "QForm" - контейнера для наших контролов

Например, так:

Отсюда, имеем: QControls - базовый класс для всех визуальных контролов, которые нам так сильно нужны. Либо, давайте нам хендл окна вкладок квика, относительно которого мы будем отталкиваться, строя сами окна-контролы.
Далее, каждый скрипт имеет базовым: класс QScript

Сейчас же, Вы заставляете нас, по сути, писать свою реализацию vcl (не путать с qvclua или vclua), хотя просто могли сделать её общедоступной. Чтоб нам стабильно использовать ту "vclua", которая гуляет в интернете - надо переписать дельфовую или лазаровскую vcl (lcl). Что весьма нетривиально, т.к. придётся отказываться от многих корневых классов и переписывать их, т.к. они заточены на взаимодействие с приложением и от него они отталкиваются, а не с плагином.

попробуйте взять qchart.dll из той версии с которой всё работало из папки "backup" квика.

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

в следующий раз - используйте спойлер для длинных (по высоте, да и не только) сообщений. его для этого и придумали.

он опять в лирику вдарился - так что, это бывает:)))

а плагин qchart.dll включен? и если "да" то, какая версия.
qchart.dll отвечает за рисование графиков в квике.

Вычисление: Параметры настройки:

1. «Количество периодов» - изменение количества периодов i усреднения МА, по умолчанию = 13.
2. «Метод» - метод расчета МА (Simple, Exponential, Vol.Adjusted, Smoothed), по умолчанию используется метод «Exponential»,
3. «Поле цены» - используемое значение цены интервала PRICE (Open, High, Low, Close, Median, Typical), по умолчанию принимается «Close».
   

это не пасхалка - просто сейчас интеграция lua в quik находится на зачаточном уровне - поэтому даже сами разработчики далеко не всё знают.

касаемо всего остального и многопоточной работы и Ваших выводов по этой теме, могу только сказать, что Вы похоже совсем не читали мной приведённый выше форум: quik2dde.ru
Там, как-раз многое детально изучено и выявлено того, чего до сих-пор нет в документации.

в QLUA используется 5.1.5. Придётся и её тогда обновлять:))

То, что она вышла 9 лет назад не делает её старой.

да без проблем. удачи:)

http://help.qlua.org/ch4_5.htm
http://help.qlua.org/ch4_5_16.htm
об этом можно узнать из таблиц текущих параметров.

остальные функции доступны в библиотеке QL.lua. Информация о ней, тут: http://forum.qlua.org/forum4.html

-------------------------------------------------------------------------
Вам в следующий раз нужно более конкретно задавать вопрос, а то, получается аж целую ветку на это потратили:)))))))

если бы разработчики писали, да ещё составили бы нормальный хелп то и форумаэтого не было б.

если вы про то, что нужно узнать какие бумаги доступны для лонга/шорта или какие в данный момент торгуются (по которым открыта торговая сессия) - то, это всё можно узнать с помощью той же QLUA и стандартных таблиц квика.

ну вы же сами говорите, что нужен статический список - ну так составьте его сами и для каждого счёта сделайте, так называемый класс, описывающий его поведение (доступность тех или иных бумаг для транзакций). информацию о доступности можно взять на основании приложений к брокерскому договору по этим счетам и фильтровать её раз в день или после каждого клиринга.

я думаю, самый правильный и действенный вариант в данном случае - это client-side. т.е. пишите на QLUA не большой пре-трейд модуль в котором:
при поступлении сигнала на открытие позиции проверяете валидность этой транзакции следующим образом: для каждого счёта составляете доступный перечень классов и инструментов, а также перечень доступных операций.
Этим Вы отсеете на собственной стороне часть транзакций,
остаётся 2 пункта: брокер и биржа.
брокер, в основном, отклоняет по риск-параметрам, редко когда по инструментам и классам. тут. как уже было сказано, никто не будет переписывать квик или ставить/писать/заказывать на брокерский сервер новый модуль. Соизмерять свои риски с теми, которые указаны в спецификациях к инструментам. Если к примеру, идёт 3 раза подряд отклонение транзакции и риск-параметры в норме то, можно просто опять же client-side сделать чёрный список (таблицу например) в которую добавлять эти классы/бумаги. Очень сильно на это похожее - существует в Wealth-Lab.
Остаётся биржа: биржа уведомляет остальных участников двумя способами: через свой сайт и в любой другой но, письменной форме (как правило после форс-мажора). Список классов и инструментов насколько мне известно (могу ошибаться, конечно) не обновляется на бирже чаще - чем он обновляется в квике. так что с этой стороны - лишнего, ничего городить не надо.

не хочу повторяться но, такой момент: отказ на транзакцию может зависеть по трём причинам:
1. на основе данных о клиенте, которые меняются динамически.
2. на основе данных полученных от биржи, где параметры тоже динамические.
3. на основании риск-параметров брокера (или других параметров)

вопрос: кто и главное, как это всё дело будет учитывать? (вообще, это по сути повторение поста #17). Можно ли это сделать? можно, НО! не бесплатно. Есть ли от этого выгода? вопрос - спорный. если это всё надо только лишь для увеличения быстродействия то, существуют и другие методы повысить его.

И мне, кстати, толком не ответили, если даже внедрить такую систему:
Что будет, если в один момент прошла транзакция на основании информации из старых списков, а в следующий момент списки изменились и оказалось, что новая связанная транзакция уже невозможна исходя из изменившихся списков?

вот честно говоря, уже неохота, что-то писать. Вы просто убиваете тему своим выяснением отношений.
1. Насчёт работы с "майном" - всё уже детально обсуждено и описано на quik2dde.ru

2. При использовании враппера - выигрыш в том, что это всё изолировано и не приводит к засорению программы, повышает читаемость. Справедливости ради, замечу, что я - сторонник того, чтоб враппер располагался в qlua.dll, а не в коде LUA-скрипта. Но в данной теме это не обсуждается, поэтому я её не развиваю.

3. подобного Не подобного. Я чувствую, что Вампросто захотелось поспорить. Ещё раз повторю: враппер делался разработчиками. Если у Вас есть вопросы по врапперу - задавайте им. Со своей стороны, я уже отметил в предыдущих постах, что КРАЙНЕ ВАЖНО СОБЛЮДАТЬ ПОРЯДОК РАБОТЫ С КОНТРОЛОМ. привёл рабочий пример. Что Вам ещё тут нужно доказывать/обсуждать/выяснять? Какой смысл от всех этих последних 10-ти постов??? Или Вы так любите, чтоб последнее слово было за Вами? Чтож, тогда умолкаю, я везде был не прав, несу полную чушь и полный бред, прошу меня понять и простить. Вам так легче? Вы это хотели услышать?

поэтому работу с майн лучше свести к минимуму. Подчеркну: не полностью отказаться, а свести к минимуму, оставив в нём лишь работу с разделяемыми переменными.

Честно сказать, даже не знаю, что сказать.... :)))))
То есть, получается, я, к примеру, купил-брокер исполнил, далее: я захотел продать-брокер НЕ захотел. Так что ль, получается???:))))))
Вообще-то, это его прямая обязанность исполнять поручения и действовать в интересах клиента. И НЕ ВАЖНО бесплатная там какая-то программа или нет. Вот есть к примеру, не программа, а телефон (или по другому ещё один канал связи с брокером для ввода поручений. рассматривайте его именно так) - он бесплатный. Я звоню брокеру, а брокер мне говорит: "а вот х.. тебе". Так что ль? Вы не перестаёте меня удивлять)))

если писать весь скрипт в одном "майне" и целиком в основной части скрипта то "Да" - не имеет. Но так можно писать и на тупайле. смысл тогда использовать LUA? А вот когда часть кода "и там и там" тут начинается геморрой из=за которого некоторые, казалось бы очевидные вещи начинают работать не так, как должно быть.

Серж,

иди тролль в другом месте.

тут разговор про то, что размер кода, равно как и число переменных значительно увеличаться, что приведёт к полной неразберихе в коде.
имеется ввиду, что враппер уже описан и в нём УЖЕ учтён правильный порядок, который разработчики так и не удосужились привести в документации. Нетрудно заметить, что подход "в лоб" у автора не сработал. Поэтому я лишний раз и обратил внимание на правильность порядка работы с контролом.

работа в "main" - это работа в другом потоке.

---------------------------------------------------------------------------------------------------------------
я так понял, что Вам бы лишь, что-нибудь написать. Или у Вас просто настроение не задалось?

1. надо забыть про работу в "майне", как дурной тон.
2. что будет если таблиц будет несколько? именно для этого и придумали классы.
3. при создании объекта "таблица", (без использования враппера), имеет очень большое значение порядок вызова методов, т.е. по сути, порядок создания объекта должен соблюдаться. это нигде не описано у разработчиков да и мой вариант врядли можно назвать абсолютно правильным но, как-то вот так (слегка переделанный твой вариант):

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

если "обозначить" то, только через скрипт

решил обойтись без quik_table_wrapper.lua ? :))))))

лучше б, что-нибудь по делу написал.

я так понимаю. это всё лирика с Вашей стороны...

выскажу своё мнение:

брокеру для этого придётся писать, а точнее, опять же заказывать ЗА СВОЙ СЧЁТ серверный модуль для квика у ARQA, который будет являться по сути динамическим фильтром списков с функцией возможного оповещения тем или иным способом. Что брокер, разумеется делать не будет.

касаемо основного вопроса: вот, у меня была ситуация: опционы у меня присутствовали во всех списках в квике, лимит позволял но, у брокера была в своё время отключена по умолчанию эта возможность для всех клиентов (дабы оптимизировать свои риск-параметры). всё решилось только звонком брокеру.

Почему это не может сделать ARQA? Ответ: спрос на такую услугу - единичный. К тому же придётся переписывать часть квика для динамического апдейта всех списков. В конечном итоге, из-за такого сомнительного нововведения неизбежно возрастёт траффик и понизится производительность самого квика. (здесь могу, конечно, ошибаться)

Почему это не может да и врядли будет делать брокер? Ответ: Брокер не пишет серверные модули, а покупает их у той же ARQA.

Главный вопрос: Что будет, если в один момент прошла транзакция на основании информации из старых списков, а в следующий момент списки изменились и оказалось, что новая связанная транзакция уже невозможна исходя из изменившихся списков?

Michael Bulychev

мне кажется или Вы удалили часть своих сообщений?

под "средствами Windows API" имелось ввиду, конечно, состряпать dll, аналог vclua.

С другой стороны, имея AllocTable, можно воспользоваться полу-хакерским методом и создать вместо таблицы какую-нибудь тоже НАТИВНУЮ кнопку или вообще другой контрол средствами Windows API, которая будет работать в окне квика. Потому что, эта функция по сути, скорей всего возвращает хендл окна. Насчёт этого, могу, конечно, ошибаться, потому как об истинной реализации могу только догадываться, читая между строк примеры в хелпе QLUA. Но, честно говоря, не хотелось бы до этого опускаться.

и так с остальными контролами. потому как если разработчики решат вдруг добавить парочку деклассированных то, это выльется в штук 20 функций для работы с этими "деклассированными контролами" и их описаний в хелпе. в итоге, справка по QLUA, равно как и код на QLUA будет стремиться к роману "Война и мир" по объёму.

таким образом, разработчики, вместо того, чтоб добавлять в qlua вот эти вот, по сути, промежуточные функции:

могли бы изначально вписать враппер "quik_table_wrapper" в QLUA, а мы, как пользователи, получили бы удобный, ещё один НАТИВНЫЙ класс в QLUA.

swerg,
я, конечно, понимаю, что Вы более опытный в метатаблицах, их метаметодах, а самое главное, как это всё реализовать (забиндить) на C++ или в том же Лазарусе. Но я не думаю, что таких большинство. Суть разговора в том, что вот у нас есть qctrls.dll и есть пример обёртки на QLUA, как с ней работать, вопрос: нахрена мне, как в первую очередь, трейдеру вся эти "танцы" когда я могу по примеру всё той же vclua в достаточно в простой форме обратиться к таблице, создать/отредактировать/удалить её. и мне даже не понадобиться вникать в то, как реализовано это, главное, чтоб оно БЫЛО реализовано. Или, другой пример, есть функция QLUA message, которая на самом деле combobox с жёстко заданными свойствами (это другой пример крайности). Другая выгода: т.к. это всё будет реализовано не нами, а разработчиками (у которых по определению больше информации) то, это отчасти упростит ранее выявленные проблемы с многопоточностью.

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

Предлагаю всем заинтересованным пользователям поддержать данное предложение в этой теме.

В целях уменьшения задавания "глупых" вопросов на форуме, а также для всесторонней поддержки независимых разработчиков и самого квика, предлагаю раскрыть на коммерческой основе интерфейс системы плагинов в квик (QUIK Plugin API), как это сделано в wealth-lab и других раскрученных торговых системах, ставших де-факто стандартом. Например, цена в 50 000 руб. на мой взгляд, устроила бы обе стороны.
Это позволило бы самим пользователям сделать квик более гибким, не быть привязанным к qpile или qlua, несмотря на в принципе, достаточно сильный её (qlua) потенциал, избавило бы от использования всевозможных связок: QUIK-QLUA-"что-то там ещё" QUIK-"что-то там ещё", отчасти, упростило бы решение проблем с многопоточностью и синхронизацией.

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

я надеюсь, что теперь, разработчики хоть немного задумаются над тем, что открытость - это не всегда во вред)))))

Это, как это??? Первый раз об этом слышу)))

одно дело когда они "внутри" в C-библиотеке и другое дело когда "наружу" в виде всяких врапперов в коде LUA-скрипта.

а когда научитесь деньги за это платить? или быть может вас надо научить?.....

а что сейчас разве есть те которые работают без ЭЦП?

это решение - никакое. не хотел это тут говорить но, у меня двойная авторизция и все ваши плюшечки с тем, что можно по-быстрому переподключиться у меня не проходят. мне приходится указывать помимо пароля ещё и место ключеового контейнера. а стоит серверу потерять коннект - ЭЦП сразу воет, что надо ввести ключ

отвечу за "этих" - звонок брокеру исправит Вашу прискорбную ситуацию. У него для этого всё есть.

засада. незасада...
Вам ясно сказали, что:
Но...
мыши давились но, продолжали жрать кактус...

неверите мне - поверьте моему опыту с 2008 г.

а что делать, если он будет просить заново вводить учётные данные(пароль, место хранения ключевого контейнера)?

если Вы про это: https://www.tradingview.com/stock-charts-support/index.php/Line_Break_Charts

то, что мешает Вам его самому сделать в QLUA?

Кстати, вот ещё интересная информация: http://quik.ru/bank/modules/server/archives/

оно там есть

это ни к кому конкретно не относится. равно, как и я не призываю к тотальному отказу от LUA. просто всё хорошо к месту.

тут разговор о чистом эквиваленте, а вы тут уже и событийную модель успели приплести. вобщем, разговор ниочём.

походу курнул:)))

специально для Вас они придумали QLUA - так что, можете сами написать себе индикатор на свой вкус, размер и кошелёк:)))

в общем, по моей проблеме, по акциям Белон - цена приобретения (средневзвешенная цена позиции) завышена чуть ли не в 2 раза.

по облигациям, так: ((Ликв. цена * Номинал / 100 + НКД) * Позиция) - ( (Баланс. цена * Номинал / 100 + НКД) * Позиция )
где,
баланс.цена: Средневзвешенная цена открытия позиции. Для облигаций значение указывается в % от номинала
ликвидн.цена: Цена, по которой в текущий момент возможно закрытие данной позиции по бумаге. Для облигаций значение указывается в % от номинала

квик считает на основе сохранённых в прошлые дни брокером данные. а вот. как брокер сохраняет это вопрос. у меня по портфелю все позиции - всё нормально за исключением Белона.

когда брал - срдневзвешенная была, кажется 3,5 что ль. ну или 3,9 но неуверен.

Белон:

если я правильно понял всю эту хрень, то:

• createdatasource без параметров получает данные на основе таблицы всех сделок
• наличие setupdatecallback заставляет обновляться при получении изменения по указанному параметру
• наличие setemptycallback заставляет обновляться при получении новой свечки
  

да уж...
только ленивый до сих пор не понял формат dat-файлов :)))))

Для того чтобы получить текущее состояние данных достаточно CreateDataSource.
Однако чтобы фактически произошла подписка на новые данные (а новыми считаются любые полученные с сервера) то нужен колбек SetEmptyCallback или SetUpdateCallback.

Функция SetEmptyCallback это то же самое что и SetUpdateCallback, только указывать функцию не требуется.

а почему тогда по остальным позициям всё нормально? у меня только одна позиция (эмитент) сбоит из писка.

• param – необязательный параметр. Если параметр не задан, то заказываются данные на основании таблицы всех сделок, если задан – данные по этому параметру.
• Параметр Тип Описание SetUpdateCallback function Позволяет задать пользователю функцию обратного вызова для обработки изменившихся свечек
  

таким образом, ничего странного.


Кстати, вот ещё интересная информация: http://quik.ru/bank/modules/server/archives/

p.s. причём, абсолютно не имеет значения: для графика вам эти свечки понадобились или для скрипта и его datasource, т.к. и там и там идёт обращение к одной и той же функции. а createdatasource - просто обёртка к ней.

и что тут странного? рассматривайте папку "archive", как кеш на локальной машине. он служит для того, что уменьшить траффик и, соответственно, нагрузку на квиковские сервера. просто в следующий раз, когда вы опять захотите открыть тот же график - квик уже не будет обращаться на сервер за прошлыми 3000-ми свечами, а качнёт их из файла. а с сервера будет получать только актуальные данные.

s_mike

для чего внедряют скрипты? чтоб облегчить жизнь рядовым пользователям (трейдерам), а не программистам. Программистам это облегчает жизнь - лишь отчасти. - уменьшается время на рекомпиллинг. повышается гибкость программы.

если превратить реализацию qlua в сплошные метатаблицы то, кто по вашему сможет ей пользоваться? для кого она? кто целевая аудитория? ответ: только роботорговцы, которые изначально опытней рядовых трейдеров и программисты.
напрашивается тогда вопрос: а кому это надо? мои предложения направлены на соблюдение интересов основной массы пользователей - трейдеров.
а если роботорговцы так хорошо разбираются то, что мешает им создать свою ТС и устанавливать свои правила? (извиняюсь если чем обидел)

нет проблем: пишите на ассемблере:)) полная свобода действий.

я думаю, что с тупайлом сравнивать пусть даже и qlua - совсем неуместно.

p.s.
а вообще-то никто и не говорил про ограничения, а наоборот. к тому же qlua развивается именно по экстенсивной модели и ничто, что до этого работало не отбрасывается.

да не волнуйтесь вы так - чтоб он исчез - потребовалось бы переписать саму LUA, что естественно делать никто не станет. Тут разговор о высокоуровневой надстройке к qlua и большей открытости её GUI.