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

Anton, Да, последние 6 слов весьма убедительны.  

Daniil Pozdnyakov, Господа, а как насчёт самого стандартного и часто задаваемого вопроса? Будет у нас когда-нибудь сервис для получения свечей по разным таймфреймам или "Lasciate ogni speranza, voi ch’entrate"?

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

Alex, Написать свой парсер на Lua.

Roffild, Ишь ты, "молодость", панимаш! Да ещё и "покормлю тролля"...  
Зачем разделять? Название нормальное придумать.Да бывают разрывы - в чём проблемы? Скрипт просто перестаёт работать, и никакой isConnected для этого нафиг не нужен.И чего? На каждый чих этих долбаных "стандартизаторов" будем курочить софт, который и без того глючный? Чем не устраивает 1251?
Чтобы отличать заявки первого скрипта от второго (на кой вообще нужен второй скрипт?) нужна как раз уникальность айдишек. Я вот именно по TRANS_ID ловлю номера заявок для снятия, если они мне не известны, и здесь тоже нужна именно уникальность ID.

Roffild, Ну, во-первых, это не баги, а во-вторых, при чём здесь "программирование на Lua"? Все эти "пробелом ставить галку" - это интерфейс юзера. И нафига Вам isConnected? В жизни ни разу не проверял! А Unicode на кой?Господи! Неужели ХОТЬ ЧТО-ТО в этом языке сделано нормально?

Ну и, наконец, а на кой вообще нужен TRANS_ID, если он не уникальный?

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

Alex, Как я сказал, так и быть.    

Alex, Да хоть десятимерный! Это не массив, это дерево получается. Любой его элемент можно тоже объявить таблицей, причём вовсе не обязательно его заранее инициализировать.

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

ДА?! А ну, покажись кто-нибудь, кому эта функция НРАВИТСЯ? У кого там такой "вкус и цвет"? Неужели такие водятся?

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

Ради КАКОГО, блин, "интереса"? 10 тыщ раз заказывать данные? По одному заказу на каждую сраную свечу? Проверять этот маразм - отвиснет или нет? А если даже и не отвиснет, это всё равно МАРАЗМ!

О, Господи! LUA, QLUA... Lua я использую ТОЛЬКО для программирования торговли на бирже! Иначе бы к такому дерьму на километр бы не подошёл. Так что LUA и QLUA для меня полные синонимы.

Это не "обычный логический оператор OR провинился", а использование его в операции присвоения.

Господи, да в Lua вообще ни хрена нет! Тип integer - и тот спи&дили! Какая уж тут "работа с битовыми флагами". В любом ассемблере есть, а здесь, блин, "творчески переработали". Таких разработчиков к компу вообще подпускать нельзя. Пожизненно!

Ничего подобного! Я бы для и всех интервалов сам считал, но у меня комп не висит постоянно в торгах. Самостоятельно посчитанные свечи - это кажется, единственное место в скрипте, которое, будучи раз написанным, работает как часы.

Ну вот, "формирует 3000 последних свечей", когда мне нужна ОДНА! Какие ещё нужны доказательства, что этой мерзости место только на помойке? Ах, да - эти же придурки ещё и НЕЗАКРЫТЫМИ свечами дрочат - ещё один идиотизм. Мне же нужна ОДНА ЗАКРЫТАЯ СВЕЧА на каждый таймфрейм.

nikolz, Лапуль, ну не путайтесь Вы под ногами, не засирайте ветку - дайте с человеком поговорить!

BlaZed, Это была демонстрация абсолютной НЕработоспособности CreateDataSource, на основе которой ВААПЩЕ НЕЛЬЗЯ "реализовать что-либо интересное", такой способ доступа к данным - это КРЕТИНИЗМ! Не говоря уже о том, что функция эта относится к разделу работы с графиками. С нею невозможно работать при ЛЮБОМ коде, даже вылизанным до последней запятой.Во-первых, Lua я знаю. Мало того: я здесь чуть ли не единственный, кто пишет на чистом Lua. Я имел в виду, что оператор этот дурацкий, я так никогда не делал, и делать не буду.Во-первых, свечи у меня начинаются с 15-секундных. Во-вторых, они считаются по-другому: я уже не раз говорил, что классические мат. ожидание и дисперсия в миллион равз информативнее всей этой "японской" дребедени. В-третьих, Вы не ответили на мой вопрос: СКОЛЬКО свечей она мне даст по каждому интервалу? И что она будет делать при появлении очередной свечи? Будет всё время дописывать? Или даже и дописывать не будет?

