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

Ошибочка в ссылке. Мой подход: https://quik2dde.ru/viewtopic.php?id=18

Тут я кажется кое-что пряснил для себя. Вы, видимо используете этот подход: https://forum.quik.ru/forum10/topic7971/, тем более сами писали. Я правильно понял? Я использую этот подход: https://forum.quik.ru/forum10/topic7971/
Хотелось бы решить задачу в своём подходе.

nikolz, у Вас что за функции nkcf.defF и rfs ? Какой их код, что они вызывают API винды? И Вы их вызываете прямо из скрипта, а я API прямо из DLL на C.

Да я по всякому уже перепробовал, пробовал я и W варант и A вариант MessageBox-а, и просто коды букв вставлял для cp1251 из таблицы символов. Ни так, ни как не выводят по русски. Скрины:

Попробую поднять данную тему вновь. Вобщем всё что выше написано - не работает Библиотека не выгружается!. Библиотека на C++. Выше писали, что типа если на чистом C++ то выгружается нормально. Не выгружается. Есть ли ещё какой способ выгрузить свою же DLL, которую Lua выгружать почему-то не хочет. Странное вообще какое-то поведение Lua. Скрипт отработал, библиотека - осталась. Функций в Lua для выгрузки не нашёл, что тоже довольно таки странно. Загружать значит можно, выгружать нет. Приходится постоянно перезагружать QUIK, чтобы удалить файл DLL, поскольку система не даёт его удалить, пока библиотека используется Lua. А удалять файл надо, чтобы после перекомпиляции DLL, новый DLL-файл записать на место  того, что надо удалить. Это сильно напрягает поскольку сам QUIK грузится не быстро. Сталкивался кто с таким? Как ещё можно решить пролему? Ведь библиотека же чисто моя, зачем она вообще удерживается Lua - не понятно. Закончился скрипт без ошибок - освободи, но нет. Уж не знаю как решить, думаю уже как-то искать ID библиотеки, ну или там хэндл какой и выгружать отдельно программой через API винды.

Аааа, я ещё что-то сразу то не приметил. nikolz, Вы  на скрине показываете окно сообщений самого квика. Мои скрипты в это окно пишут по-русски нормально. Я писал не про это окно. У меня DLL. Скрипт вызывает её функции. Эти функции например вызывают MessageBox виндовую для вызова окна сообщенй винды с русским текстом. И вот оно то пишет не по-русски. Вот в этом проблема. А с простым message в скрипте проблем нет - сохраняю с русскими сообщениями как ANSI и проблем нет. Вобщем сама винда перестаёт по-русски писать в своём же сообщении, хотя если вызывать  не из библиотеки DLL под QUIK, а просто из программы под винду, то пишет по-русски как положено. И ещё. Из DLL в этом окне только само сообщение абракадаброй выводится, а вот кнопки "Да", "Нет" - они нормально по-русски подписаны.

nikolz, вот я и не пойму толком ничего. Винда 10. У винды с 10-ой версии вроде что-то там как-то поменялось. Толи на юникод на какой-то другой перешли, толи ещё что. Наверное был до этого юникод 2-х байтовый(наверное u16), а сейчас полный u8(8 - это не биты) - так наверное. У Вас какая винда, что проблем нет? Блин, локаль показывает ru-Ru, что пользователя, что системы, в вызове из DLL - локаль C. Ну вроде же сменил локаль, потом вывел, нет всё равно на нерусском пишет. Думаю поди надо ещё в этой локали кодировку(чарактер сет) сменить. Буду пробовать. Но это потом, пока это не критично, надо главные функции писать.

За столько времени так никто и не ответил. Поддержка может хоть что-нибудь подсказать в решении проблемы? Мой вывод : в контексте толи потока QUIK, толь в Lua, локаль меняется с ru-Ru на локаль C, а в ней видимо русских букв вообще нету. Поэтому хоть что ты пиши, хоть кодируй текст - всё равно толку не будет, так как его попросту в чарактер сет(кодировке) нет как такового. Но почему не получается сначала  сохранить локаль C, потом установить родную локаль, вывести текст, потом локаь C вернуть обратно - не пойму.

