Вручную снять галки в настройках метки. Но не думаю, что это - то, что вам нужно: после снятия привязки метка будет смещаться относительно осей при масштабировании.
Надо делать так, как надо. А как не надо - делать не надо.
и убеждаемся, что метку переместить вручную уже нельзя.
Обратил внимание, что если после SetLabelParams в настройках метки снять привязку ко времени и цене, то метку можно двигать вручную. Может, это имеет отношение к обсуждаемой проблеме.
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: Если речь о Lua-индикаторе, то ответ очевиден: индикатор должен уметь обратиться как к графику, по которому он построен, так и к самому себе. Можно например, ввести две константы, которые заменяли бы тэг графика или индикатора.
В таком виде пожелание можно зарегистрировать.
Регистрируйте.
Цитата
Sergey Gorokhov пишет: Вопрос не понятен. Предмет спора, предложить вариант избавления от идентификаторов. Я привел не более чем пример решаемой задачи. Не нравится одно окно с шестью графиками, пусть будет 10 окон с 200 графиками.
Поэтому я и уточнил: нет смысла искать график, если не известно, где его искать. Сам Auto_ID, как таковой не даст ничего. Но, если иметь список ID всех открытых графиков и иметь возможность получить свойства этих графиков, такие, как код бумаги, таймфрейм, название индикатора и др., то эта информация уже даст возможность обратиться к нужному графику.
Надо делать так, как надо. А как не надо - делать не надо.
Если речь о Lua-индикаторе, то ответ очевиден: индикатор должен уметь обратиться как к графику, по которому он построен, так и к самому себе. Можно например, ввести две константы, которые заменяли бы тэг графика или индикатора.
Если речь вообще о любом скрипте, тогда не понятен предмет спора: как вы определили, что вам нужно вот именно это
Цитата
Sergey Gorokhov пишет: Вот есть окно с графиками. В нем 6 графиков по разным инструментам.
а не какое-то другое окно?
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov пишет: Дмитрий, к Вам тот же вопрос. Вот есть окно с графиками. В нем 6 графиков по разным инструментам. Вот Вы предлагаете чтоб на каждом был Auto_ID. Хорошо, допустим мы это сделали. Дальше что? Как скрипт сам должен понять на каком графике рисовать метку?
Речь идёт о нанесении меток из индикатора?
Надо делать так, как надо. А как не надо - делать не надо.
Viktor MMM пишет: Я менял файл отображение метки. Отображение не изменилось)).
Попробуйте использовать только bmp-файл: с gif бывают проблемы. Также поиграйте с прозрачностью метки (TRANSPARENCY): при замене файла прозрачной становится вся метка полностью.
Надо делать так, как надо. А как не надо - делать не надо.
Можно добавить логирование непосредственно перед вызовом функции из socket:
Код
function getTime()
toLog("Определяем текущее время...")
local Time = socket.gettime()
toLog("Текущее время: "..Time)
return Time
end
Тогда при возникновении подобной ошибки будет ясно, виноват ли в этом socket. Ну и держите нас в курсе ;-) , бо я думал, что с работой функции socket.gettime у QUIK давно нет проблем.
Надо делать так, как надо. А как не надо - делать не надо.
Egor Zaytsev пишет: Так и было задумано.Вместо "1" в поле период всегда подставляется "all" -это означает, что в этом массиве содержатся ВСЕ имеющиеся на данный момент не агрегированные свечки - данные по остальным интервалам являются агрегированными.
Серьёзно? Вы внутрь файлов вообще заглядывали? Вас не смущает, что содержимое файлов по всем периодам совпадает?
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
_sk_ пишет: Применяется только gettime() из библиотеки Socket. Остальное всё самописное.
Самописное в Lua-коде?
Цитата
Николай Камынин пишет: попробуйте убратьсвой перехват ошибок. возможно тогда ошибка вывалится в dump, либо получите больше сообщений из перехвата луа машины.
Возможно действительно без xpcall получите больше информации об ошибке, и будет понимание, где искать.
Цитата
_sk_ пишет: Такой вариант не удобен, т.к. свои ошибки тоже нужно контролировать с подробностями (трасса стека не пишется в окно об ошибках скриптов).
Код всё ещё модифицируется? Или не все "блохи отловлены"? В любом случае, после того, как найдёте причину возникновения ошибки, вернёте xpcall.
Надо делать так, как надо. А как не надо - делать не надо.
В скрипте используются какие-то сторонние библиотеки? Так при использовании сторонних библиотек, скрипты в QUIK иногда могут падать с ошибкой "Unknown error."
Надо делать так, как надо. А как не надо - делать не надо.
_sk_ пишет: Нет ли в QUIK ситуации, когда сборщик мусора не может избавиться от каких-то старых данных DataSource из-за того, что не все ссылки сброшены в nil?
Есть такая ситуация. Когда данные стали не нужны, их необходимо принудительно сбросить в nil, иначе они ещё долго могут висеть в памяти (даже при ручном вызове collectgarbage()).
Надо делать так, как надо. А как не надо - делать не надо.
При отсутствии значения искомого параметра в ТТП всегда param_value = "0.000000" и param_image = "" ? Т.е., они не могут быть nil ни при каких обстоятельствах?
Надо делать так, как надо. А как не надо - делать не надо.
1) Сделайте при наведении курсором на график вывод в подсказке значений всех индикаторов на данном временном баре, а то порой бывает сложно "поймать" какой-то конкретный индикатор в месте пересечения с ценой.
2) А также на панели "Координаты курсора" при включённом перекрестии (и снятой галке "Показывать подсказку на свечке") опцию "Всегда показывать подсказку", при включении которой в левом верхнем углу диаграммы отображались бы значения всех индикаторов в месте пересечения с горизонтальной линией курсора (на всех панелях данной диаграммы).
Надо делать так, как надо. А как не надо - делать не надо.
Юрий пишет: нашел временное простое решение без "заморочек" на расчеты биржи
Что-то я не пойму, зачем так "заморачиваться"? Рассчитывайте ГО по предложенным формулам, подставляя в качестве L в них 0.5 базового ГО, транслируемого в QUIK. Ведь блокирую-то именно эту сумму, как для рублёвых, так и долларовых контрактов. Или нет?
Надо делать так, как надо. А как не надо - делать не надо.
Как вариант: если скрипт обнаружил, что метка сместилась, задать некий таймаут ожидания полного перемещения метки, после окончания которого считать, что метка установлена на нужном уровне цены.
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: И чтобы эти фильтры можно было применить в окне сообщений.
Могли бы подробнее описать желаемый функционал.
Добавить опцию (относится к фильтру, заданному по условию «Исключать выбранные»), при выборе которой сообщения, удовлетворяющие условию, также не будут отображаться в окне сообщений.
Надо делать так, как надо. А как не надо - делать не надо.
Vitaly Skorobogatov пишет: И вполне может, обновив данные на сервере, дальше известить об этом факте своих клиентов.
Я понимаю, что если брокер не извещает клиентов об обновлении архива, как в этой ситуации
Скрытый текст
Цитата
Роман пишет: Два раза перезаказал графики, на разных серверах, на второй раз исправилась.
Цитата
Egor Zaytsev пишет: Роман, как поняли проблема решилась после перезаказа графиков. По всей видимости какое то время у брокера действительно на сервере были не корректные графики, брокер проблему исправил, но чтобы и на клиентском месте транслировались корректные данные необходим перезаказ графиков.
то это и не ваша забота вовсе. Но, даже если гипотетически предположить, что в день, когда брокер обновил архив графиков на сервере, то известил бы об этом факте, пользователь мог отсутствовать за терминалом в этот день и пропустить данное сообщение.
Цитата
Vitaly Skorobogatov пишет: К сожалению, ни сам график, ни сервер QUIK, его транслирующий, не могут догадаться о том, что данные некорректны
Это я уже выяснил с вашими коллегами. Но можно сделать по аналогии и для графиков:
Цитата
Sergey Gorokhov пишет: есть специальная процедура восстановления в случае сбоев. Если процедура выполняется то на клиентских терминалах данные перезакажутся.
Т.е., на сервере в случае восстановления архива графика добавить какую-то метку, которая сообщала бы клиенту, что имеющийся у него график "битый", и если он желает, то может перезаказать новый. Как вам тут неоднократно указывали, программа должна быть "User Friendly"
Надо делать так, как надо. А как не надо - делать не надо.
Проще сделать не хоткей, а именно кнопочку "Готово", при нажатии которой будут применены новые координаты линии (т.к. в любом случае после смещения линии надо будет кликать в окно таблицы).
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: Пользователям, естественно, нужно будет перезаказывать архив графиков вручную?
Да. После того, как брокеры выложат восстановленный график RTS на свои сервера.
А вы не находите такой вариант работы не совсем удобным? Ну, т.е.: 1) пользователь должен узнать, что вот такой-то график некорректный; 2) восстановленный график брокер уже выложил на сервере; 3) и нужно перезаказать весь архив графиков.
Если с последним пунктом проблем не возникает: вместо всего архива можно вручную удалить только графики по нужному инструменту, минуя стандартную процедуру "Перезаказать архив графиков". (Как уже указывалось на форуме меню "Перезаказать архив графиков" следовало бы убрать совсем, т.к. оно грохнет весь архив).
То как быть с первыми двумя пунктами? По-хорошему надо бы как-то предупредить пользователя, о том, что на сервере доступен новый вариант графика.
Надо делать так, как надо. А как не надо - делать не надо.
В рабочих скриптах, которые должны работать автономно весь день, стараюсь не использовать сторонние библиотеки ввиду их возможной нестабильной работы с QUIK (часто при выходе новой версии что-то ломается).
Цитата
Viktor MMM пишет: Я ведь правильно понимаю, что SetTableNotificationCallback будет работать только тогда, когда событие произошло при нахождении курсора в границах созданной таблицы?
Только, когда окно таблицы активно.
Надо делать так, как надо. А как не надо - делать не надо.
green_X5 пишет: Что же по-вашему должна ответить ТТП, если она даже не знает о существовании такого тикера?
А что по-вашему отвечает CreateDataSource, если ей задать несуществующий код бумаги в реальном классе? Как ни странно, CreateDataSource возвращает таблицу! А что при этом говорит SetUpdateCallback? true, что согласно документации означает "успешное завершение".
Надо делать так, как надо. А как не надо - делать не надо.
_sk_ пишет: По-хорошему, это должно быть указано разработчиками QUIK в документации явным образом.
Если сотрудники сами об этом "забывают"? По-хорошему, это должно быть указано разработчиками QUIK в документации явным образом в первую очередь для сотрудников техподдержки.
Надо делать так, как надо. А как не надо - делать не надо.
Egor Zaytsev пишет: Открывать таблицу не обязательно. Вот простой пример: step = getParamEx("SPBFUT","RIH6","SEC_PRICE_STEP").param_value message(tostring(step),1)
Значение получает без открытой таблицы.
Egor Zaytsev, ваш пример некорректен: параметр "SEC_PRICE_STEP" - это т.н. статический параметр, который в любом случае "заезжает" на рабочее место.
Надо делать так, как надо. А как не надо - делать не надо.
green_X5 пишет: Что же по-вашему должна ответить ТТП, если она даже не знает о существовании такого тикера?
ТТП знает о всех существующих тикерах, независимо от того, выбран ли этот тикер в "Списках" или добавлен ли он в таблицу. Если какой-то тикер не найден, значит его нет вообще, или у пользователя нет прав на работу с этим инструментом.
А я указываю, что getParamEx
Цитата
Egor Zaytsev пишет: Значение получает без открытой таблицы
только, если нужный нам параметр явно выбран в "Связь -> Списки".
Надо делать так, как надо. А как не надо - делать не надо.
Можно создать метку в виде горизонтальной линии. И в цикле опрашивать состояние метки функцией GetLabelParams, и проверять, не изменился ли параметр YVALUE. Тогда можно будет двигать линию мышкой.
Но сразу о багах: 1) метку нужно обязательно создавать без подписи (TEXT), иначе она будет визуально позиционироваться не там, где нужно, и при масштабировании графика смещаться; 2) функция GetLabelParams возвращает таблицу с названиями параметров в нижнем регистре, тогда как эти параметры в функции AddLabel задаются в верхнем регистре; 3) функция GetLabelParams возвращает значения всех параметров в строковом виде, несмотря на то, что часть параметров типа number.
Надо делать так, как надо. А как не надо - делать не надо.
Settings = {
Name = 'HLine',
Value = 0,
line = {
{
Name = 'HLine',
Type = TYPE_LINE,
Width = 2
}
}
}
function Init()
return 1
end
function OnCalculate(index)
return Settings.Value
end
Перемещение линии через настройки индикатора. Хоть мышкой двигать нельзя, но можно задать точный уровень цены, что удобнее стандартной линии. Значение линии можно считывать в своём скрипте.
Надо делать так, как надо. А как не надо - делать не надо.
_sk_ пишет: если в ТТП нет инструмента или все ТТП вообще закрыты, то данные всё равно доступны через getParamEx, если их получение настроено через "Связь -> Списки"
Надо делать так, как надо. А как не надо - делать не надо.
Раз уж вопрос поднимался, хотелось бы получить однозначный ответ, чтобы поставить, так сказать точку в этом вопросе.
Цитата
Старатель пишет: Но у меня вопрос к сотрудникам ARQA Technologies по конкретной торговой платформе :
Цитата
Старатель пишет: действительно ли брокер может "перехватывать" заявки клиентов, поданные, посредством ИТС QUIK ?
Цитата
Дмитрий пишет: Присоединяюсь к вопросу Старателя к разработчикам по поводу возможности перехвата и исполнения брокером обычных заявок клиентов без вывода их на биржу.
Надо делать так, как надо. А как не надо - делать не надо.