Ах ты засранец!

Ну, начнём с того, что тикеров у меня не 4, а на сегодняшний момент 1529, и их состав немного "плавает", и код скрипта это, разумеется, никак не затрагивает. Интервалов у меня тоже вдвое больше - мелкие свечи я считаю сам, но они ведь тоже должны где-то храниться и далее обрабатываться по общему алгоритму..

Теперь инициализация: что делает хреновина вида "ds[tikers[j][1]]=ds[tikers[j][1]] or {}" я не знаю, да и знать не хочу. Для меня не подлежит сомнению, что обращение к данным тикера должно быть по его айдишке (его порядковому номеру в таблице), а уже в полях этой таблицы должен лежать и код тикера, и код класса, его валюта, статус, количество закупленных лотов, размер лота и вся прочая хрень. В том числе, одно из этих полей должно содержать информацию о свечах по разным таймфреймам: младшую часть я инициализирую и поддерживаю в актуальном состоянии сам, а вот вторая половина должна получать её как раз через CreateDataSource. Итак, мне предлагается при старте вызвать эту конструкцию 1529*8=12232 раза, а уж опосля... впрочем, что-то мне подсказывает, что никакого "опосля" уже не будет - на этом скрипт и сдохнет.

Теперь насчёт Size: СКОЛЬКО свечей она мне даст по каждому интервалу? Повторяю: мне нужна ОДНА, последняя. Ну, для страховки, ДВЕ. А эта падла сколько их туда насуёт? И, насколько я понимаю, будет всё время дописывать? Или даже и дописывать не будет?

Нет, я не понимаю: Вы ВСЕРЬЁЗ предлагаете подобную хрень реализовать или прикалываетесь?

BlaZed, Нет, самому мне до такого вовек не догадаться! Так КАК ИМЕННО нужно делать? Мне вот совершенно не очевидно! Вернее, мне очевидно, что любой решение будет называться "ППЦ". А вопрос к меня именно в том: Как получить все эти свечи? Лично я решения не вижу ВААПЩЕ.

BlaZed, О! А Вы - умеете готовить? А ну, шайбу! Мне нужны свечи (хотя бы последние) от 15 минут и выше, вплоть до месячных. Мелочь я сам считаю, до часовых (0.25, 0.5, 1, 2, 4, 8, 16, 32, 64 минуты). И это примерно по полутора тысячам тикеров (чуть больше). А ну, хто здесь Великий Кулинар?  

BlaZed, Весь заказ данных через CreateDataSource один сплошной атавизм.    

Кстати, о птичках: функция - это ТОЖЕ объект. И метод вовсе не обязательно функция.

Заинтриговали, глянул в Вики, чо там за "замыкания" нарисовались. Господи, какая же чушь!И "видимостью" своей затрахали - даже несчастный goto теперь ни хрена не видит.Читал и ржал. Ещё лет 20 назад я говорил, что "указатель на структуру покрывает все "классовые" потуги Страуструпа как бык овцу". Надо же умудриться на ровном месте наковырять себе столько проблем! Причём ВЕЧНЫХ проблем!

Nikolay, Таймер и так сделан: почти в любом скрипте стоит этот цикл со sleep.

Алексей, Только этот колбэк и катит!   Именно, что он приходит только после факта сделки. Даже если эта сделка "левая" - скрипт заявку не подавал, а сам юзер вручную, через стаканы что-то там купил или продал. У меня заявка ТОЖЕ может сниматься ещё до факта сделки (либо частично исполненная). Да, "чтобы убить заявку до сделки, нужен order_num", и я его получаю как раз "прямо из таблицы заявок"... чо-то я не понял... что там order_num, а что order_id? Нужен номер заявки для снятия, и он получается либо по OnTrade, либо из таблицы "orders".

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

