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

т.е. даже пробовать не будете?

Странное желание.
Основное время запуска QUIK (а только это время волнует пользователя) занимает как раз чтение файлов с накопленными данными.
Если у вас нет места на SSD - просто перенесите весь QUIK на HDD. Ну если вы готовы мириться с упавшей от этого скоростью запуска терминала.

Ограничьте объем получаемых данных в вашем терминале QUIK.
https://www.finam.ru/education/likbez/kak-snizit-potreblyaemyiy-trafik-v-terminale-quik-i-izbezhat-poteri-svyazi-s-serverom-20200304-14330/
https://forum.quik.ru/forum1/topic840/

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

Не должно быть никакой привязки к визуальной таблице
Должен быть чисто программный интерфейс на манер CreateDataSouce c последующим вызовом call-back функции на каждую новость.
И API перебора всех уже имеющихся новостей.

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


Регистрируйте.
1. В документацию включить список функций, которые нельзя вызывать из OnStop() по каким-либо причинам, как нарушающие корректность выполнения программ Lua или работу терминала.
2. После этого у вас будет список функций с ограничением по функционалу. Очевидно, далее следует работать над уменьшением размера этого списка, т.е. надо добавлением возможности всё же вызывать функции из этого списка из OnStop() (c постепенным удалением таковых функций из данного неприятного списка).

Указывайте полный путь к скриптам, тогда они всегда будут находиться.
Как - см. выше

Схематично как-то так:

HMODULE lib1 = LoadLibrary("Trans2QUIK_1.dll");
TRANS2QUIK_CONNECT_1 = GetProcAddress(lib1, "TRANS2QUIK_CONNECT");
TRANS2QUIK_SEND_SYNC_TRANSACTION_1 = GetProcAddress(lib1, "TRANS2QUIK_SEND_SYNC_TRANSACTION");

HMODULE lib2 = LoadLibrary("Trans2QUIK_2.dll");
TRANS2QUIK_CONNECT_2 = GetProcAddress(lib2, "TRANS2QUIK_CONNECT");
TRANS2QUIK_SEND_SYNC_TRANSACTION_2 = GetProcAddress(lib2, "TRANS2QUIK_SEND_SYNC_TRANSACTION");

.....

TRANS2QUIK_CONNECT_1(....);
TRANS2QUIK_CONNECT_2(....);

TRANS2QUIK_SEND_SYNC_TRANSACTION_1(....);
TRANS2QUIK_SEND_SYNC_TRANSACTION_2(....);

Всегда за.

Вот бы метод каким это сделано описать...

Я бы откопировал нужное количество Trans2QUIK.dll с разными именами или разными каталогами и подключал бы их динамически, указывая для каждого экземпляра свой путь до QUIK при вызове TRANS2QUIK_CONNECT

Зарегистрируйте другое пожелание.
Из ТТТ должен открываться таблица, отображающая соответствие названий параметров и их "формальное название".
Тогда каждый сам легко и наглядно сможет это соответствие увидеть без всяких DDE и экселов.
С обязательной возможностью копирования данных из такой таблицы!!! чтобы не приходилось перепечатывать названия параметров.

Вам в этом случае не придется поддерживать актуальность документации, просто отпадает надобность в документировании.

Это как раз понятно: лезть в объекты интерфейса Windows и связанных с этим собственных структур данных из разных потоков - слишком сложная замута. Потому её всегда избегают.

Сам себя поток прибить не может. Должен кто-то "извне".

Не совсем так.
Очевидно, что написан обычный стандартный код (который выполняется в основном потоке):


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

Это бы развязать, конечно. "Но эт вряд ли".

Может у кого-то есть готовый пример? или кто-то готовым решением готов за деньги поделиться?

Положим как-то мы сформировали свечи для нестандартных TimeFrame
Вопрос: есть ли возможность как-то их отрисовать штатными средствами QUIK, через Lua-индикаторы, например?
Я не сумел придумать как это сделать. Ведь на графиках, на которые накладываются индикаторы, есть возможность выбирать только стандартные TimeFrame.
Но может есть какие-то другие варианты?

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

Итак, открываем документацию, файл "Использование Lua в Рабочем месте QUIK.pdf".