Попробовал .cpp файл открыть в проводнике виновс и сохранить его в ANSI, как сохраняю скрипты под Lua, но при загрузке в Visual Studio C++ студия отображает русские символы как положено, т.е. перекодирует под себя. Раньше как то пользовался таким способом только в других ситуациях и помогало - при загрузке отображались иероглифы, но например в консоль шло то что надо.

Возникла проблема. Нас C написал библиотеку DLL. В ней функция для вызова из скрипта Lua. Библиотека подгружается, функция вызывается и нормально работает. Эта функция создаёт окна в отдельных потоках Windows, окна выводят cтроковую информацию API функциями Windоows(OutputDebugString, MessageBox), которые естественно корректно выводят русский текст при работе в простом приложении, но в DLL они выдают полную хрень из-за разных кодировок в среде Windows по умолчанию и в QUIK. Пробовал перед вызовом функций устанавливать локали по умолчанию через GetUserDefaultLocaleName и GetSystemDefaultLocaleName(обе возвращают "ru-Ru", а QUIK через _wsetlocale(LC_ALL, NULL) даёт локаль "C"), а потом вызывать функции вывода информации, после чего обратно возвращал локаль "C", чтобы QUIK работал не замечая временную смену локали. Не помогло!!! Как можно ещё выкрутиться? Изначально указать компилятору как-то(как?) закодить русский текст в кодировке QUIK-а? Писать строки через "\код" - не вариант, да и коды надо как-то генерить в кодировке QUIK-а. Пока что-то совсем на ум ничего не идёт.

О, здесь когда цитировал строки Владимира, видимо нажал Цитировать не в том месте и получилось, что я писал, а не Владимир, но по сути вопрос задан. А с потоками придётся позаниматься.

Как запускается скрипт? чем? И как понять в потоке из пула? Тут как то можно использовать функции lua для запуска функций в отдельном потоке?(если таковые есть в lua, просто lua глубоко не изучал).

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

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

Вы немного не так поняли мой вопрос. Наверное я так написал неоднозначно. Я имел ввиду, что Ваш робот в процессе работы может попасть в такую ситуацию, когда он например сделает покупку, а потом (нужно соответственно сделать продажу) продажа ну никак не получается, потому что цена пошла не в сторону, которую предположил робот, т.е. робот никак не может закрыть сделку находясь в ожидании подходящего момента для продажи(ждёт нужную цену), а момент этот ну никак не наступает. Про это я написал типа "завис", не имея ввиду программное зависание как таковое. Хотя и Ваш ответ проинформировал об интересных моментах, что не лишне. А посему спросил, если бывают такие "зависы", то как робот их решает? Продаёт в убыток по стопу или ждёт таки момента неизвестное количество времени? Хорошо, когда отроботал и закрыл предыдущую сделку, например покупки, продажей, а если нет? Если цена всё никак не хочет "подстроиться" под алгоритм робота? Ждать или продавать в убыток? Если продавать в убыток, каково %-ное соотношение угадал-не угадал? Типа какой КПД прибыльных сделок? Если прибыльные все на 100%, то это достигается только ожиданиями, которые могут уйти в бесконечность.

Или условного стопа с лимитной заявкой или как-то так.?

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

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

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

Да, сложный у Вас робот. Каа Вы пишите - единственный на все случаи жизни, его постоянно совершенствуете? Алгоритм меняется? Данные меняете? Не может же он быть универсальным.

Мне и не надо полного синхронизма. У меня диапазон времени в пределах минут как писал выше. Если робот, то просто ждёт когда появится нужный "большой" разрыв (если судить по графику) и чтобы были соответствующие минимальные объёмы. Если вручную, то визуально смотрю на графики и сам принимаю решения, что "пора" выставить заявку.

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

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