Алексей, Что делать? Видимо, то же, что и я: почти сразу выбросил OnOrder вообще, не разбираясь в нюансах, как ПОТЕНЦИАЛЬНО глючный, оставил только OnTrade как минимально необходимый. Проблем с order_num ни разу не испытывал.

Alex, Я думаю, это вечный костыль. Идея-то стандартная, ещё из прошлого тысячелетия, называется ОЗУДД (ОЗУ двойного доступа). Например, повесить какую-нить функцию на какой-нить вектор и программным прерыванием по этому вектору делай, что хошь. Но современные операционки уже настолько изуродованы, что кроме как через файл вряд ли что получится.

swerg, Я давно перестал удивляться тому, как искренне изумляется хам, когда получает в ответ той же монетой.А я бы не дополнял. Информационная ценность Вашего "дополнения" равна нулю.Это как раз забота о том, чтобы мир ни в коем случае не улучшался.
КАКИХ "деталей"? Про инкапсуляцию слышали когда-нибудь? Заявлять о проблеме нужно как раз абстрагируясь от всех "деталей". Марка дисковода, тип процессора, тактовая частота - эти "детали" тоже уточнять требуется? Будем отдельный софт писать для обработки "хлеба печёного и мяса варёного"?В ЛЮБЫХ условиях на ЛЮБОЙ бирже, в ЛЮБОМ режиме торгов интерпретируемый код не должен подвешивать Квик. В ЛЮБЫХ условиях не должно быть потери управления по OnStop. В ЛЮБЫХ условиях на одно событие должно быть ОДНО прерывание, а не целая колода. В ЛЮБЫХ условиях свечи должны быть отвязаны от графиков и считаться на сервере или (как заглушка) внутренними утилитами самого Квика. В ЛЮБЫХ условиях не должен пропадать текст в таблицах Квика (кстати, этот случай когда-то был по полочкам разложен именно Старателем, а не Вами, "советчиком").Естественно! Старатель - один из самых въедливых посетителей этого форума, и потому он находит такие ошибки, которые остальным 99% участников вовек не найти.
Да неужели? Примерчик можно? Ну хоть один! Как известно, "краткость - сестра таланта". А вот уродовать изложение кучей второстепенных деталей - это как раз очень вредная штука.  

QApplication, Да мне как-то стандартной sprintf хватает, известной также в Lua под погонялом string.format.  

swerg, Вы и конструктив? Это что-то новенькое. По моим наблюдениям конструктива в постах Старателя в разы больше, чем в Ваших. Если не на порядки.

QApplication, И что за средства такие у С++?    

swerg, Мне насрать на Гугл. Я пробежался по сообщениям службы техподдержки на форуме "Программирование на языке Lua".

Анатолий, Я всё-таки пробежался по сообщениям службы техподдержки. Слова "Ваше пожелание зарегистрировано" встречаются более двухсот раз. Слова же "Ваше пожелание было реализовано в версии X.X.X терминала QUIK" встретились лишь 6 раз. Ещё реже встречается "Ваше пожелание учтено и будет внедрено в ближайших версиях" или "Ваше пожелание не реализовано. При его реализации сообщим Вам в этой ветке форума". Иногда встречаются просто шедевры, например:
Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что реализация пожелания признана потенциально целесообразной. Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить...
Или:
С учётом ограниченного трудового ресурса и критичностью стоящих перед нами задач, к сожалению, вопреки Вашим ожиданиям, не представляется возможным сделать "всё и сразу, хорошо и правильно". Мы вынуждены расставлять соответствующие приоритеты, выделяя из них в первую очередь безусловно приоритетные задачи, критичные для всей системы в целом.
Последний пример - фрагмент обращения лично ко мне

Ну и, наконец, пост одного из пользователей:
Никто не просит вас отчитываться за каждое пожелание, но хотя бы список ближайших внедрений или вообще список, который вы учитываете, можете выложить. В конце концов есть конечный клиент, который написал вам об ошибке или пожелании. Вы присвоили номер, адресно в личном кабинете можно хранить список заявок со статусом и ответами? Это вообще стандартная практика по тех.поддержке по любому проекту. Сейчас все выглядит так, что вы просто делаете отписку в теме в надежде, что она затеряется и забудется за кучей аналогичных и других.
А вот это фиг! Как мне здесь объяснили, "Текущая политика компании в отношении работы с клиентскими пожеланиями не предполагает открытого доступа к списку пожеланий и их статусам. В данном вопросе, в обозримой перспективе каких-либо изменений не предвидится".

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

