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

надо сперва запомнить, как правильно пишуться контракты, а потом уже торговать ими :) ))

Sim5 vs SIM5 -> почувствуйте разницу :) )))))))))))))))))

-------
http://moex.com/ru/contract.aspx?code=SiM5

в справке всё есть:
Баланс. ст-ть Стоимость текущей позиции по балансовой цене Значение рассчитывается следующим образом:
Баланс. цена * Позиция.
Для облигаций: (Баланс. цена * Номинал / 100 + НКД) * Позиция .
Для срочных контрактов:
Баланс. цена * Позиция * Стоимость шага цены / Шаг цены
Не заполняется * Стоимость Стоимость позиции по текущей цене Значение рассчитывается следующим образом:
Цена * Позиция.
Для облигаций: (Цена * Номинал / 100 + НКД) * Позиция .
Для срочных контрактов значение рассчитывается следующим образом:
Цена * Позиция * стоимость шага цены / шаг цены
Значение параметра Позиция. Если найден кросс-курс, то значение пересчитывается по курсу в выбранной валюте * % активов Доля стоимости позиции по активу в общей стоимости активов, без учета денег Шорты берутся без знака «0» * Ликв.стоимость Стоимость позиции по ликвидационной цене Значение рассчитывается следующим образом:
Ликв.цена * Позиция.
Для облигаций: (Ликв. цена * Номинал / 100 + НКД) * Позиция .
Для срочных контрактов значение рассчитывается следующим образом:
Ликв.цена * Позиция * стоимость шага цены / шаг цены
Позиция в выбранной валюте * Нереал. PL Прибыль, возникающая при закрытии позиции Значение рассчитывается следующим образом:
Ликв. стоимость – Баланс. ст-ть Не заполняется НПриб.% Прибыль в % к затратам Значение рассчитывается следующим образом:
Нереал. PL / Баланс.ст-ть*100 Не заполняется

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

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

остаётся лишь повторить один из "слоганов":

QLUA это не способ достижения результата, а средство для увлекательного процесса угадывания. :))))))))))))))))))))))))))

я, конечно, извиняюсь но, я чот никак не пойму: причём здесь шлюз plazaII с его роутерами 2 и какой-то непонятной документацией?
есть квиковская функция sendtransaction и в квиковской справке к ней - должно быть всё указано, как ей пользоваться и все возможные к ней параметры. НО! что мы видим? нас опять куда-то отправляют читать какую-то инфу, которую мы должны иметь изначально в своем справочном файле.

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

:) )))))гугл уже всё подсчитал во, что это обернётся :) ))))))

а точнее, уже "вшортил" :)))))))

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

всё понятно. не буду больше комментировать посты с вашим участием.

присоединяюсь - тоже это замечал. но не могу понять причину такого поведения. Michael Bulychev - Вам слово.
получается при потере фокуса окна скрипта (и то, не во всех случаях) - LUA VM ведёт себя непредсказуемым образом. Обычно такое зависание происходит в момент входа в критическую секцию (или в её теле) и вытекающую из этого непредсказуемость поведения всей системы (т.к. это основная обратная сторона медали использования критических секций).

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

p.s. вы никак не поймёте - по отдельности, им (разработчикам) - на  нас по-большому счёту ... (ну выпоняли...). Мы, хоть и являемся конечными пользователями их, как бы м-м э... так называемого продукта но, для нас он бесплатен. покупают его брокеры и, по идее именно они должны всё это требовать - но им, в силу микроскопичности нашего рынка и отсутствии здоровой конкуренции, как у них самих, так и у разработчиков квика - на это тоже ... (ну вы поняли...). Однако, только объединившись - мы сможем добиться своего.
в данный момент, получается когда хочешь, что-то предложить - наталкиваешься на типичный троллинг от разработчиков. на простые вещи и разжёванные истины они отвечают стандартными заученными фразами/формулировками:

• не понимаю о чём вы говорите
• о чём собственно речь
  

и т.п.

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

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

да, вот теперь, наверно, соглашусь.

http://www.freepascal.org/docs-html/prog/progsu4.html

Я, конечно, не спорю но, если можно, приведите примеры когда это имеет большое значение?

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