Может HFT так и работают. У меня нет тенденции словить что-то в малых диапазонах времени. Как и описал выше тенденция она нарастает со временем, длится не мс, а минуты, времени для принятия решения предостаточно. А игратся в пределах миллисекунд, так там такое изменение цены маленькое будет на купил-продал или наоборот, что и комиссии брокера не оправдает.

В части того, что прогноз будущего - да, без прогноза заявку вообще никто не делает, ни робот, ни человек, а вот в части того, что с горизонтом в мс - нет. Это так кажется, что стакан быстро и динамично меняется. Меняется то он меняется, быстро меняется в основном его часть, которая на стыке bid-offer, остальная часть стакана намного более статична и эти статичные части в bid и в offer просто скользят по стакану вверх-вниз. А вот следить надо не за быстроменяющейся частью стакана, а именно за более статичными. От того как они меняются и в каком направлении, от того и зависит тренд. Эта их бОльшая относительная статичность никакие не миллисекунды, она минуты длится, а то и в переделах пол часа - час. Когда сопротивляются повышению цены - в стакан прям начинают заваливать заявками на продажу с крупными объёмами, как натиск спадает, так и заявки такие резко уходят из стакана, тоже самое и в отношении поддержки, не дают цене уйти вниз своими крупными заявками. Но тут надо учитывать не только перевес одних над другими, но и общие объёмы и тех и тех, и объём торгов, и пару графиков сразу, а не только скажем фьючерса, нужно учитывать и изменение базы. Да и вообще интересно смотреть как меняются стаканы во времени того же фьючерс например относительно базы.

Нет. У меня абсолютно совершенно другое. К аллигатору никакого отношения и близко не имеет. Аллигатор, тот анализирует прошлое, т.е. прошлые свечи для построения 3-х скользящих на разных периодах, каждая из которых имеет свой сдвиг вперёд на своё количество. Я вообще свечи игнорирую и у меня 2-е кривых, данные из реального времени - построение кривых в момент прихода свечи без её анализа, в расчёте только данные из стакана, т.е. я за точку отсчёта просто беру приход свечи и считаю стакан в обоих направлениях.

На каком принципе основан Ваш робот если не секрет конечно? Я прошу написать без подробностей и нюансов, а просто на пальцах для понимания сути. Ведь на основании чего-то же он срабатывает? Чего? Понятное дело, что в 2-х словах весь алгоритм описать сложно, но всё же... Можно намекнуть без секретов? Хотя бы понять в чём идея алгоритма?

Рынок он динамичный и робот должен быть динамичным. Это самая сложная задача. Не знаю какие там нейронные сети что могут, но думаю, что сети эти пишет человек и по своему уму и всякое там обучение тоже основано на алгоритмах, которые пишет человек, универсального алгоритма обучения нет. Поэтому заморачиваться и писать самообучающийся робот - это какая-то неимоверная задача, и робот будет без конца расти в размере всё больше и больше и постоянно писать его как самообучающийся неимоверно сложно, запаришься такое писать. А доверять сторонним алгоритмам это так себе идея. Вот поэтому за обучение нужно отвечать самому, анализирую рынок, тесты скриптов, стаканы и прочее и всё это закладывать в разные алгоритмы, которые снабжать разными данными. Всё гениальное просто на самом деле, не надо шибко всё усложнять.

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

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

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

Вот;

Просто файл .jpg тут вставить нельзя?

Через ссылку не получается.

Не понял как правильно файл .jpg тут отправить через Изображение?

Хотел картинку вставить, видимо как-то по другому надо вставлять. Сейчас переделаю попробую.

Вот например прям сейчас заскринил:
[img]file:///C:/Users/extma/Downloads/Screenshot_5.jpg[/img]

Если не забуду и поймаю такую "тенденцию" - покажу здесь скрин и результат.