На картинке "Событийная модель" после OnStop мы видим фразу:

Однако далее в тексте мы видим другое объяснение:

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

Окей, я продолжаю далее следовать рекомендациям из того же описания (официального).
Чуть ранее:

Супер. Такой подход нам и демонстрирует автор изначального сообщения этой темы. Он все делает в main(). Использует лишь один обработчик, связанный с интерфейсом пользователя OnStop(), т.к. надо же скрипту сообщить "остановись, хватит". Ибо иного пути нам не предоставлено.

И тут вдруг выясняется, что в этом описанном в документации подходе есть "особенности", когда часть функций попросту не работают в каких-то ситуациях! Как это так??
Это явная ошибка, которую необходимо исправить.
Да, обработчики событий не должны вызываться после OnStop, в этом есть логика, да и это явно описано в документации. Но другие-то функции взаимодействия с терминалом почему не должны работать?? потому что "так получилось"? Нет уж, это не есть обоснование; это лишь признание кривоватой реализации данного места, которая, очевидно, является ошибкой и должна быть исправлена.

Mixa, пойми главное: ты можешь сейчас здесь спорить до посинения хоть два года - ничего не изменится. (см. комментарий про 10 лет)
Пока сам не сделаешь как тебе надо, опираясь лишь на те средства, какие есть.

На что потратить следующие два года твоей жизни - решать тебе.

Чтобы получить общий список список классов (режимов торгов) и бумаг, надо использовать функции:
getClassesList
getClassInfo
getClassSecurities

getNumberOf позволяет получить данные только из строго определённых таблиц, перечисленных в справке.
И задавать там надо не имя таблицы, как вы его видите в терминале, а как указано в справке.

Получить значения параметров торгов (из таблицы параметров торгов) этой функцией нельзя.

Не совсем так.
Это же индикатор, а не просто данные.

Нужно иметь такую возможность:

1. получили, например, вызов OnCalculate для индекса 5 от основного источника данных (т.е. от источника, по которому построен индикатор, как сейчас). Отлично, что-то посчитали и нарисовали.
2. теперь получили данные по свече с индексом 4 по дополнительную DataSource. Значит что надо:
а) получить вызов OnCalculate для индекса 4, где мы получили данные по основному и дополнительному источникам и тут же иметь возможность выставить новое значение индикатора в точке для свечи 4.
б) дополнительно получить вызов OnCalculate для индекса 5, т.к. этот индекс, очевидно, надо заново пересчитать, ведь в свече 4 у нас получены новые значения, а от значения в точке 4 у нас зависит и значение индикатора в точке 5; после иметь возможность обновить значение индикатора в точке 5, т.к. оно изменилось

Так понятно?

Чета я забыл, что getMoney возвращает таблицу.
Не в строчку выступил, извиняюсь.  ;)

Мне просто любопытно: а вы также наугад составляли буквы в программах mql ? вот просто любопытно.


Приведу тут тоже ссылку, потому как найти её на этой сайте в самом деле крайне затруднительно; я просто помню по каким словам ее гуглить, просто так фик найдёшь.
https://arqatech.com/ru/support/files/
Внизу страницы "Документация по языку LUA в QUIK и примеры.zip"

Если запрашиваемой возможности инет - просьба зарегистрировать пожелание.

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

Не поможет, т.к. нет средств заставить индикатор перерисоваться в этот момент.
В пункте а) списка проблем в некущем API я в самом деле не то написал.

Требуется: иметь возможность строить Lua-индикаторы на основании нескольких источников данных.
Легально и корректно.

Сейчас скрипт строится только по одному источнику данных.

Можно получать второй (трений и т.д.) источник
- через метку другого графика читать с него значения вызовами getCandlesByIndex;
- либо использовать data source,
но каждый из этих путей неполноценный, т.к.
а) нет уведомлений о приходе данных из "второго" источника, а значит нет возможности строить скрипт с учетом изменившихся данных второго источника;
б) сложности в настройке / использовании.
Основное это а), конечно.

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

Вопрос: когда будет такая возможность в QUIK?

В справке написано:


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

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

