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

Это ограничение не брокера, но биржи.

В какой версии? В v.6.17.1.17 окно ввода стоп-заявки по опционам открывается более 8 сек.
Почему в списках исправлений версий нет информации об этом баге?

Если бы воспроизводили проблемы на боевом Квике, то этот вопрос уже решили бы.

Было время, когда RTSI (вы ведь сейчас о нём?) и в вечернюю сессию рассчитывался.

Судя по скрину ТС интересует ФОРТС (в т.ч.). В таблицах по ФОРТС есть цена приобретения?

Это не является ошибкой?

Ну да, на часовом графике - 9:00
Так о какой "технической" свечке идёт речь?

И если это так, то что тогда с предторговой свечкой? Обращаться к брокеру - не вариант. Т.к., если он уберёт отображение предторговой свечи, то к нему появятся вопросы "почему цены в ТТП не соответствуют ценам на графике" и т.п.

О какой "технической" свечке идёт речь? Это сделка по цене открытия текущего дня, которая на минутном графике и в ТВС отображается в 09:59:59

У меня тоже белый фон возвращается через 500 мс. Вопрос был в том, почему фон подсвечивается в чёрный цвет при указании константы QTABLE_DEFAULT_COLOR?

Возможно, имелось ввиду не по текущей, а по сигнальной цене (с учётом спрэда)?

Зарегистрируйте, пожалуйста.

Цвет чего используется для фона в функции Highlight?
Почему при использовании следующего кода цвет фона становится чёрным? Ведь видно, что по-умолчанию цвет фона белый:

Так почему не сделать, чтобы пользователь мог сам ограничить отображение у себя на графике по аналогии с тем же Intra-day только за все дни? Необходимый функционал у вас уже почти реализован.

Что вам больше нравится. Оба варианта решают вашу задачу.

string.match (s, pattern [, init])

Sergey Gorokhov, я написал:
Т.е., я не знаю точно, где именно были проблемы, но сделал вывод, что не у меня, т.к. в то время, когда отправлялись транзакции, разрывов с сервером QUIK не было и проблем с интернетом на моей стороне не наблюдалось.
При отсутствии связи сервера с торговой системой клиенту ничего не приходит в ответ на транзакцию?
А что со стоп-заявками? Для них ведь связь сервера с торговой системой биржи не нужна? (Мой случай был именно со стоп-заявками)

Спорное утверждение. Выше я писал об этом.

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

У меня вопрос к специалистам ARQA:
В Отчёте по транзакциям фиксируется локальное время сервера QUIK?
Т.е., возможна такая ситуация, когда "Время получения на сервере QUIK" и "Время получения ответа торговой системы" больше, чем время заявки в таблице заявок?

А ничего не будет. Вам показали котировку. Вы на неё купились. Затем человек передумал и убрал свой ордер.
Ну так что? Ваш алгоритм тоже ведь направлен против тех, кто покупает по "завышенным" или продаёт по "заниженным" ценам, не так ли?

Для чего вам Аккаунт выставившего заявку? Не морочьте людям голову.

Цену чего? Последней сделки или текущей котировки?

Вы случаем не опционами торгуете?

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

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

Запросить у брокера.

Причём, в Отчёте по транзакциям не было информации по тем транзакциям, в ответ на которые OnTransReply  не пришёл. По остальным же время получения на сервере QUIK - именно то, когда был получен ответ от сервера, т.е. на сервере транзакции регистрировались через 10 сек после их отправки клиентом. Где они "гуляли" это время - не понятно.

Не могу сказать: логов за тот день не сохранилось...

lergen, заинтриговали. Прям, детектив какой-то.  :)
Чтобы понять кто это делает, нужно подумать кому это выгодно.
Брокер?
Брокеру нет никакой выгоды разорять своего клиента. Это не дилер на Форекс. Брокеру выгодны клиенты-"долгожители".
Если только он не является 100% вашим контрагентом.
Как вариант, можно предположить, что какой-то сотрудник брокера, вычислив ваш алгоритм, играет против вас, обогащая свой личный карман.

Нет, не верно. Есть прецедент, когда при наличии связи с сервером, отсутствии проблем с интернетом, колбеки OnTransReply не приходили от сервера. При этом заявки по данным транзакциям также не были исполнены.
Видимо, в это время были какие-то проблемы на стороне брокера: часть заявок не выставлялась, остальные - с задержкой более 10 сек.

В смысле? Лично против вас? Почему вы так полагаете?
Вы хотите вычислить обидчика?
У вашего брокера. Он видит все ваши заявки и заявки своих клиентов. У специалистов биржи: они видят заявки клиентов всех брокеров. Но я не в курсе, имеют ли они персональную информацию физ. лиц.

И тут нужно отдать должное Alexey P, т.к. это он обратил внимание на этот момент. (Я наивно полагал, что проблема "пляшущих трендов" решена.)

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

Есть ли возможность самому рассчитать цену приобретения (скажем, в Lua) и загрузить в таблицы, раз уж брокер ленится?

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

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

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

Добавьте функцию определения номера выделенной строки в QLua

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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