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

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

Будут вам и свойства и классы и интерфейсы - просто Вы просите меня написать вам по сути, иерархию vcl "в моём представлении". Чем я и занимаюсь. Но, как уже писал, Вы это можете сделать и сами. vclua или, если уж, как дефакто стандарт: дельфовая vcl. Можете обойтись и своей реализацией: qctrls.dll и qlist.dll (про qchart пока молчу, но это пока). все поля и методы и события - там в них всё у вас описано - так выведете же их наконец, наружу через qlua и дайте нам ими пользоваться, КАК УЖЕ НЕ РАЗ ПОВТОРЯЛ: БЕЗ МЕТАТАБЛИЦ.

p.s. насчёт интерфейсов: я вам их опишу в своём понимании.

то есть, если у нас уже есть в квике qtable нам, как трейдерам, проще было бы обращаться к нему, как-то вот так:

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

суть в том, чтоб скрывать в C++ коде реализацию класса, а в LUA - дёргать только функции, позволяющие создать объект, настроить его поля, вызвать некоторые методы. Ваша, в данном случае задача: реализовать развёрнутую в с++ структуру классов графических контролов, избавив пользователя от таскания многочисленных врапперов и метатаблиц в своих проектах. также, обеспечить корректное взаимодействие на уровне потоков. для этого у вас есть все ресурсы в отличии от нас - т.к. мы не знаем ни контекстов плагинов, ни других внутренних структур. Это только, что касается qctrls.dll. в остальных темах - у меня к вам другие вопросы. p.s. Нам не надо надо LUA или средствами C API проектировать/создавать/описывать новые классы - нам нужны простые функции доступа и коллбеки к ним. какие классы, какая структура/иерархия нам нужна - на том уровне, который мне доступен, постараюсь вам нарисовать. но вам это и самим должно быть хорошо известно - ведь они у вас уже есть - просто надо их больше сделать доступными на QLUA. Пока я вижу, что у вас более менее детально реализован класс qtable. НО!!! вы совершенно (прошу меня извинить конечно) наплевали на его биндинг, вы просто представили его, как некую dll, к которой можно с помощью опять же лишнего QLUA-враппера иметь доступ. А почему бы изначально не дать нам пользовать готовыми абстракциями на манер message() или, тот же самый combobox, если смотреть изнутри.

кстати, вот актуальный мини-срач по схожей теме: http://www.gamedev.ru/code/forum/?id=147765
так... для общего, как говорится.

имеется ввиду классов, конечно, а не объектов

вот в том-то и проблема: и таскать вместе с основным скриптом кучу врапперов. а если объектов будет окло 200-300 то, это я вообще молчу.

я напишу вам, как-раз над этим работаю. просто если всё писать - потомы вы же меня и обвините в раскрытии своих секретов. потому что мои предложения некоторые УЖЕ у вас реализованы, но не раскрыты

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

ну тогда сделайте их доступными из QLUA сами. и сделайте уже нормальный бинд вашего qtable. пример того, как обходятся в CryEngine без метатаблиц Вам уже давали.

В связи с тем, что секция экспорта в библиотеке пользовательских контролов имеет открытый интерфейс, могу ли я, сделав к ней QLUA-бинд использовать её в своих программах на qlua?

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

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

короче это значит "магнититься".

Это просто у него такая коронная фраза. когда ему день. что-то писать/объяснять НО!! надо как-то отреагировать для начальства - он просто пишет:

:))))))

если "магнититься" - то, при рисовании линии вправо - с 11.50, влево - с 11.35

Если я правильно понял автора, попробую высказаться:
ближайшая по времени свеча меньшего таймфрейма. т.е. 11:35. (если рисуем слева направо). другие варианты пока абстрактно не видя перед глазами представить не могу.

Sergey Gorokhov,

извините, я Вы до этого мне вопрос задавали, а то тут уже непонятно кто кого спрашивает?

Однако! Что будет с такой отрисовкой если Вы будете наоборот, рисовать на меньшем тайме, а потом переходить на больший?

то есть, вы хотите привязать, получается точку дневного "хая" к соответствующему часовому "хаю"? Если так - то, время тут будет избыточным.

честно говоря, 2 раза прочитал сообщение - несовсем понял

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

Или разработчики, или брокер намудрил с расчётом средневзвешенной по объёму цене.

О порядке фьючерсных расчётов вам надо не здесь у разработчиков спрашивать, а на сайте ммвб читать:

• Спецификацию на фьючерсный контракт на "такой-то актив"
• Методику расчёта вариационной маржи по фьючерсному контракту "такого-то" актива
• Правила клиринга на Срочном Рынке
  

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

p.s. к тому же: вот Вы тут любите считать прибыли/убытки по каждым сделкам. а если поза арбитражная, да ещё и межрыночная? тут тогда полностью теряется всякий смысл от такой статистики.

а что мешает это всё сделать на QLUA? Хоть она пока ещё убогая но, уж с таким-то она точно справится. и результат будет не хуже ваших картинок.