А редактировать и удалять здесь ничего нельзя.

Анатолий, Лет 20-25 назад я бы поверил, но сейчас-то вероятность разрыва связи "в нужное время в нужном месте" практически нулевая. А при настолько страшных движениях курса, что аж терминал не успевает, производить любые действия просто безумие. Тем более, стоп-лоссом, во время установки которого никто в принципе не мог ничего не знать о таких изменениях.

Никаких "бэктестов" для своего скрипта я ни разу не проводил - отлаживал сразу "в боевых условиях". Результаты более, чем удовлетворительные. Таким образом, экспериментально подтверждено: стоп-лоссы нафиг не нужны!  

Dr Wed, Получить текущую цену инструмента как два пальца о асфальт - никакие свечи для этого не нужны. А вот как получить саму дневную свечу - это вопрос! А связываться с незакрытыми свечами вообще никому не советую.

nikolz, А я полагаю, что останов функции main c помощью sleep вполне нормальное решение разработчиков. Во всяком случае, оно намного лучше некоторых других их решений, про которые я не раз говорил.

Чтобы показать полную ненужность предлагаемого способа никаких тестов не проводил, а тупо заглянул в свои логи - они у меня (на этом компе) ведутся с середины апреля, так я взял период с 1 мая по 31 августа и тупо посчитал количество вызовов коллбеков за всё это время. Получилось 5037 у одного брокера и 2081 у другого. Правда, цифры эти надобно умножить на 3, поскольку прерывания OnTtade приходят пачками, но и в этом случае цифры смехотворно малы. За всё время моей работы в Квике никакой "постоянной активации потока и бесполезной загрузки ядра", равно как и "пропусков завершения работы колбеков" ни разу не заметил. Опять микросекунды ловим? Ну-ну... когда коту делать нечего... Так что "библиотеку" свою засуньте... сами знаете куда.

Анатолий, Да я, честно говоря, вообще не понимаю, зачем нужны стоп-лоссы - здесь же скрипт, и он вроде как постоянно работает. Ну, разве что связь вдруг разорвётся, и именно в этот момент на рынке произойдёт что-то непотребное. Не говоря уже про тейк-профиты. Ну, поставили мы там что-то по своим доморощенным представлениям о поведении рынка, а как он там себя на самом деле поведёт - одному богу известно (да и то вряд ли). Ну, сработает там этот "профит", а рынок, мож, только начал разгоняться, и ещё на 5-10-20% взлетит. Или чирикнет по нашему стоп-лоссу, оставит нас без акций и повернёт вверх. У меня никаких лоссов с профитами вообще нет. Вернее, лосс-то есть, но он динамический - теоретически может двигаться каждые полторы секунды, но двигаться У МЕНЯ. А заявку, когда скрипт посчитает нужным подать, он подаёт всегда по LAST или даже по BID или OFFER. Кстати, заодно снимаются все проблемы с шагом цены - какая бы она ни была, у любого из этих трёх параметров с шагов всё в порядке.

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

Какой ещё хернёй этот форум не загажен?

Незнайка, Вам нужно удалить файл? Так используйте, блин, ту последовательность, которая работает! Тем более, что Вы её знаете.

Функция обрезки концевых нулей здесь не раз приводилась. Прекрасно работает и для целых, и для дробных значений.

Anton, Дык бабло можно много на чём поднимать, но я лично предпочитаю на своих прыгающих свечах.  

Anton, Нет уж, ничего скользящего - только прыгающее. Пока очередная свеча не накоплена, смотрим на предыдущую. Тогда, возможно, помогут и от геморроя.

BlaZed,
https://forum.quik.ru/messages/forum10/message57616/topic6614/#message57616

Anton, Я о Квике. У меня никогда не было ни малейших сомнений, что свечи считаются на сервере, но, как мне тут популярно объяснили, считаются они на клиенте из таблицы обезличенных сделок.

Из тиков МОЖНО построить любые агрегаты. Ну так и стройте их НА СЕРВЕРЕ! А на клиента транслируйте уже готовые "агрегаты". И на сеть нагрузка будет намного меньше, и процессоры клиентские не придётся забивать дурацкой работой.