На срочном рынке ММВБ т.н. "планки" - это ограничения самой биржи, и биржа их транслирует. Квик тут ни при чем.

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

https://forum.quik.ru/forum1/topic6410/

Но самое грустное - это вот этот ответ:


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

Напомню, ветка начиналась с "Добавить функции вида pauseCallbacks и resumeCallbacks, где первая приостанавливает вызовы многопоточных колбеков". И мы долго выясняли про какие многопоточности идёт речь.
Вроде как выяснили (хотя явно вы это не писали, но я вас понял так), что pauseCallbacks и resumeCallbacks вызываются в main(). Ну иначе бы и проблемы не было, очевидно.
Теперь внезапно все это в одном потоке, как так??

Так где вызываются pauseCallbacks и resumeCallbacks? и если не вmain(), то о какой многопоточности речь и как эти функции помогут, будучи вызванными не в main() ?


Давайте не менять условия задачи на ходу. Это совсем уже другая история, она здесь не обсуждается.


В самом деле: вы d каждом сообщении не договариваете половину важных деталей под девизом "и так очевидно", а когда совершенно не очевидные детали кое-как клещами из вас вытянешь - вы же других обвиняете в том, что кого-то там держат за идиотов.
Самому-то не стыдно не уметь корректно и внятно общаться?

Python тогда здесь при чем?

Напишите, как бы вы в Python отправляли информацию в телеграмм-бот. Приведите пример кода, попробуем переложить на Lua и библиотеки для Lua.

Однако мне всё же интересно было бы тут услышать ответ тех. поддержки
Неужели при указании нестандартного интервала в предыдущих версия QUIK корректно формировал и отдавал нестандартные свечи?

Почему?? Хочу такую кнопку!!

Я тоже хочу отменять сделки!!
Запишите моё пожелание!

Скрипты - они про автоматическую работу. Полностью. Без наблюдения человеком.
При этом очень важно, чтобы скрипт работал. Да, в нём могут быть какие-то ошибки. Может быть ошибки при экзотических сценариях, приводящие к остановке скрипта.
Но важно, чтобы скрипт все же работал, даже если наткнулся на какую-то непредвиденную ситуацию.
Пусть и методом повторного перезапуска (фактически "с нуля"). Понятно, что стартовать скрипт "с места падения дальше" - невозможно.
Как скрипт будет взлетать с нуля после аварии и восстанавливать своё состояние - уже проблема разработчика скрипта. Хотя можно и передать какой-то признак в OnInit, например, "рестартовано автоматически после ошибки", пригодится.

Если вы беспокоитесь, что скрипт "задолбает" терминал перезапусками - можно предусмотреть вариант: прекратить перезапуски, если скрипт упал 10 раз за какое-то время (за минуту, например). Хоть я и не уверен, что это нужно.

А если callback в момент вызова такой функции уже выполняется - как должно работать?
Этим вопросом я намекаю на то, что приведённому вами коду видно, что в многопоток вы не умеете.
Почитайте книжки, ознакомьтесь с объектами синхронизации и их использованием - и всё наладится. Никакие "отложенные колбеки" не понадобятся.

Однако пожелание для QUIK есть: штатные средства межпоточной синхронизации в QLua таки нужны.

Еще лучше, конечно, пересмотреть модель выполнения скриптов. Никакие конкурирующие потоки в рамках одного скрипта там явно не нужны.

Считаю это ошибкой, которую разработчики QUIK должны исправить.
Интерфейс у терминала русский, по умолчанию для русских букв штатные upper / lower должны корректно работать.

Скрипты Lua используете?

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


Я бы не согласился. Callback-функция - это та, которую кто-то вызывает по какому-то событию. А сам это скрипт или среда исполнения этого скрипта - какая разница? По-моему, никакой для применения данного термина.
Кстати, в самом начале следующей цитаты вы ровно про это и пишете, так что не совсем понимаю почему непременно "скрипт сам дёргает". Впрочем, вероятно это не суть важный момент.


Вообще-то это нормальное, обычное и ожидаемое многопоточное выполнения кода.

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