я, конечно, извиняюсь. я - не разработчик квика но, как вы представляете себе это?

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

таким образом, тут 2 варианта:
не страдать рисованием, а думать над тем, как уйти от торговли по таймфреймам и графикам.
и второй, как Вы правильно заметили: если вы хотите точность - рисуйте на том тайме на котором торгуете.

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

невозможно...

м-да уж...
я бы постеснялся такое писать.

так что,
с Вас, как минимум, напрашивается, сделать редирект или, что-то в этом духе.

тут дело не только в поиске, а в том. что у многих в "Избранном" были ссылки на страницы (и не по одной). а теперь они не рабочие.

похоже, у автора просто есть робот и он за него торгует НО! автор несовсем уверен в своём роботе и хочет time2time его контролировать, что он там наторговал. Опять же, НО! Мешать ему не хочет. Стало быть, для него вариант - только иметь двух пользователей на одном счёте с разными правами. насчёт того, что это долго (поездка к брокеру + оформление) = тут, думаю, вообще смысла нет тогда, что либо комментировать. Это всё делается быстро, и по интернету или телефону в наше время. Как ещё один вариант:  использовать квик для торговли, а учётку от вебквика - для просмотра = всё делается звонком брокеру сей момент.

и парсить...

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

А не Мартынов ли это часом? :)))))))))

всё правильно. почему-то учитываются собственные посещения - в результате, "накрутка" просмотров.

а что тут удивляться? всё сделано по образу и подобию квика  :)  )))))))))

БЫЛО: http://www.quik.ru/forum/quik/50102/?view=list

СТАЛО: http://forum-archive.quik.ru/forum/quik/50102/?view=list

то есть, добавилось: forum-archive
-------------------
В итоге: весь гугл-кеш - идёт лесом, впрочем, как и мы. т.к. чтобы найти нужную информацию надо приложить больше усилий.

из некоммерческих форумов, что-то Вы можете найти для себя на:

• quik2dde.ru
• forum.qlua.org
  

На остальных форумах, в основном, роботорговцы.

пардон. он может просто заблокировать (без пароля). Но тогда, для разблокировки - надо будет опять звонить.

насколько мне известно, это делается одним звонком брокеру. У него для этого есть весь функционал.

самое интересное, что если удалить скрипт из списка и опять добавить - то, всё находится без проблем:)

автоматических решений, врядли Вы найдёте. тупайл не настолько раскрученный, а qlua - и подавно. Так что - только руками. Можно писать и на C++, а в LUA - только подключать dll. Многие так и делают для ускорения работы скрипта и сокрытия исходного кода.

в частности, интересует на кого рассчитаны FIX-решения? На брокеров или на обычных трейдеров?

а где можно почитать про Ваши FIX-приборы? Что это такое, как их применять и сколько стоит?

http://docs.cryengine.com/display/SDKDOC4/EntityUtils+Lua
тут неплохо показано: в скриптах на LUA - мы не создаём через какие-то там метатаблицы, и не редактируем объекты в самом LUA , а используем уже готовые функции: "MakeDerivedEntity( _DerivedClass, _Parent )", "broadcastEvent", "MakeUsable( entity )" и т. п.

Предоставлю здесь, за основу - можно взять тот же wealth-lab

насчёт "бумаги" - уже писал в общих чертах.
Глобальные переменные:

HookGvarChang("MyGvar", "MyGvarChangeEvent" )
MyGvarChangeEvent
do smth work
end

getGvar("MyGvar")
setGvar("MyGvar")

Под словом "глобальные переменные" - следует понимать глобальные в масштабах всех скриптов, т.е. по сути, нативные на уровне квика.

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

Михаил,

см. #35

Если Вы про то, что Вам надо подробную иерархию классов - что ж, я могу её составить. В какой форме желаете? В формате сообщения в посте - тесно, в формате e-mail - тогда другие участники не смогут подключиться к обсуждению и редактированию.

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

• Развитая поддержка классов с коллбеками в квике. Класс скрипта, класс для бумаги. Класс для работы с глобальными переменными.Класс индикатора. Про остальные не прошу. Хотя бы это.
• Добавление HookEvent etc. Полагаю уже не надо объяснять.
  
• Про доступ к нативным контролам в квике из LUA - я так понял, что уже было до этого предложение и оно за регистрировано.
  

Хотя бы это. даже если ответ "Нет" будет без аргументации - я это приму
Если Вы опять начнёте утверждать, что всё это можно сделать и в LUA - тогда, предлагаю на этом закончить обсуждение. оно-то, конечно, для разработчиков и легче так но, нам, как трейдерам, от реализации классов и коллбеков в LUA - далеко нет.

а где сами заклинания?

по-подробней. какая именно?

за примеры - однозначно, спасибо. но, лучше, если есть возможность, залей их на gitHUB или sourceforge.net, или сделай торрент. так сохранней будет.