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

я - так и знал...
:)))))

полный пример в студию.

такое ощущение, что кто-то решил написать справку из вопросов и ответов форума по всей QLUA:)))))

с такими выражениями - надо быть аккуратным в QLUA с его "ленивыми вычислениями"

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

почему я думаю, что CreateDatasource - автономна, т.е. имеет свой LUA-поток? Потому что она служит для прямого получения данных с сервера QUIK и имеет свои коллбеки, которые не связаны со стандартными QLUA-коллбеками, выполняющимися в основном потоке квика для всех скриптов.

в любом случае, getparamEx - берёт информацию из текущего и внутреннего источника данных QUIK-клиента. CreateDatasource же, скорей всего, выделен в отдельный LUA-поток, да ещё и работает через метатаблицу со своими методами Close и т. д. и т. п. Кроме того, скорей всего, под него заводится отдельный запрос на получение данных с сервера. Поэтому, конкретно с getParamEx - он никак не связан. То есть, я более чем уверен, что он не использует эту функцию в недрах QLUA, чтоб иметь доступ к внутренним и текущим данным QUIK-клиента.
Кроме того, большой вопрос, что будет в реале действительно быстрее. Лично мне, думается, что для текущих данных - именно getParamEx.

ну и зря. Похоже 21-век Вас не коснулся...
это удобно, интерактивно, экономично (как минимум, снижает траффик).

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

ну вот...
взял и убежал сразу...

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

а разве пользователи не этим занимаются - когда пишут свои библиотеки на LUA C API в QLUA???

да ладно? :)))....

https://forum.quik.ru/messages/forum12/message9521/topic1030/#message9521
https://forum.quik.ru/messages/forum10/message8065/topic872/#message8065
https://forum.quik.ru/messages/forum1/message3276/topic396/#message3276
http://forum-archive.quik.ru/forum/ideas/32746/32750/#m32750

просто нет слов....:)))))))

Есть возможность встроить в сам QUIK этот (forum.quik.ru) официальный форум в формате чата, чтоб не держать открытым браузер и в свободное время параллельно торгам его просматривать и, возможно комментировать.

Вопрос к разработчикам,

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

<ответ - обязателен>

или, "по-простому", - вот так:
http://arqatech.com/ru/support/files/

ftp://ftp.quik.ru/public/

там, буквально, всё...

он просил без os.execute

без них - не обойтись.

"чисто" lua - чисто, не в состоянии сделать этого. Для этого есть функции WinAPI +, как вариант, (как было сказано выше) - написать своё небольшое расширение (библиотеку) с использованием LUA C API.

касательно сотни коллбеков...

ничто не мешает пользователям самим их создать. Главное уйти от повсеместно навязываемой дешёвой парадигмы: когда коолбеки исполняются в основном потоке терминала.
Специально для Вас, пользователи, разработчики выделили для Вас на каждый скрипт - отдельный поток. Осталось только грамотно этим воспользоваться...
Спору нет - это кардинально изменит архитектуру Ваших примитивных торговых ботов. НО! Потратив время на создание своего торгового qlua-движка - Вы потом с торицей всё себе вернёте. Можно будет сабклассить ботов, быстро удалять/добавлять бумаги на которых они имеют право торговать и т. д. и т. п.

getParamEx и CreateDataSource - абсолютно никак не связаны. Однако, вполне может получиться так, что для получения исключительно текущих параметров - быстрее использовать именно и исключительно getParamEx.

вкратце, суть в том, что файловое хранилище квика - не оптимизированно для быстрой загрузки/модификации. Это раз...
Во-вторых,
<начиная с этого момента высказываю исключительно собственное мнение - мои мысли (неначём не основанное)>
в основном, квиковцы не считывают разом целый блок параметров, а считывают каждый параметр по отдельности ("по-dword-но"). Попутно проверяют его корректность, что несомненно отражается на занимаемой памяти - т.к. в этот момент, в ОЗУ могут накапливаться результаты промежуточных вычислений конкретных функций обработки конкретных параметров.
В-третьих,
не удивлюсь,
если открытие и закрытие файла параметров (одного из файлов (ну или базы данных сериализуемых параметров)) осуществляется после обработки каждого блока параметров (в худшем случае после каждого параметра).
Этого никак не избежать и никуда от этого не деться в той или иной степени. Выручить может лишь то, если заранее известен размер файла сериализации (т.е. он изначально спроектирован с необходимой избыточностью). В таком случае, будет просто достаточно один раз открыть этот файл (получить его хендл), а не постоянно обращаться к ядру ОС за этим. А доступ/чтение/модификацию параметров - осуществлять по заранее известным смещениям внутри этого файла. Т.е., в этом месте, таким образом, отпадает надобность в парсинге сохранённых параметров и определении (расчёте) смещения для функций вида fileseek (предполагается, что оно уже заранее известно). А значит, уменьшается потребность памяти и увеличивается быстродействие.
В-четвёртых,
для более быстрой работы с параметрами квика - необходимо производить общее обслуживание файловой системы. т.е. запускать такие программы, как CHKDISK. Также желательно использовать файловую систему NTFS на диске где размещён квик (думаю, что это уже не актуально - бо как она сейчас у каждого и так стоит)
Кроме того, важно время от времени проводить частичную дефрагментацию. В проприетарных высокоскоростных серверных приложениях за этим следит отдельный драйвер режима ядра, который следит за физическим размещением наиболее критичных к быстродействию файлов.
В-пятых,
SSD, конечно, весьма сильно выручает ситуацию. Но и тут, приходит момент когда он не спасает, если не заниматься тривиальным техобслуживанием файловой системы.

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

