Пожелания по квику и LUA

1. qchart.dll. Прошу раскрыть API этого контрола.

Это облегчит участь многим и облегчит задачу поддержки визуализации в скриптах.

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

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


3. Также нужна поддержка хуков событий (Events):
Я не прошу создания и регистрацию нативных событий, т.к. это далеко нетривиальная задача для квика и LUA. Поэтому прошу лишь на развитой поддержки событий в квике. Те, что есть - этого мало. Смысл в том, чтоб в LUA пользоваться уже готовыми зарегистрированными квиком и в квике колбеками, а не писать это всё дело через псевдомногопоточность на LUA.
4. Должна быть модель общей разделяемой памяти для всех скриптов для обмена общими данными. Это надо для систем где одновременно работают разные роботы на разных инструментах. То есть для корректного обмена данными между скриптами-роботами

5. Нужен системно-реализованный класс алертов (алармов или триггеров) и чтоб, его можно было отслеживать вызывать из LUA.
К примеру, есть бумага, есть условие по ней, оформленное в виде функции. При срабатывании условия квик вызывает коллбек.
На самом деле, это всё относится к п.3. Но, если это невозможно для Вас сделать - чтож, придётся писать далеко нетривиальные "велосипеды" на LUA.

6. Нужен класс TaskManager - для создания и управления параллельными задачами.
Можете не реализовывать но, выполните хотя бы остальные пункты.
7. Неплохо было бы иметь такой коллбек, как OnFrame. Скажем, 20-ти миллисекундный интервал устроил бы многих. Что можно делать и для чего он нужен - зависит от того. какие функции из этого списка Вы собираетесь исполнить. Вариантов много, равно, как и реализаций.
8. Неплохо было бы иметь профайлер скриптов и QLUA-дебаггер (исходники Decoda есть в общем доступе, что мешает заточить их, под QUIK как многие разработчики делают для своих программ)
----------------------------------------------------------------------------------------------------------------


Одним словом, нужно много нативных классов, всяких и разных, чтоб не изобретать их в LUA и не думать об их синхронизации. То есть, в идеале, программирование на LUA - должно и ОБЯЗАНО превратиться в callbacks-программирование. В противном случае, у него просто нет шансов. В индустрии 3d-игр - есть 2 основных направления или стиля работы 3d-движков с поддержкой скриптов на LUA:

• движки, которые имеют развитую классовую структуру и тем самым, не заставляют скриптописателей писать многочисленные велосипеды. А дают им лишь возможность создавать, удалять, изменять свойства шаблонных классов, которых тьма. В результате,  с созданием скриптов может справится даже школьник, а игра - засчёт массовости имеет весьма приличный оборот.
  
• и движки, которые имеют минимум классов, оставляя всё на откуп скриптописателей. Бесспорно, это даёт большую свободу в реализации возможностей и даже некоторые известные игры это используют НО!!! это требует неимоверной квалификации скриптописателя. И как показывает практика или жизнь - такие игры долго не живут. Так вот, QLUA - сейчас на этом уровне.