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

Для наглядности я провёл ещё одну линию вдвое короче первой на дневном графике. При уменьшении таймфрейма до 2М она осталась на месте:

Egor Zaytsev, то, что средняя точка пришлась на пик - случайность.
Но, если вас это смущает, то вы можете поступить следующим образом: убрать отображение графика цены и провести наклонную линию на чистой диаграмме, отметив 2 реперные точки и третью точно посередине:

Затем уменьшить таймфрейм, так чтобы одна из реперных точек вышла за пределы границ диаграммы:

Как видим линия сместилась. Достаточно убедительно? Или вы можете математически доказать, почему теперь линия не проходит через среднюю точку, которая находится точно посередине между реперными?

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

Но на рис.3 есть явное смещение. Посмотрите повнимательней: линия должна проходить через пересечение горизонтальной и вертикальной линий.

sam063rus, вы разработчик? Вам-то что за интерес?

При клике правой кнопкой мыши на таблице появляется меню с одним единственным пунктом "Переместить на вкладку". Сделайте возможным добавлять свои пункты в контекстное меню.

Я проверял на версии 6.17.1.17
Да вы сами можете это повторить: на скринах хорошо видно инструмент и период времени.

ОК. Добавьте также нормальное описание этой функции, бо у меня вопрос так и остался:

Добавьте также код события нажатия на заголовок окна.

Я в том смысле, что смещение, как таковое, происходит только при уходе базовой точки за пределы диаграммы (3 рис.).
Чего нельзя сказать про рис. 2, где линия построена с математической точки зрения верно.

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

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

Меняем таймфрейм на 4H. Визуально правая точка сместилась относительно вершины. Но в QUIK точки привязываются к началу того тайфрейма, на котором проводилась линия. А в данном случае дневной максимум приходится не на начало дня:

Далее меняем таймфрейм на 20-минутный. Левая точка уходит из зоны видимости. Вот тут-то линия смещается, что можно наблюдать по средней точке:

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

Под понижением таймфрейма вы подразумеваете то же, что и я?
Вот был таймфрем Daily, на нём точка с координатой X = 10.04.2015. Понизили таймфрейм до H4. Что округляем-то? У нас 4 координаты теперь по Х: 08 ч, 12 ч, 16 ч, 20 ч. Какую выбираем?

Вам лучше знать. Я с вами не знаком, и какими прогами вы пользуетесь не знаю.
Представьте лучше сравнительные скрины, как выглядят линии при смене таймфрема в QUIK и "других прогах", чтобы был предметный разговор.

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

Опа!   :o   Вот это откровение... Могли бы соврать что ли, что, дескать, "работа ведётся, скоро выпустим 64-разрядную версию, остались, буквально, считанные годы..."
Что бы вы могли скорее оценить целесообразность перехода на 64-bit даю ссылку на полезную статью: 7 шагов по переносу программы на 64-битную систему.

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

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

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

Добрый день.
Работаете ли вы над созданием 64-битной версией QUIK? Или хотя бы есть ли в планах перевод версии на 64-bit?

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

Это значит, что OnCleanUp вызывается при переподключении к серверу в новый торговый день?
Когда происходит выгрузка файла qlua.dll?

Короче, что нужно сделать, чтобы был вызван колбек OnCleanUp?

Michael Bulychev, здесь вы предлагаете использовать OnCleanUp. Позже ваш коллега
Так как на самом деле: OnCleanUp работает? И что есть "смена сессии"?

Пардон, не видел: здесь об этих функциях ни слова, в quik_6_17_1_upd.zip вообще отсутствует WhatsNew.

Sergey Gorokhov, отметьте также об отсутствии потокобезопасности предложенного вами способа. А то ведь ещё один человек по этим "граблям пройдётся".

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

Sergey Gorokhov, спасибо.

Если не сложно, дайте пример расчёта греков.

По поводу очереди событий здесь.

Вернее, последний параметр - это текст на панели задач.

Как это поможет в решении задачи?

Интересная идея. Зря вы отмахиваетесь от неё.
Вот, пример, как настраивается текст в заголовке окна, статусной строке и всплывающей подсказке в foobar2000:

Скрытый текст

У вас в цикле "for i=1, 30 do" нигде не используется переменная-счётчик i. Отсюда, на первый взгляд, в этом цикле вы делаете 30 раз одни и те же действия.  

Если кто будет качать данные с сайта Финама (экспорт котировок), то у них тоже не обходится без косяков:

Скрытый текст
Слева - данные из QUIK (совпадают с биржевыми), справа - с сайта Финама.

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

Так это уже обсуждалось: http://forum-archive.quik.ru/forum/lua/125655/125655/

В чём отличие с require() в плане подключения своих функций?

Правильно ли я понимаю ваш ответ, что в QUIK поддерживаются параметры/значения_параметров транзакций различных бирж, не описанные в Руководстве пользователя QUIK? Нам осталось только угадать как они могут называться в вашей интерпретации?

Из документации Шлюз SPECTRA Plaza-2:
Если я правильно угадал, то FutMoveOrder - это транзакция с параметром ACTION = "MOVE_ORDERS", а regime - параметр MODE в QUIK.
Поддерживается ли параметр MODE = 3 ?

s_mike@rambler.ru, у вас:
На самом деле, если не указаны остальные параметры, то используется момент времени 12:00:00

Как я понял из общения с ТП, сначала обновляются данные в ТТП, затем вызывается колбек OnParam.
Но чтобы "быстрей получить" данные из ТТП, нужно знать, в какой момент к ней обращаться. Так что без OnParam не обойтись.
И при чём здесь OnTrade?

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

Можно, как вам уже указали, используя CreateDataSource и SetUpdateCallback. Но, если необходимо отслеживать много параметров, то неизвестно, как это отразится на производительности.

Да нет же. Так вы будете получать сообщение при изменении любого параметра по данной бумаге.
Максимум, что можно сделать, это проверять, была ли вызвана функция OnParam изменением интересующего параметра или какого-то другого:

Нет, OnParam будет срабатывать при изменении любого параметра, а не только того, который вам нужен.

* к прежнему UID

Ой ли? Брокер, как правило, "прицепляет" новые ключи к прежнему пользователю.

s_mike@rambler.ru, вы что, сговорились с разработчиками?
По приведённой мной выше ссылке разработчикам на 5-ти страницах пытаются объяснить, что при подключении клиента к серверу требуется первым делом передать клиенту количество записей, которыми располагает сам сервер. Ничего более. Никаких гаданий, что "груз" в пути не нужно. Только то, что есть сейчас.
И "окончательная загрузка" имеется ввиду по отношению к моменту подключения к серверу.
Не заставляйте переписывать предыдущую тему сюда, лучше почитайте здесь.

 :o   Да вот хотя бы:

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

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

Речь в данном случае идёт о получении изменения параметров или таблице истории изменений. Разве для этого имеет значение интервал (не считая тикового)?

Нет. Только онлайн в реальном времени.

Я вижу, что "стакан". Но в стакане нет информации ни о количестве заявок, ни о времени их постановки...
Есть только агрегированный спрос и предложение с разбивкой по ценам.