http://lua-users.org/wiki/StringLibraryTutorial
http://lua-users.org/wiki/PatternsTutorial
:)))

ага. и я про тоже :) )
http://www.dependencywalker.com/faq.html

скорей всего потому, что она подключается через функцию winapi LoadLibrary.

была бы не потеме если у нас в квике была своя штатная vcl. и она у вас есть (qlistdll, qctrls) - но вы её нам не даёте использовать, ограничивая только применением таблиц.
проблема описана выше, конкретно описана.

т.е. суть такая: если qchart.dll и моя lua-библиотека работают в одном потоке - то стало быть со стороны квика УЖЕ присутствует messageloop и мне ненадо ничего выдумывать/дублировать - мои окна итак будут своевременно получать сообщения из очереди.

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

т.е. имеется ввиду не использование vcl или mfc, а напрямую задействуя winapi и gdi. и уже на основе этих примитивов строя свои классы и контролы.

а что тут может быть непонятного? есть функции CreatePen, LineTo, MoveTo, GetDC и т. п.

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

нет, нельзя и врядли предвидется, т.к. устанавливая таймфрейм на индикаторе - мы тем самым заказываем у квика совершенно определённый источник данных и с определёнными параметрами. именно поэтому кнопка смены таймфрейма находится в самом квике, а не встроена в окно графика. к тому же, если всё же сделать так называемый "multitime" - то неясно по какому источнику рисовать/синхронизировать шкалу абсцисс.
С другой стороны, нельзя сказать, что это невозможно. это просто одна из реализаций общего подхода, которую выбрали разработчики qchart.dll. Но, не единственно возможная. Уже сейчас их плагин поддерживает слои отображения (правда "их" понятие слоёв - весьма "специфическое"). В общем, как было сказано выше - если не пинать разработчиков - то нельзя, - либо, писать самому.

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

точные замеры тут не имеют смысла.

это справедливо на случай форс-мажора, т.е. при зависании одного из тредов. поэтому и называется гарантированное переключение. но, как показывает практика, никем это и нигде не гарантируется, так что в реальности и цифра 5 тут тоже условна.

Ладно. не хотите так - вот вам линк-> ask Big Bill

графики в квике - это окна. Чтобы нарисовать свечу в окне нужно одновременно задействовать порядка 10-ти объектов GDI (карандаши, кисти, регионы и т. д. и т. п.). Существует ограничение по числу объектов GDI на один контекст и уж тем более на одно окно-график.
А теперь, умножьте количество объектов GDI на 3000. И это, не говоря про то сколько это сожрёт памяти, а также быстродействия - т.к. оконная функция будет по времени съедать весть "тред" (поток, а в квике, судя по всему, главный поток).

Чтобы как-то исправить данную ситуацию и отказаться от наклёвывающейся потери производительности - разработчики квика со временем отказались от функции показа "хинта" при наведении на тень свечи, скорей всего, банально заменив расчёт региона на расчёт прямоугольника свечи (ptInRgn на ptInRect), а также, при показе всего графика - они не показывают все свечки и, соответственно, не рассчитывают по ним регионы, а делают из, скажем 2-х, 4-х свечей - одну полоску (представленную в памяти, как один логический объект) - это если не все свечи физически могут поместиться на графике (к тому же известно, что минимальная ширина свечи равна 1 пиксель). Можно, конечно и дальше продолжать упорствовать и вдаваться в пространственные обсуждения, что вот мол, де, для того и придумали полосы прокрутки (scrollbox) - но с точки зрения windows и программиста - это ничего не меняет, т.к. отображая даже часть общего количества свечей - надо, как говорится, со сроком "вчера" - уже думать над кешированием новых объектов, а как уже говорилось, время работы оконной процедуры и ресурсы ОС должны быть сведены к минимуму. Отдав/выделив это дело в отдельный поток - графики перестанут быть адекватными (строго говоря, они итак невсегда адекватны), а с ними и стиль торговли, жёстко привязанный к показаниям графиков перестанет отражать реальную рыночную ситуацию. т.к. windows - это не система жёского реально времени и время выделяемое под каждый тред нигде не фиксировано (по документации максимальное время гарантированного переключения между тредами может доходить до 5 сек, а вреальности и того больше)
(говорю максимально усечённо, т.к. тут не форум по программированию, а я в свою очередь, не программист)

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


