Максим написал: Егор, речь про 32-битную версию библиотеки 1.3. Можно ли её выложить? 'double orderNum' - да, про колбеки, напрягает такое использование типа, а в 1.3 это исправлено.
32 битной версии нет. Если у Вас QUIK версии 7.0 и выше, можете устанавливать 64битную версию.
Не могу, т.к. окружение всё 32 битное. И библиотека загружается в контексте 32 битного приложения.
Егор, речь про 32-битную версию библиотеки 1.3. Можно ли её выложить? 'double orderNum' - да, про колбеки, напрягает такое использование типа, а в 1.3 это исправлено.
Imersio Arrigo написал: А в чем именно "крещение"? Темная тема не работает под wine-ом. Виснет на старте. А в светлой все нормально.
Ну вот в этом и вопрос - сделать, чтоб тёмная тоже работала. Сейчас выходит так, что скачал дистриб квика, поставил с нуля и пойди догадайся почему оно не работает. Если следом они и со светлой что-то сделают - вообще печально будет.
А почему не сделали сабж, только 64-битную сборку? Можно восстановить справедливость? Не очень-то прикольно получать 'double orderNum' в 1.2, да и новые функции в 1.3 хотелось бы посмотреть в деле. А ещё это, скажите вашему отделу по средним ценам, что они сокр. называются "avg", а не "awg"
У кого-то получилось скрестить? Единственный способ, что нашёл, это в info.ini либо удалить 'theme=1', либо заменить на 'theme=0'. Но хотелось бы более надёжный вариант, на случай если с очередным обновлением и стандартную тему поломают.
Когда удалённо подключаешься к квику из-за медленной отрисовки иногда вместо переключения между вкладками они перетаскиваются. Можно сделать опцию "закрепить вкладки", чтоб их нельзя было таскать пока она включена?
Максим пишет: Отлично, теперь эта проблема и у брокера вылезла (Открытие). Видимо он обновил серверную часть? Предлагает обновить терминал до 6.17.3, но я как-то привык сперва проверить новую версию на демо, убедиться что опять что-то не сломали. Но там 6.17.1.17 и обновиться не предлагает. Можно туда 6.17.3 выложить?
Добрый день,
Для получения версии рабочего места QUIK 6.17.3 необходимо направить запрос нам на почту: quiksupport@arqatech.com Обращаем внимание, что данная ошибка будет исправлена в одной из следующих версий программы.
Просьба зарегистрировать пожелание пересмотреть процесс выпуска новых версий терминала в сторону более раннего их обновления на демо, а уж потом рассылать брокерам. Причина описана выше. Тем, у кого такая же проблема, вот временное решение (уж не знаю в чём сложность это исправить в той же 6.17.3):
Код
function getFuturesLimitFixed(firmid, accountid, limit_type)
local ret = getFuturesLimit(firmid, accountid, limit_type)
if ret ~= nil then
return ret
end
for i = 0, getNumberOf('futures_client_limits') - 1 do
local entry = getItem('futures_client_limits', i)
if entry.firmid == firmid and entry.trdaccid == accountid and entry.limit_type == limit_type then
return entry
end
end
return nil
end
Отлично, теперь эта проблема и у брокера вылезла (Открытие). Видимо он обновил серверную часть? Предлагает обновить терминал до 6.17.3, но я как-то привык сперва проверить новую версию на демо, убедиться что опять что-то не сломали. Но там 6.17.1.17 и обновиться не предлагает. Можно туда 6.17.3 выложить?
Максим пишет: В Блумберг-терминале можно делать арифметические операции с графиками. Например, цену нефти в долларах умножить на курс доллар-рубль. Можете и себе такое прикрутить.
Добрый день.
Если есть навыки программирования, то данную задачу можно решить при помощи LUA.
Вы уж определитесь, кто является целевой аудиторией ваших терминалов =) Программисты, трейдеры, трейдеры-программисты или ещё кто.
В Блумберг-терминале можно делать арифметические операции с графиками. Например, цену нефти в долларах умножить на курс доллар-рубль. Можете и себе такое прикрутить.
Создаю, например, ТТП и график с привязкой. Потом ещё график, ещё какое-нибудь окно. И вот встаёт задача занять ими всё возможное пространство, благо есть опции "Окна/Чем-нибудь". Хотелось бы, чтоб была возможность и без того висящие поверх других окна исключить из этой интересной процедуры. Они ж все равно сверху. Хотя бы сделать такое поведение настраиваемым.
Предложение номер два - сделать окна фиксированной высоты, ширины или обоих размеров сразу (т.е. я ручками размер подогнал, тыкаю в контекстном меню "зафиксировать высоту"). Тогда всякие таблицы вроде ограничений по счетам при упорядочивании не будут занимать совершенно ненужное им пространство.
Короче, основная идея - иметь возможность пользоваться функцией автоподгона размеров и координат без печальных последствий вроде неэффективного использования полученного пространства. Может в этом контексте ещё какие идеи у кого-то будут.
На брокерском счёте такой проблемы нет, на демо же, несмотря на то, что в таблице futures_client_limits присутствуют три записи с limit_type=0,3,4, функция getFuturesLimit возвращает только последние две, вместо первое возвращает nil. Т.е. вызов
getFuturesLimit("SPBFUT000000", "SPBFUT00981", 0)
на демо не работает. Не то, чтобы это сильно нужно, но как-то неаккуратненько.
Michael Bulychev пишет: Добрый день. OnQuote вызывается на каждое изменение стакана, полученное с сервера. Если вы получите на терминал 1000 изменений с сервера и ваш скрипт обрабатывает 100 в секунду, то сетевая очередь на стороне клиента будет разобрана за 10 секунд.
Т.е. getQuoteLevel2 внутри одного вызова OnQuote будет всегда возвращать одно значение до следующего вызова OnQuote? А вызов getQuoteLevel2 в main тоже не вернёт новый стакан до тех пор, пока OnQuote не обработает старый? Если у меня торги длились секунду, было 1000 изменений, за эту секунду OnQuote обработал 100 стаканов, то в начале второй секунды он получит стакан, который в реальности был после 0.1 секунды от начала потока, т.е. 0.9 секунд назад, верно? Как объяснить эксперимент выше, где в OnQuote показывалось меньше данных, чем в OnParam?
Идёт с сервера bid=10, offer=11 вызывается OnParam, печатает bid=10, offer=11 вызывается OnQuote, печатает bid=10, offer=11 идёт с сервера bid=9, offer=11 вызывается OnParam, печатает bid=9 идёт с сервера bid=10, offer=11 вызывается OnParam, печатает bid=10 вызывается OnQuote, печатает ... а ничего не печатает, для него ничего не изменилось.
Я такую ситуацию имел в виду. Что "та же котировка" и "те же значения чисел лучших спроса-предложения" - несколько разные вещи.
Кстати, сотрудники арки, можете описать механизм вызова OnQuote? Вызывается ли он на каждое изменение котировок? Если случилось 1000 обновлений стакана в секунду, мой скрипт обрабатывает OnQuote со скоростью 100 в секунду, сколько раз будет вызван OnQuote? 1000 (и будет работать 10 секунд)? 100 (и будет работать секунду)? Другое число? Те же вопросы к OnParam.
Так OnParam на кучу всего реагирует, так что частота не показатель. Возможно OnQuote дёргается не на каждую котировку, а только если стакан поменялся с момента последнего вызова OnQuote. Т.е. если с сервера идёт 1000 котировок в секунду, а я могу обрабатывать только 100, то нигде эти котировки не копятся, просто меняется объект, возвращаемый по getQuoteLevel2, после возврата из OnQuote она вызывается ещё раз, итого ровно 100 раз в секунду. Ну я бы так реализацию написал :) Попробуйте добавить getQuoteLevel2 в OnParam и getParamEx в OnQuote. Может статься, что в OnParam показывается вообще не та же котировка, что потом покажется в OnQuote. И ещё, у вас же в скрипте хитрость - если между двумя вызовами OnQuote действительно стакан может несколько раз туда-сюда сходить, то вы на второй вызов ничего не напечатаете, т.к. best bid/offer "те же". Для OnParam оно имеет смысл, а тут уменьшает кол-во настоящих записей в логах. Или можно не гадать и дождаться ответа разработчиков =)
Сомнительные выводы из эксперимента (что непременно через OnParam надо котировки доставать). Там разница в пределах погрешности измерения + время на вызов колбека. Наверняка в квике написано что-то вроде --- нашКрутойОбработчикКотировок(котировка) начать засунутьКотировкуВТТП(котировка) вызватьЭтотВашOnParam(paramPamPam) вызватьЭтотВашOnQuote(класс, бумага) закончить --- Т.е. если OnParam нет, то и переживать не стоит, что он мог бы раньше вызваться. Кроме того, в привидённом примере есть запись, противоречащая (по крайней мере на первый взгляд) утверждению о последовательности:
Предлагаю по аналогии с ТТП сделать по нажатии Alt-I отображение инфы по инструменту. В случае облигаций было бы полезно. Ну может и для позиций на срочном рынке так же сделать для единобразия. Например, чтоб стоимость шага цены быстро глянуть, не открывая дополнительных таблиц.
Демо-сервер. На реале всё устроено иначе, чтоб не заморачиваться с "готовностью данных". При начале новой сессии виснет гарантировано (т.е. когда с утра переподключатеся). Иногда и при обычной работе. В консоль выдаёт кучу
Код
err:ntdll:RtlpWaitForCriticalSection section 0x31213f0 "?" wait timed out in thread 0009, blocked by 0000, retrying (60 sec)
Заблокироваться пытаемся в потоке 9, в рамках которого только что успешно отработал "OnInit" луа-скрипта, судя по логам. А кто держит секцию? Никто - "blocked by 0000" Стек (ну а вдруг):
Код
$ winedbg 8
WineDbg starting on pid 0008
0xf7768a12 GLIBC_2+0xa12 in ld-linux.so.2: ret
Wine-dbg>bt
Backtrace:
=>0 0xf7768a12 GLIBC_2+0xa12() in ld-linux.so.2 (0x00000000)
1 0xf74943d7 syscall+0x26() in libc.so.6 (0x00000000)
2 0x7bc3c574 RtlpWaitForCriticalSection+0xe3() in ntdll (0x00e6e558)
3 0x7bc3cfa8 RtlEnterCriticalSection+0x4f() in ntdll (0x00e6e598)
4 0x0304e894 in qlua (+0x3e893) (0x00e6e5bc)
5 0x0304f500 in qlua (+0x3f4ff) (0x00e6e5f4)
6 0x0303eecc in qlua (+0x2eecb) (0x00e6e644)
7 0x03080e40 in qlua (+0x70e3f) (0x00e6e65c)
8 0x00812d79 in info (+0x412d78) (0x00e6e690)
9 0x00812ed6 in info (+0x412ed5) (0x00e6e6c8)
10 0x005e6c90 in info (+0x1e6c8f) (0x00e6e6ec)
11 0x005e6e9b in info (+0x1e6e9a) (0x00e6e76c)
Далее, если посмотреть объект по адресу 0x31213f0, то можно увидеть, что там расположена критическая секция с такими полями:
Которая выглядит как будто её никто и не блокировал. Или же повторно инициализировал, или же убить успел.
Возможно, это глюк вайна, но если вдруг фреймы 4-7 что-то говорят и есть желание воткнуть там отладочную информацию, могу попробовать погонять с дебажной qlua.dll.
Сегодня обновил QUIK, запустил на демо и пришлось потратить какое-то время, чтоб выяснить, что проблема в квике и уже описана тут - http://forum.quik.ru/forum12/topic308/ Я надеюсь QA (если они есть) и программисты (если это их рук дело, а не "само сломалось") получат люлей от начальства (если ему есть хоть какое-то дело до репутации продукта). Можно это как пожелание зарегестирровать. Начиная с 6.15, что не релиз, то глюкавое чудо в перьях. Если же это альфа, бета или ещё что - указывайте, пожалуйста, эту информацию в строке версии, чтоб было ясно, что 6.17.0.58.beta.download.at.your.risk на реальном счёте качать не стоит. Вообще не круто с каждым обновлением затая дыхание искать "что же они сейчас сломали".
В связи с вышесказанным пожелание: наймите нормальных QA и покройте тестами ваши API
Максим пишет: Пожелание: Тщательней тестируйте свои продукты, включая этот форум, перед выкладыванием на публику. Написал комментарий выше и эта тема пропала из списка http://forum.quik.ru/topic/new/
Максим....там отображаются новые для Вас, Вы ведь этот топик Весь видели, значит он не новый....А для других он новый и будет в этом списке. Здесь всё норм.
Да, но при этом в меню слева эта ссылка называется "Обновления", где я бы ожидал увидеть обновления тем самих по себе, без учёта смотрел их кто или нет. Кроме того по самой ссылке страница называется "Новые темы", что опять же в моём субъективном понимании должно содержать список именно новых тем, а не обновлённых старых за вычетом просмотренных.
Пожелание: Тщательней тестируйте свои продукты, включая этот форум, перед выкладыванием на публику. Написал комментарий выше и эта тема пропала из списка http://forum.quik.ru/topic/new/