Constantin Constantin пишет: Еще бы сделали, чтобы в info.log меньше писалось всякой (ненужной) информации. Девять бумаг в ТТП и один открытый график дают файл info.log в более 30 мегабайт. Многовато.
Если оно вам не надо, отключите сохранение истории изменений. За всю торговую сесиию: info.log - 7.32 Мб curr_data.log - 18.9 Мб
Надо делать так, как надо. А как не надо - делать не надо.
Перезаказать данные заново - Очистить полученные данные и заказать их заново Очистить все и начать новый сеанс - Очистить все накопленные данные и заказать их заново Перезаказать архив графиков - Очистить архив графиков и заказать заново данные с сервера
Описание довольно скудное. Не понятно, чем отличается "Очистить полученные данные и заказать их заново" и "Очистить все накопленные данные и заказать их заново". Поясните, пожалуйста, более подробно, что делает каждый пункт, какие настройки сбрасываются, какие файлы при этом очищаются/удаляются.
Надо делать так, как надо. А как не надо - делать не надо.
Radik Mingazov пишет: Из-за этого терминал долго запускается, каждый раз приходится перед запускам удалять этот файл руками. Сделайте в Настройках галочку "Удалять info.log перед запуском терминала"
Цитата
Дмитрий пишет: Очищать данные после смены даты - выбрать "На локальной машине"
Это не то. Есть параметр командной строки для info.exe. Сейчас не помню какой. Техподдержка подскажет.
Надо делать так, как надо. А как не надо - делать не надо.
И да, проверьте также шлюзы к другим площадкам: то, что мы не видим на них подобных несоответствий вовсе не означает, что данные транслируются без ошибок.
Надо делать так, как надо. А как не надо - делать не надо.
Самое стрёмное в этой истории, что об этой ошибке я сообщил ещё год назад. И в течение этого времени никто этим вопросом не занимался, списав все грехи на биржу... Вот так и работаем...
Надо делать так, как надо. А как не надо - делать не надо.
s_mike@rambler.ru, QUIK и QLUA на сегодняшний день предоставляют широкие возможности для анализа данных, построения и тестирования своих стратегий. В QLUA можно реализовать то, что нельзя сделать в системах технического анализа (за Амиброкер не скажу - не пользовался). Правда, зачастую это требует и больших усилий.
Надо делать так, как надо. А как не надо - делать не надо.
Так, а что касается самого формата dat-файла. Разработчики так и не сказали, раскрываете вы формат или оставляете это на совести пользователей - копаться в его структуре?
Надо делать так, как надо. А как не надо - делать не надо.
Александр Шумилин пишет: Пока-что остаётся непонятным, зачем нужно анализировать dat-файлы
Например, для того, чтобы конвертировать из текстового файла, в случае, когда инструмент уже не торгуется, а брокер не предоставляет данные по архивным инструментам.
Надо делать так, как надо. А как не надо - делать не надо.
Egor Zaytsev, Версия QUIK v.6.16.0.42. На этой версии проблема имеет место быть, как и на предыдущих. Данная проблема также наблюдалась у других участников форума. Поэтому, я уверен, что настройки рабочего места на это не влияют. Скажите, для чего вам архив моего рабочего места? В течение года вам не удалось воспроизвести проблему?
Что касается брокера, то он прежний. Но судя по разным результатам тестирования других пользователей, я могу сделать вывод, что мы с ними работаем, по-крайней мере, на разных серверах.
Если есть затруднения, я могу скопировать сюда код скрипта для тестирования (который я неоднократно приводил в письме и предыдущей теме). Но, когда спрашивал о помощи, я имел ввиду реальную помощь, а не повторение по второму кругу действий годичной давности. Егор, если вами не было ничего предпринято по данному вопросу, то не стоит ожидать, что проблема сама собой рассосётся.
Надо делать так, как надо. А как не надо - делать не надо.
Да, речь про стакан котировок FORTS. Я вижу, что изменений нет. Это слишком сложная задача - поиск и устранение ошибки? Я могу вам помочь в этом деле? А что-нибудь вообще предпринималось по этому вопросу?
Надо делать так, как надо. А как не надо - делать не надо.
Michael Bulychev, Повторюсь: на Московской бирже иногда происходят ситуации, которых быть не должно. Из последних: транслируется информация по сделкам и заявкам за предыдущую торговую сессию, загружаются "левые" лимиты...
Поэтому вашего утверждения, что "такая ситуация невозможна" недостаточно: на основании его нельзя возместить убытки, понесённые в результате сбоя. Я понимаю, что такой вариант вы даже не закладывали при разработке системы. Но всё же хочется узнать, что произойдёт если шлюз пришлёт код бумаги, который уже есть в списке, с новыми статичными параметрами? Параметры заменятся для данного кода бумаги?
Надо делать так, как надо. А как не надо - делать не надо.
Прошёл почти год с момента обнаружения проблемы и отправки вам необходимой информации по данному вопросу. Ваша ИТС выдаёт неверные данные. Нужно выявить причину и устранить ошибку. Какие предприняты для этого меры?
Ответ типа "мы действительно не виноваты. Все необходимые данные для анализа мы передали специалистам биржи." не канает. Прошёл почти год. Ситуация не изменилась. Я ни за что не поверю, что в век информационных технологий вы отправили гонца с письмом пешком из Новосибирска в Москву, и по дороге в лесу его съели волки. Если "вы не виноваты", то нужно назначить "крайних" и пусть занимаются проблемой.
Надо делать так, как надо. А как не надо - делать не надо.
Известно, что на бирже случаются сбои, и могут произойти ситуации, "которых даже теоретически быть не может". И я не зря взял в кавычки слово "новая". Итак, сервер QUIK в течение торговой сессии может получить со шлюза новый код бумаги или список кодов шлюз передаёт только один раз в момент подключения?
Надо делать так, как надо. А как не надо - делать не надо.
1) getClassInfo() возвращает таблицу Lua, содержащую описание класса, в т.ч.:
Цитата
nsecs
NUMBER
Количество бумаг в классе
Если список кодов бумаг измениться может, то данный параметр также изменится, верно?
2) getSecurityInfo(). Что произойдёт, если поступит с сервера "новая" бумага с кодом, который уже есть в списке? Она заменит существующую бумагу с новыми параметрами?
Надо делать так, как надо. А как не надо - делать не надо.
Sofia Fedurina пишет: Сразу о том, чего сделать не сможем: 1. Открыть возможность редактировать свои сообщения.
Это принципиальная ваша позиция или технически невозможно? Если первое, то можно открыть возможность редактировать своё последнее сообщение, если оно не было закрыто другим сообщением - ничего страшного в этом нет.
Надо делать так, как надо. А как не надо - делать не надо.
Николай Камынин пишет: В Lua принято индексы таблицы начинать с 1. иначе неправильно работает # (размер массива).
В QLUA это не принято:
Цитата
getCandlesByIndex
Функция предназначена для получения информации о свечках по идентификатору (заказ данных для построения графика плагин не осуществляет, поэтому для успешного доступа нужный график должен быть открыт).
Формат вызова:
TABLE t, NUMBER n, STRING l getCandlesByIndex (STRING tag, NUMBER line, NUMBER first_candle, NUMBER count)
Параметры:
tag – строковый идентификатор графика или индикатора, line – номер линии графика или индикатора. Первая линия имеет номер 0, first_candle – индекс первой свечки. Первая (самая левая) свечка имеет индекс 0
Надо делать так, как надо. А как не надо - делать не надо.
Не надо этого делать: QUIK в лучшую сторону отличается от аналогичных программ тем, что: 1) Не требует инсталляции в систему 2) Является портабельным, т.е., может работать с любого носителя 3) Переносится на другое рабочее место со всеми данными и настройками простым копирование всего одной директории (со всеми подкаталогами)
Если религия не позволяет установить программу в папку, отличную от "Program Files", то можно просто дать доступ на запись в папку QUIK пользователю, под которым запускается info.exe. В этом случае "Запускать от имени Администратора" не потребуется.
Надо делать так, как надо. А как не надо - делать не надо.
Могут ли списки кодов классов и кодов бумаг обновиться (добавиться новый класс или бумага) на клиентском месте в течение торговой сессии без переподключения к серверу?
Надо делать так, как надо. А как не надо - делать не надо.
Запускаем два скрипта: 1) Считаем количество всех сделок:
Код
function main()
local hID = AllocTable()
AddColumn(hID, 1, 'Количество', true, QTABLE_INT_TYPE, 13)
CreateWindow(hID)
InsertRow(hID, -1)
while bRun do
local nLen = getNumberOf('all_trades')
SetCell(hID, 1, 1, tostring(nLen), nLen)
sleep(100)
end
end
2) Заказываем все сделки:
Код
function main()
local sClassCode = 'QJSIM'
for sSecCode in string.gmatch(getClassSecurities(sClassCode), '([^,]*),') do
(CreateDataSource(sClassCode, sSecCode, INTERVAL_TICK)):SetEmptyCallback()
end
message('ТВС заказана', 2)
end
Через некоторое время QUIK падает с созданием дампа. После нескольких попыток все сделки наконец закачиваются в хранилище. Но при этом есть вероятность, что часть сделок теряется. Повторное переподключение к серверу не помогает. Помогает только удаление файла alltrade.dat с повторной закачкой данных.
Также удалось локализовать ошибку, когда все сделки заказываются только со 2-го вызова CreateDataSource: это происходит, если во время запуска QUIK инструмент уже находился в списке [ALL_TRADES_DATA] файла INFO.INI
Надо делать так, как надо. А как не надо - делать не надо.