Спорить ни с кем не буду. У каждого своё мнение. nikolz: "Поэтому без прошлого нельзя прогнозировать будущее" - здесь скажу, что прогнозировать без прошлого конечно нельзя, ибо вообще тогда и прогнозировать-то по сути нечего будет, но один хрен точно спрогнозировать это прошлое всё равно не поможет, будущее будет не таким как прогнозы в 99% случаев, а то  и больше. Владимир: "Суходрочка в стакане и вообще HFT является лучшим доказательством отсутствия нормального алгоритма торговли." - тут по поводу HFT не знаю вообще ничего, а индикаторы рисуют графики по стаканам в качестве тестирования, мониторинга ситуации в течении  дня, анализируются мной(не роботом, не индикатором) пары - и базовый актив и фьючер одновременно на разных графиках, тенденции они показывают чётко, например приближение к поддержке или сопротивлению существующим или новым(графики с линиями этого не покажут или покажут ложные[исходя из "старых" данных]), практически с ооооочень высокой вероятностью! Решения на покупки-продажи принимаются не роботом в этом случае, не индикатором, а вручную после анализа. Пока ни разу не подводил такой подход. Всё в пределах дня в основном.

Вообще эти свечи все "старые", как и вообще весь этот ТА как по мне, так это всё ерунда. Что бы там не рисовал нам ТА, рано или поздно он соврёт. Анализировать конечно можно, но нужен чисто свой ТА, котрый будет работать по набору чисто твоих данных, которые могут динамически менятся во времени от разных ситуаций, да и сам алгоритм ТА нужно постоянно менять под меняющийся рынок. Только так ТА будет работать. Но это такие сложности постоянно обновлять входящие данные и их количество и постоянно корректировать код(и то только после определённого слежения за рынком), а как поменяется код, то нет никаких гарантий, что рынок не изменится и код будет рабочим определённое время. Вобщем ТА не вариант в плане свечей и графиков прошлых цен, вернее вариант, но очень сложный, требующий постоянной корректировки скрипта. А вот анализ стакана может помочь при дневных сделках и общем анализе ситуации на рынке если мониторить несколько инструментов например основных фишек индекса.

Да в этом индикаторе нет никаких циклов вообще, он наипростейший до немогу. Мне по сути то вообще и свечи эти не нужны и считать мне по ним ничего не надо. Мне надо было в реальном времени отображать 2 объёма в стакане - для BID и OFFER для инструмента. И чтобы эти объёмы  в виде кривых соотносились с графиком инструмента. Т.е. я OnCalculate() просто использую как функцию для расчёта в реальном времени этих нужных мне объёмов. Свечи как таковые с их данными просто игнорирую. Резульаты расчёта 2-х объёмов вывожу через return. Расчёт каждого объёма по любому в цикле, так как надо же пробежаться по стакану.

Этот Size() я ранее вызывал в Init. При загрузке индикатора он показывает последний индекс последней свечи. При загрузке квика ещё до логина с сервером если Size() остаётся в Init, то он возвращает НОЛЬ! А при ноле логика скрипта не работает. OnCalculate делает проверку индекса свечи с сохранённым Size(), чтобы отбросить всё что меньше, а там ноль. Поэтому, чтобы не менять логику с Init убрал Size() и начинаю его вызывать только после isConnected() == 1 и только 1 раз внутри OnCalculate(1 раз чтобы  - использую флаг true/false). Так логика остаётся прежней и Size() возвращает уже не ноль. Хотя как вариант с первого пробега по свечам можно брать последнее максимальное значение(при этом возвращая везде nil), а при втором прогоне откидывать все свечи до максимальной с первого прогона так же возвращая везде nil, а потом уже начинать обрабатывать новые свечи, но так логика кода будет совсем иной(по Вашему примеру как-то так). Да, и ещё про 2 прогона, что Вы пишете - это когда индикатор грузится на график, а если загружается квик, то сначала идёт 2 прогона до одного максимального значения каждый, а потом после коннекта с сервером(ввод логин/пароля) происходит ещё 2 прогона и только последний, т.е. фактически 4-й по счёту начинает считать новые свечи с сервера.