как-то вот так... ;)

им кстати, уже задавали такой вопрос - на что они ответили: переходите на старшие таймфреймы...:)))))))

я тоже думал над этим НО!!!
встаёт такой вопрос: а если графиков более чем один. скажем, 20-50 то тогда как? да что говорить? пусть даже 10?
при каждом добавлении новой свечки плагин графиков приостанавливает все другие потоки, которые к нему обращаются, что заметно потому как квик начинает "замирать" в этот момент, а потом "догонять" отображение пропущенных данных.

Вопрос, к Michael Bulychev, как к самому опытному:

из материалов форума - мы знаем, что qchart.dll и скрипты в QLUA (не считая коллбека main) - работают в одном потоке. Из windows sdk мы также знаем, что у всего этого дела, чтоб оно как-то вразумительно работало в плане визуализации должна быть своя "message loop", а именно, в данном потоке должны присутствовать такие функции, как: getmessage, peekmessage, sendmessage, dispatchmessage, которые обрабатывают очередь сообщений потока в котором они вызваны. Кроме того, из "интернетов" - мы видим пример полу-успешной реализации данного момента: vclua.
Таким образом, вопрос-[ы]: если я создаю свой контрол, скажем, средствами GDI -

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

задам резонный вопрос: ЗАЧЕМ?
если уж выбирать между тупайлом и qlua - то, я однозначно выберу qlua.

боюсь спросить:
а график улыбки волатильности нам тоже можно построить? :))) или покупать для этого Stratvolat.dll?

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

и меня!  :)  , и меня!  :)  , и меня!  :)  , и меня!  :)  , и меня!  :)  , и меня!  :)  , и меня!  :)  , и меня!  :)  , и меня!  :)  , и меня!  :)  , и меня!  :) ,
на довольствие!!!:)))))

удивляюсь, однако сколько в квике ошибок...
и как в такой системе только торговать...
:))))))))))

p.s. ладно хоть она бесплатна для рядовых пользователей, а то бы эту компанию просто засудили:)))

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

у них всё это есть - только реализовано "не для всех". у них есть продуманная система плагинов на которой они делают деньги и есть софт "для всех остальных" - qlua и тупайл (для отмазки).

Объясните популярно, что Вы собираетесь этим сказать?
есть функция в QLUA getNumCandles - может Вы об этом?

одна из причин вылета может заключаться в том, что они используют в своём скрипте vcl.dll (так же известную, как VCLua 0.3.5). Она не предназначена для стабильной работы в среде QLUA. Подробно вся эта хрень обсуждалась на quik2dde.ru. На данный момент пока не удалось пересобрать полностью стабильный релиз, т.к. и сама QLUA оказалась не без греха: http://forum.quik.ru/messages/forum10/message1324/topic176/#message1324

если Вы про те скрипты, которые распространяет mycreditcard.ru - то в них очень много багов. В таком случае, Вам лучше обратиться к ним, т.к. они не распространяют исходники от него. К тому же, сам привод - бесплатен у них - поэтому тут вряд ли получится, что-то потребовать.

считайте маржу так. как считают её брокеры:
отдельно считайте купленные контракты
отдельно маржу по проданным (неважно, закрывайте вы позу или это чистый шорт)
потом, суммируйте эти 2 маржи.

не знаю, как насчёт 1.0.0.0. но, 1.0.0.3. - это просто библиотека импорта функций LUA из той же QLUA.dll. В поставке QUIK - она оставлена исключительно для совместимости. На данный момент, qlua.dll - полностью заменяет стандартный (с точки зрения LUA-дистрибутива файл). Скорей всего, проблема том, что Вы используете какие-то дополнительные внешние dll в своём скрипте, которые скомпилированы под lua.5.1.dll.

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

:)))))))))))))))))))))))а я нигде не сказал, что я его использую. это всё Ваши мысли:))))))))))))))))))))))))

так ли

они вам скажут, что всё может сделать и в qlua/либо (о чудо!) зарегистрируют наконец пожелание, которое врядли будет исполнено.