А здесь и спорить нечего: нормальные решения по тикам принимать практически невозможно - нужны именно свечи. Аксиома!  

swerg, Лапуль, доставать свечи из графиков - это ИДИОТИЗМ! Считать их на клиенте - это тоже идиотизм, но помельче. Что, прикажете мне полторы тыщи графиков заказывать, чтобы получить по одной сраной свече с каждого? Или лопатить месячный массив тиков, чтобы получить также одну сраную свечу? И вообще, всё о Вашей квалификации я давно сказал. Вот здесь:
https://forum.quik.ru/messages/forum10/message52413/topic6201/#message52413

swerg, О! Ещё один умник нарисовался. Это, по-моему, "второй". Или даже "первый".  

Anton, Какие такие "все клиенты локальные"?! Тики идут с сервера, а свечи считаются на каждом клиенте. У меня просто челюсть отвисла, когда я об этом узнал. Кому и на кой нужна эта "база тиков"? Разве что этому дурацкому HFT, а нормальные решения по ним принимать практически невозможно - нужны именно свечи. И при чём тут "порисовать"? Мне вот нужно порядка 12 000 свечей (от 15-минутных до месячных - мелочь я считаю сам), и объём у них не "ужатых десяток мегов", да ещё ноухавно ужатых, а распакованных сотня кило. И никаких графиков! Получать к ним доступ через графики - это даже не "только приключений искать", а Полная Жопа!

nikolz, Лапуль, ежу понятно, что "у Вас нет проблем" - Вы же НИЧЕГО не умеете! Какая, в задницу, могёт быть "помощь" от распальцованного полуграмотного неуча, которому я ещё 16.10.2020 08:43:39 писал: "Учите матчасть"? А 30.10.2020 13:46:16 писал: "Открываем книжицу "Руководство пользователя" от ARQA - так там буквально в названии чёрным по белому: "ИНТЕРПРЕТАТОР языка Lua". VM, да будет Вам известно, это ТОЖЕ интерпретатор! А 31.10.2020 12:35:26 писал: "Может, хватит, господа? Сначала один нёс какую-то клиническую ахинею про "роботов и всякие прочие глупости", да ещё с гнутыми пальцами вроде "вы даже понимаете суть вопроса". Получил щелчок по носу - теперь чего-то шипит про "троллей". Потом второй начал пальцы гнуть на тему API в том же ключе: "По-моему вы ничего не понимаете", да про int-float ("Как бы по мягче сказать, что вы не разбираетесь в теме. Повторю в квике 7, lua 5.1 - в нем не числа хранятся типом double, соответственно нельзя хранить int64"), да про "не надо путать стек процессора и стек Lua - это разные стеки. Вам бы документацию почитать и хорошенько разобраться в луа", да про "выучи английский", да про "умение читать документацию и гуглить", после чего вообще забился в истерике. Потом третий понёс пургу про "монстров фондового рынка", и тоже с гнутыми пальцами: "Вы еще далеки от понимания реальности фондовых рынков" и совсем уж клинический бред с ещё большей распальцовкой: "вот некоторые из аксиом, которые надо усвоить и научится программировать", затем бред про мантиссы ("для справки: Разрядность мантиссы в 64 битном вещественном числе составляет 52 бита, что  позволяет точно отобразить лишь 16 разрядное десятичное целое число, а не  18 квинтиллионов, как наивно полагает Владимир"), затем про "это VM а не интерпретатор", и тоже с истерикой: " в языках и виртуальных машинах вы ноль без палочки"... я прям утомился этому неучу по носу щёлкать!" Если забыли, то "третий" - это как раз Вы, лапуль.

В общем, надоело листать: Последнее, что попалось на глаза из моих обращений к Вам, датировано 04.08.2021 13:57:04: "Что, сегодня в Кащенко день открытых дверей?". Да 16.08.2021 12:47:16: "Лапуль, ну хватит напрашиваться! Ну ведь растопчу и проглочу, как это уже не раз бывало. У нас просто разные весовые категории".

Anton, Что такое твс? Тепловыделяющая сборка? Трансформатор выходной строчный? Трансмиссивная венерическая саркома?