Вернее индикатор(код) один, а на инструменты разные код в начале прописан, вот и получается, что если хочу установить на новый инструмент, то в начале меняю код инструментов ClassCode, SecCode, а остальной код оставляю как есть. Поэтому плодиться скрипты могут по мере того, что мне надо. Хотя вот думаю надо универсальный сделать через getDataSourceInfo().

Как вариант можно да, если один индикатор. У меня несколько, поэтому проще думаю переименовать LuaIndicators. В любом случае индикаторы не загрузятся. Но лучше конечно, чтобы они загружались и исправно работали.

А на счёт замыканий я раньше и не слыхал. Может в интерпретируемых языках такое есть? Типа Lua, Pyton и прочих? На си так вообще никаких проблем с такими переменными нет. Передал в функцию переменные не явно, а по ссылке, или просто их адреса(что с точки зрения компиляции одно и тоже фактически будет) и все дела. Явные то переменные через стек в функцию попадают, после выхода из функции стек режется и переменные пропадают, а по ссылке или через адрес функция обращается к ним не через стек, а через косвенную адресацию. Поэтому эти переменные при выходе из функции сохранятся после их изменения внутри функции. Может из-за того, что интерпретируемые языки так не могут ввиду их простоты, поэтому и ввсели эти замыкания. Но это только догадки. Пока я сам в смысл этих замыканий ещё не вникал, не читал ещё.

1) Про замыкания возник вопрос из-за того, что у кваика есть справочный .pdf файл "Использование Lua в Рабочем месте QUIK.pdf" в C:\Open_Broker_QUIK\Doc\Lua, в нём есть п. 3.7 "Расчёт EMA" и там написано: "Нет возможности обратиться напрямую к предыдущим рассчитанным значениям индикатора.
Это значит, что для вычислений текущего значения необходимо хранить и предыдущие
значения. Для таких целей в Lua используется механизм замыканий. Определение такой
функции нужно вынести в отдельный файл и в отдельный каталог, который не сканируется
при создании индикатора."
И далее идут примеры, функции, возвращающие функции(короче замыкания как я понял). Они используются именно для индикаторов. В чём там прикол, я так и не понял. Можно тоже самое написать и не использовать возврат функции в функции(замыкания). Что они хотели этим показать я не понял. И зачем это всё в отдельный каталог, который не сканирует квик при создании индикатора? Зачем весь этот изврат с каталогами, dofile и замыканиями в придачу???
2) Это да согласен, что i c Size() надо тогда сравнивать, это так. Просто у меня сначала скрипт начинался с того, что в init сначала запоминал Size(), а в OnCalculate() отбрасывал всё, что меньше Size(), повторные свечи >= Size() тоже обрабытывал, для меня это не важно было. Вобщем такой скрипт при загрузке на индикатор нормально загружался и работал без проблем, рисовал кривые мои 2 шт в отдельной области. Проблема возникла только тогда, когда я выходил из квика, повторно запускал квик и вот тут то квик у меня вообще начал зависать, вернее в цикле без конца то подключится к серверу, то отключится, при этом куча окон всяких на экран выдаёт, в сам квик войти невозможно стало. А чтобы зайти нужно было как то отключить индикаторы. Я даже по началу вообще не понял, что в этом виноваты мои индикаторы, так как проблема то явно выглядела как подключения-отключения к серверу. Потом дошло, что могут влиять на это индикаторы. А как их отключить то если квик не запускается. Вот пришлось переименовывать папку с индикаторами, чтобы квик при загрузке их не находил. Папку переименовал, в квик стал заходить, ну иначал искать причину чё к чему. Выяснил, что квик этот почему-то еще до коннекта с сервером по паролю 2 раза(зачем 2 не знаю, только разрабам видно известно) пробегает по свечам по всем начиная с первой, потом после второго прогона останавливается и пока не залогинишься более никакие свечи не прогоняет. Потом как залогинишься квик опять таки ещё 2 раза опять заного пробегает по всем свечам(точно так же как и до залогинивания) но потом уже начинает и дальше свечи обрабатывать, что новые грузит. Так вот в самый первый раз до залогинивания Size() выдаёт почему-то 0(ноль) Ха - ха - ха Ноль, а не то что надо - максимальный индекс свечи. Отсюда получалось то, что даже при закрузке квика(после переименования папки с индикаторами)  и при работающем квике если название папки с индикаторами вернуть обратно, то индикаторы то всё равно не заработают на открытых графиках, а чтобы заработали надо зайти в график, удалить их и заного загрузить на график, только тогда квик их загрузит из папки. Ну а потом я эту проблему решил как описал выше через isConnected() и подкорректировал всю логику индикатора, убрав Size() из Init. Просто вычислений на свечу видимо много было и квик так долго всё обсчитывал и обсчитывал, что не догонял чё так долго то и разрывал соединение установленое с сервером, потом опять по кругу - подключался, считал, отключался и т.д. и т.п. Потом, когда сделал так, что Size() начал мне выдавать нормальное значение вместо ноля, квик стал подключаться, так как все свечи до логина мой индикатор считал в nil, а потом отсчитыал только свечи новые, видимо так как новые то идут не так часто, квику хватает времени и на свою работу и на просчёт свечей. Всё стало работать. А так то это их косяк - почему Size() выдаёт ноль если он в Init и квик загружается с существующим ранее индикатором? Ведь всечи то есть и он их прогоняет до какого-то значения аж 2 раза. Почему же тогда Size() не возвращает это значение? Вот в этом и косяк. Не будь его всё бы работало и в процессе загрузки на индикатор и после перзагрузки, ан нет, пришлось извращаться и корректировать код.