Я согласен с тем, что многопоточность в скриптах была сделана напрасно; от нее оказалось больше проблем, чем пользы. Было ли это очевидно в момент проектирования - не уверен.
Однако пользователи страдают по другим причинам, считаю:
а) не умеют в многопоточность;
б) сделав многопоточность в скриптах, ARQA не добавила функций для межпоточной синхронизации.

Пункт а) решается чтением книжек.

С пунктом б) чуть сложнее ввиду отсутствия готовых функций в QLua.
Например, библиотека w32 для QLua содержит функции работы с мьтексами, что вполне можно использовать для синхронизации, если это необходимо. Правда мьютексы несколько избыточны и тяжеловаты, ведь синхронизируемся ты лишь внутри одного процесса (в терминологии Windows), надо будет добавить в нее и работу с более подходящим для этого случая объектом "критическая секция".

Ну и еще в QLua есть "Потокобезопасные функции для работы с таблицами Lua". В отдельных случаях они спасают, но в очень узком круге случаев, да.

Как-то не верится.
Возможно, ранее возвращались левы цифры т.е. от какого-то другого тайм-фрейма ? в это я еще могу поверить.
Вы уверены, что возвращались верные данные именно для указанного вами произвольно тайм-фрейма?

Артем,
я таки напомню мой вопрос, адресованный вам, на который вы упорно стесняетесь дать ответ:


Ответ от вас хотелось бы услышать.

На мой взгляд вы куда-то не туда роете. Ну т.е. там, где нет практической пользы.
Для практической пользы достаточно считать, что все main() работают параллельно, и параллельно с ними работают callback'и.
Параллельно - значит любая часть кода этих main() и callback'ов может быть выполнена в произвольном порядке.
Нужен точный порядок - надо придумывать синхронизацию, да. Иначе просто считать, что любой кусок кода может быть выполнен в любой момент.

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

Нет, не в произвольный.
В терминале возникает какое-то событие.
1) Терминал доделывает все свои дела, в том числе полностью завершается выполнение Lua-кода колбеков, отрисовывает интерфейс если надо и т.д.
2) Выбирает событие из своей очереди
3) Вызывает Lua-колбек произошедшего события (если таковой имеется), этот колбек до конца выполняется (т.е. до выхода из колбека), ведь так?
4) Если есть еще активные скрипты с таким же колбеком - все такие колбеки последовательно вызываются и завершаются (выходом из них)
Всё это в рамках одного основного потока терминала
5) После этого терминал обрабатывает свой код, связанный с данным событием (никакие колбеки не вызываются в этот момент)
6) Терминал переходит к следующему пришедшему событию и далее на пункт 2)

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


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

Вообще говоря по справке и не подразумевается передача произвольного интервала, только заранее заданные константы.
Так что не понятно что именно надо исправить.


При этом в справке есть уточнение:


Наверное было бы логично, если бы при неправильном значении interval тоже возвращалось nil

А как надо починить?
Должно возвращать ошибку? или nil?
Или должно возвращать данные?
А может в предыдущей версии работало как-то иначе, а теперь поведение изменилось?

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

Вы зачем-то намешиваете совершенно разные термины, а потом пишете "никакие стандартные термины не подходят".
Отлично подходят, именно термин callback-функция, которая вызывается в момент нужного события.
Прерывания - это из другой оперы, не стоит их сюда примешивать.


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

Вот тут нарисована картинка, которую даже стырили в документацию ARQA.
https://quik2dde.ru/viewtopic.php?id=16

Может она что-то для вас прояснит?

Callback-функции вызываются в основном потоке работы терминала.
В "другом потоке" работает main().

Так что что там вызывается "посреди выполнения другого кода" - мне не понять.


Callback-функции работают строго последовательно, т.к. выполняются все в одном потоке. Уберите код из main() (ну кроме заглушки про is_run) - и никакого "параллельного кода" у вас не останется, будет ровно то, что вы хотите - полностью однопоточный код без каких-либо проблем.

Так определение "многопоточных колбеков" будет уже или нет?

стр. 112

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

https://arqatech.com/ru/support/files/
Документация по языку LUA в QUIK и примерыzip, 4.3 МБ
https://arqatech.com/upload/iblock/194/quik_lua.zip
"Интерпретатор языка Lua.pdf"