Ну ведь это МАРАЗМ строить свечи на лету из тиков! Гонять огромные объёмы данных на каждого клиента, и на каждом из них (хорошо, если одинаково!) получать из этих данных другие, меньшие по объёму на несколько порядков! А если обрыв связи? А если я уеду на рыбалку дня на три, и комп не возьму с собой? А получать свечи из графиков - это я даже не знаю, как назвать - даже матерные слова здесь слабоваты. У меня, блин, полторы тысячи тикеров на контроле, у каждого полтора десятка таймфреймов. И чо делать? Наконец, классические мат.ожидание и дисперсия в тыщу раз информативнее всей этой дурацкой "японистости".

Я тоже строю свои свечи, но не из тиков, а просто опрашиваю ТТТ (LAST) раз в полторы секунды. Лог у меня тоже ведётся, и никакие СМС нафиг не нужны. Да и просто свихнёшься: у меня обычно несколько десятков сделок в сутки - иногда больше, иногда меньше, и всей этой колодой бомбардировать мой телефон - упаси, Господи!

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

nikolz, Лапуль, Ваша информационная ценность для меня просто РАВНА нулю. Ну, расскажите, коль неймётся, как Вы будете получать дневные, недельные и месячные свечи - посмеёмся...

Anton, Я догадываюсь - я же не первый год программирую.   Но сути это не меняет: это по-прежнему простенькая прикладная задача и по-прежнему с поганым языком и поганым интерфейсом. Но функциональность по-прежнему ДОСТАТОЧНАЯ для организации торговли. Что до "внешних длл по дизайну" - а зачем они нужны? Дизайн на таблицах Квика и всяких там SetTableNotificationCallback более, чем удовлетворительный - хрен такой получишь от этих внешних длл! А роботу, по большому счёту, это вообще не нужно. Только вот со свечами какой-то тихий ужас творится.

А я решил проблему через использование ОДНОГО скрипта на все случаи жизни и минимально необходимого количества коллбеков (по сути, один только OnTrade, да обработчики событий от юзера). Чуть не половина веток этого форума посвящена этим несчастным потокам. Между тем форум посвящён организации автоматической торговли с помощью терминала QUIK, да ещё и на языке Lua. То бишь простенькой прикладной задаче. Не занимайтесь хернёй, господа! Ах, да - а вторая половина веток посвящена ловле этих несчастных миллисекунд - ещё одна разновидность онанизма.

Roman Azarov, О, чёрт! Где были мои глаза? Спасибо!

Ох, ни хрена себе! Так свечи считаются НА КЛИЕНТЕ?! И месячные тоже?! Да как же такое возможно? А если даже так - тем более: если вы сами считаете свечи, так и засуньте их в какую-нибудь таблицу! Это же ужам какой-то, доставать свечи из графика!

Roman Azarov, О! Неужели? Спасибо!

а) Так... ну, getMoney меня уж точно не интересует... getDepo... не понимаю - тут тоже нифига нет... getPortfolioInfo... Господи, чего тут только нет, кроме того, что требуется... нахрена мне все эти "оценки стоимости"? Мне нужно узнать, сколько у меня лотов (ну или акций) по каждой позиции, которая есть в портфеле. А здесь что? Какой-то набор совершенно бесполезных цифирей.

б) Как это "никак", если на любом сайте, связанном с торговлей, этих свечей как собак нерезаных, всех мастей и размеров, и хранятся они там годами, если не десятилетиями? И при чём тут "свечи текущей торговой сессии"? А недельные? Месячные? А к ТТТ они имеют самое прямое отношение: перечень тикеров, интересующих юзера, настраивается именно в ТТТ, а Квик всё время ведёт весьма интенсивный обмен данными с сервером. И что, трудно заодно и свечки прихватить? В плане траффика это вообще ничего не стоит! А что, ваш CreateDataSource тоже получает свечи, сгенерённые терминалом на основании потока обезличенных сделок"?

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

Pavel, Писать и пробовать! Пока деньги есть.

Никаких альтернатив Quick + Qlua не существует. Точнее, я категорически не рекомендую их искать. Лично я пишу на девственно чистом Lua, чего и другим советую.