1) Посмотрю. Вникну подробнее. Мельком глянул - ничего с наскоку не понял. Для чего эти замыкания в квике в индикаторах? Если можно на пальцах, хоть кратко, просто для того, чтобы уловить суть необходимости.
2) Не, мне так не пойдёт. Это отсекёт повторы если будут, а так то всё-равно все свечи пробегать будет. А мне надо, чтобы "старые"(до момента коннекта) все отбрасывались. Я в принципе уже нашёл решение как это сделать, хотя и Size()
в Init возвращает 0 при запуске квика с индикаторами. Вызыываю Size() только после коннекта с сервером и только 1 раз, чтобы зафиксировать значение и обрабатываю свечи > этого значения только. Несколько вызовов на 1 свечу мне не страшно, пусть будут, график рисует как надо. А так то да, можно использовать, чтобы одну свечу 1 раз только вызывать, может и заиспользую.

Не нужные мне свечки ранее отсекал сохранение значения через вызов функции Size(), обрабатывал только вновь пришедшие свечи. При загрузке индикатора такое работало. После перзагрузки Size() внутри Init возвращает 0, буду пробовать выкручиваться, может отсекать свечи до подключения и после подключения? Попробую, а то виснет же - видимо много считает и считает при загрузке.

Вобщем сейчас долго тестит-тестил. Оказалось, что простейший индикатор всё-таки свечки новые вызывают вызов функции OnCalculate. Просто новых выводов функции PrintDbgStr в окне DebugView не было видно, что они появляются снизу как и положено видимо потому, что очень много инфоормации в окне накопилось и чтобы их увидеть, что они действительно пиишли надо было понажимать PageDown клавишу и тогда их видно новые, а я мышкой пытался двигать позунок вниз и ничего не происходило, чтобы мышкой двинуть оказывается надо сначала вверх ползунок двинуть, а потом вниз до конца - только тогда окно отображет последние выводы, а если только ползунок вниз до конца, то так не катит, такие особенности вот, ктоб знал, что у них так, раньше всегда  просто вниз ползунок и всё видно что последнее в окно пришло.

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