Большое спасибо!

надеюсь, не обманете...

Спасибо, Егор. Хоть кто-то откликнулся

Тут нечего изучать. Проблема в том, что импортируемая qlua.dll функция kernel32.dll GetTreadId - не работает в XP, а работает только начиная с Висты:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683233%28v=vs.85%29.aspx

Самое простое, что Вы можете - это отказаться от её использования, заменив чем-то вроде "связки" Thread32First/Thread32Next

Уважаемые разработчики Arqa Technologies!

Вы предлагаете пользователям за Вас патчить QLUA или Вам стало глубоко наплевать на пользователей WinXP PRO???

<требуется обязательный ответ>

"они" - как-то называли цифру в 5тыр в месяц. Но, думаю, Вам проще обратиться с этим вопросом в отдел по продажам.

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

ждём очередное "новое" обновление???....

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

Итак, поехали:
после данного обновления - отвалилась напрочь QLUA. Да-да, именно эта ваша.
"Опытным" путём установлено:

Скрытый текст

Скрытый текст

Полагаю, что надо сделать, чтоб этого позорного бага не было - разработчики уже догадались...

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

мда уж...
и это, называется обновление...

врядли. Скорей всего, они оформят это (а точней уже оформили), как платный продукт (https://arqatech.com/ru/products/quik/modules/integration-solutions/fix-software-interfaces/)

этого не будет, т.к. это серьёзно скажется на безопасности.

Уважаемый Егор!
Один вопрос:
Ну и стоило выпускать одно обновление, чтоб потом в другом исправлять очередной нескончаемый поток багов - предыдущего?


в качестве P.S.
<возможно стоит задуматься не над обилием очередных восхваляемых некоторыми "плюшечек", а всего лишь, для начала, начать с банальной стабильности своих "поделок"??>
безобид.

После "обновления" с версии 6.3.х.х. перестали сохраняться (как-либо) местоположения свёрнутых MDI-окон на "главной" форме вкладки:

Скрытый текст

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

а разве не это? ->Система->Настройки->Основные настройки->Программа->Получение данных->Интервал обновления данных с текущим состоянием???

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

Мне проще в таком случае, создать свой проект на базе выше упомянутой MediaWiki.

Удачи Вам с Вашими почитателями и Вашей стратегией по развитию...

если всё сделать так, как нам тут только что предложили - то стандартную библиотеку lua, также входящую в QLUA - "require" - можно смело отключать/выбрасывать - ведь она тоже явно не указана в документации по QLUA Однако, весьма хорошо прописана в самой LUA. И если эту библиотеку "изъять" из QLUA - в плане полезности для квика - стремительно упадёт к нулю.

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

похоже - они и сами всё прекрасно поняли - и из-за этого, теперь пишут такие приписки:

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

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

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

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

но только, чтоб был обязательно индекс к хелпу, как например, вот здесь:
https://developer.valvesoftware.com/wiki/SDK_Docs
https://developer.valvesoftware.com/wiki/Category:Modding

Как видите - пример достойный подражания и за бесплатно.

а лучше: http://quik.ru/qlua/wiki/

к примеру: help.quik.ru/qlua/wiki/

Уважаемая Арка (наверно тепрь надо с Вами говорить так...) - я так и не услышал ответа на свой вопрос? При том, что я привёл достаточно развёрнутый и аргументированный взгляд на проблему. Почему нельзя создать онлайн-хелп на базе (да пусть хотя бы даже движка википедии)? --> https://ru.wikipedia.org/wiki/MediaWiki

так и есть - они с Михаилом Булычевым - уже поднимали этот вопрос на старом форуме: --> http://forum-archive.quik.ru/forum/lua/117341/117351/#m117351

пока же, в данном случае нам ограничились лишь позволением создавать/строить таблицы.