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

Выбрать дату в календареВыбрать дату в календаре

Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 ... 46 След.
Доступные скрипты, Значки для скриптов с ошибками
 
Цитата
nikolz написал:
сообщать на форуме все теплые материнские слова об авторе такого скрипта
Скорее об авторе библиотеки qlua, который допустил такое безобразие:
https://forum.quik.ru/messages/forum10/message59792/topic5823/#message59792
Надо делать так, как надо. А как не надо - делать не надо.
Доступные скрипты, Значки для скриптов с ошибками
 
2. Сделать возможным задавать звуковой сигнал при остановке скрипта с ошибкой.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
LUA_GCSTOP: останавливает сборщик.
LUA_GCRESTART: перезапускает сборщик.

Идея запихать сборщик в каждый колбек - так себе. Понятное дело, в боевых условиях это никто не тестировал.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Anton написал:
И уточнил, с какими аргументами lua_gc вызывается, вот с какими
А можно на русский перевести? ))
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Anton написал:
Поменялось ли что-то в 9.3.3
Изменений в Lua не было: осталась библиотека версии 4.2.0.3
Значит, исправили какую-то другую проблему, не обсуждаемую здесь.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
QUIK clients support, будьте любезны, прокомментируйте, п.6. из Изменения в Рабочем месте QUIK 9.3.3:

Цитата
Исправленные недоработки
6. Медленная работа Рабочего места QUIK в некоторых случаях при запуске или во время работы

Имеет ли этот пункт отношение к обсуждаемой здесь теме?
Надо делать так, как надо. А как не надо - делать не надо.
QMinEditor
 
Цитата
Egor Zaytsev написал:
Здесь:  https://arqatech.com/upload/iblock/4d8/QMinEditor.zip
Проверили, графики открывает. Если наблюдаете какую то проблему, то сообщите.

В архиве по ссылке версия 8.6.0.0 от 10.02.2020.
Так он "открывает" графики с Junior 9.3.1.11
Но если вы считаете, что так и должно быть, тогда ладно. Мне уже не надо.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
В сообщении #41 опечатался.
* в QUIK 8 скрипты торгуют, а в QUIK 9 режим торговли не включен, т.е. в 9 работы выполняется меньше, чем в 8.
+ в QUIK 8 на два скрипта больше. А нагрузка - сами видите.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Anton написал:
смена режима должна, по идее, заметно влиять, т.е. одно из в начале
Код
  collectgarbage( 'incremental' )
collectgarbage( 'generational' )
  

'incremental' - без видимых улучшений
'generational' на синтетическом тесте показал заметное улучшение. Что он делает?
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
А нет обманул, в QUIK 8 запущено даже на два скрипта больше - для сбора статистики.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Anton написал:
Насколько это критично в реальном применении, а не в модельном примере, вопрос открытый.

А вот в реальном применении: загрузка CPU сегодня на открытии основной сессии в 10 ч.
Слева - QUIK 9, справа - QUIK 8 при одинаковых настройках и одинаковом количестве открытых окон. Отличие только в том, что в QUIK 8 скрипты торгуют, а в QUIK 9 режим торговли не включен, т.е. работы выполняется меньше, чем в 9.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
swerg написал:
Деградация от версии к версии определённо печалит. Хоть я и поставил бы под сомнение корректность некоторых полученных результатов (v(0) больше, чем v(10000000) ??).
В сообщении #28 есть уточнение про погрешность.

Цитата
Anton написал:
после каждого колбека lua_gc добавили. Не обратил внимания только, полный или шаг. Вот оно собсна и есть, пропорционально количеству потенциального мусора.
Тут надо отметить, что, если в скрипте есть таблица, в которой постоянно добавляются и убираются элементы, то фактически количество элементов в таблицы будет только расти и никогда не уменьшаться.
Например, имеем таблицу активных заявок orders с ключом order_num. Когда заявка становится неактивной, убираем её: orders[order_num] = nil. Но для сборщика мусора этот элемент будет продолжать существовать со значением nil, он не сможет его очистить. Чтобы удалить элемент из таблицы, надо полностью удалить саму таблицу. Т.о., объём потенциального мусора будет только расти со временем работы скрипта.

Цитата
Anton написал:
Насколько это критично в реальном применении
У каждого своё реальное применение. Кто-то торгует только один инструмент, а другой весь рынок отслеживает. Кому-то и 200 стаканов мало. Сами понимаете, в каждом случае количество событий будет отличаться кардинально.
Надо делать так, как надо. А как не надо - делать не надо.
QMinEditor
 
Где взять QMinEditor для архивов из 9 квика?
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Anton написал:
9.1 или 9.2
Тест из сообщения #23 показывает, что с версии 9.1
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Anton написал:
в девятой версии смотрел "чего нового" в отладчике, увидел, что после каждого колбека lua_gc добавили.
Anton, начиная с 9.1 добавили?
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Поправка к коду в сообщении #25: время надо фиксировать в самом колбеке. Но это не сильно влияет на итоговый результат: завышение результата на 0 - 0.5 сек.
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Владимир, ну что за человек. Ну не понимаешь о чем тема, чё засирать её своими "умными мыслями".
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
swerg написал:
Давайте десятки миллионов глобальных переменных создадим

А давайте, чё мелочиться!
Скрипт:
Скрытый текст

Методика тестирования описана в сообщении #20. Только в этот раз я запускал только один экземпляр скрипта.
Результаты тестирования в различных версиях QUIK при 0 и 10000000 глобальных переменных:
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Даже просто создание локальной таблицы снижает производительность. Методика тестирования описана в сообщении #20

Код
local run = true
function OnStop()
  run = nil
end

local t
function OnAllTrade()
  if getNumberOf("all_trades") == 1 then
    local num = 1
    function OnAllTrade(alltrade)
      num = num + 1
      if num == 200000 then run = false end
    end
    t = os.clock()
  end
end

function main()
  local a = {}
  local n = 0
  --local n = 20000
  for i = 1, n do a[i] = i end
  while run do sleep(1) end
  if t then message(tostring(os.clock() - t)) end
end

Получается, кеширование любых данных, например для расчётов индикаторов, снижает производительность при вызовах колбеков.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
До кучи решил ещё одну тему проверить.
swerg, то, что вы написали
Цитата
swerg написал:
если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить. Т.е. это такое вполне понятное свойство интерптетатора Луа.
- бред и не соответствует действительности: в чистом Lua время вызовов пустой функции никак не изменится даже после создания "десятков миллионов глобальных переменных". Коль ввязываетесь в спор, вы бы хоть проверяли, прежде, чем чё-то писать.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Пока биржа не тогует, решил проверить одну идею на демке.
Junior, настройки по-умолчанию.
Открыл три окна: ТОС, системные сообщения и доступные скрипты. В ТОС добавил неторговый класс SMS-оповещения, чтобы не мешала измерениям.

Далее запустил одновременно три копии скрипта:
Скрытый текст

Перезаказал обезличенные сделки: Система / Настройки / Основные настройки... -> «Программа» / «Получение данных» / «Обезличенные сделки».
Выбираю класс "Акции 1-го уровня (эмулятор)" -> "Перезаказать данные"
По завершению работы скриптов запоминаю время.

Далее повторяю процедуру с f(150). Время работы скриптов выросло на 25%.
С r(150) - на 80%-90%.
При подключении socket время также увеличилось в 1,8 раза. А с iuplua в 3 раза.

Так что, дело тут не только в глобальных переменных.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
swerg написал:
Только сейчас разглядел создание 50 тыс глобальных переменных
Это количество было написано для саппорта, который проводит "нагрузочное тестирование" на демке, где количество событий на два порядка меньше, чем в реале. Чтоб потом не было разговоров, что все летает.
На бою, естественно, и рядом нет тысячи переменных.

Конечно, я не учёл фактор теоретиков-флудеров.
Цитата
swerg написал:
если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить.
Пруф в студию.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Nikolay написал:
о каких функциях речь? Любых пользовательских, или только о подписанных колбеках и функциях qlua?
Nikolay, В сообщении #2 уточнение: речь идёт о любых объявленных переменных. Возможно глобальных, но это не точно.
Вы можете заменить блок создания переменных таким образом:
Код
_G["f"..i] = i
Естественно, в моменты низкой активности торгов, а тем более на демке, влияние на загрузку будет незначительно. Если только не увеличить количество переменных и/или скриптов. Можно ещё в скрипт добавить подписку на другие ликвидные инструменты, чтобы получать больше событий.

Цитата
swerg написал:
А если колбеки убрать станет лучше?
Станет.

Цитата
swerg написал:
какие именно колбеки убрать, от убирания которых становится лучше?
Очевидно, те, которые вызываются чаще.

Цитата
swerg написал:
А если main убрать - станет лучше?
Совсем убрать? Скрипт остановится.

Цитата
swerg написал:
Чтобы масштаб проблемы был понятен.
swerg, сравните загрузку CPU при запущенном(ых) скрипте(ах) с блоком создания переменных
Код
_G["f"..i] = function () end
и без него. При открытых окнах (стаканы, ТТТ, ТОС) и при закрытии всех окон в квике.

Цитата
swerg написал:
не особо слышно чтобы тормозил от колбеков
swerg, А кто догадается, что тормоза именно от вызова колбеков? Не от выполнения кода внутри колбека, а просто от вызова.
В этой теме посмотрите #4 и #5 сообщения:
https://forum.quik.ru/messages/forum10/message59837/topic6874/#message59837
Не факт, что там именно эта проблема. Но это легко проверить:
1) автору достаточно добавить в начало каждого колбека do return end и проверить загрузку
2) переименовать каждый колбек как-то так OnQuote -> OnQuote_ и снова проверить загрузку
Если в 1-м случае нагрузка не изменится, а во 2-м уменьшится, то это - обсуждаемая здесь проблема.
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Владимир, nikolz,
господа флудеры, в демонстрационном скрипте нет никаких вычислений от слова совсем. Колбеки, вызываемые скриптом, пустые и не должны были бы оказывать на CPU абсолютно никакого влияния.
Не надо искать подвох в скрипте, он написан лишь с одной целью: продемонстрировать в первую очередь разработчикам Арки существенный баг в организации вызовов колбеков скриптами. По факту получается, что время, затрачиваемое на вызов колбека, существенно больше, чем выполнение кода в колбеке.
C Владимиром согласен в одном: "математика есть полное говно". Вот только это не моя математика, а квиковская, в котором есть прямая зависимость между количеством объявленных переменных и производительностью. Я, конечно, догадываюсь, в чём тут дело. Но так быть не должно.
Предлагаю вам воздержаться от засирания темы. Хотя кому я это пишу...
Надо делать так, как надо. А как не надо - делать не надо.
Слетает настройка кода клиента в быстром стакане
 
Добавлю: даже если торговый счёт (поле А) каким-то чудом не слетел после подключения к серверу, то чтобы отображалась верная текущая позиция, надо поменять счет на другой и вернуть обратно.
QUIK 9.3.1.11
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Даже не так.
Нагрузка на CPU пропорциональна количеству любых объявленных переменных (глобальных ?), в т.ч. функций (не обязательно выполняемых, а просто объявленных) в скрипте и/или подключаемых модулях и количеству колбеков, получаемых скриптом.
Когда в QUIK открыты одна или несколько ТТТ с большим количеством бумаг, стаканы, ТОС, то скрипты, в которых есть колбеки по событиям из этих таблиц, при высокой активности торгов сильно тупят.
Надо делать так, как надо. А как не надо - делать не надо.
Отладка QUIK 9.3
 
Цитата
_sk_ написал:
повышенное использование процессора в QUIK
_sk_,
https://forum.quik.ru/forum10/topic6953/
Надо делать так, как надо. А как не надо - делать не надо.
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Демонстрационный скрипт:
Скрытый текст

QUIK 9.3.1.11, Lua 5.4
Открыто, как минимум одно окно: стакан ликвидного инструмента.
Конечно, никто не запускает скрипты с тысячами функций, но при нескольких запущенных скриптах с десятками функций при высокой активности на бирже получаем нихилую загрузку CPU.

ЗЫ: У кого "один скрипт на все случаи жизни" с парой функций, может игнорировать эту тему.
Без флуда!
Надо делать так, как надо. А как не надо - делать не надо.
Кривые шибки в QLua
 
QUIK 9.3.1.11, Lua 5.4
Ещё парочка "неуловимых" косяков. Обе ошибки были в main. Никаких сторонних библиотек не подключено, только QLua-код.

1.
Код
local Time = tonumber((os.date('%H%M')))
if Time >= 2300 then
Ошибка:
Цитата
attempt to compare number with nil

2.
Код
local Param = getParamEx2('SPBFUT', 'SRZ1', 'STEPPRICE')
tonumber(Param.param_value)  -- вернул nil
Во время ошибки в лог было записано состояние самой таблицы Param:
Код
{result="1", param_type="1", param_image="1,000000", param_value="1.000000"}
Надо делать так, как надо. А как не надо - делать не надо.
Quik_9.1.0 не загружается
 
Vladimir Ivanov,
Неоднократно писал, в т.ч. на форуме. Искать номер сейчас времени нет.
Как помню, ваша основная рабочая версия была, что "виноваты Вайфай и Винда, поэтому ничё делать не будем."
Сейчас я опровергаю вашу версию: Вайфай не виноват.
Да даже, если допустить, что после выхода из спящего режима, у компьютера чудесным образом пропадают все сетевые интерфейсы - это не повод приложению зависать в ожидании от сервера ответа, которого никогда не будет.
Да и не стоит винить дядю Билла в том, что при этом ваше приложение даже закрыть невозможно, нужно его прибивать через диспетчер задач.
Надо делать так, как надо. А как не надо - делать не надо.
BUG: SetSelectedRow работает некорректно при использовании пользовательских фильтров или сортировки
 
Цитата
Daniil Pozdnyakov написал:
описать, как по-вашему должна быть реализована работа функций с номинальными порядковыми номерами

NUMBER row SetSelectedRow(NUMBER table_id, NUMBER row)

row >= 1 and row <= количества строк в таблице  -- выделяет строку с номером row (здесь и далее под номером строки подразумевается номинальный порядковый номер)
                                                                               если строка с номером row отсортирована и не отображается в таблице, то выделение снимается, SetSelectedRow возвращает -1
row = 0  -- снимает выделение, SetSelectedRow возвращает 0
row = -1  -- выделяется последняя видимая строка в таблице (обратите внимание, что сейчас это не работает должным образом, если к таблице применены фильтры)

Если кто-то считает, что SetSelectedRow должен по-прежнему работать с  видимым представлением таблицы, в котором учитываются пользовательские фильтры и сортировка, пусть напишет в этой теме, как это можно использовать.
Надо делать так, как надо. А как не надо - делать не надо.
Quik_9.1.0 не загружается
 
Vladimir Ivanov,
Напишите в теме, как продвигается устранение древнего бага? Есть успехи?
Надо делать так, как надо. А как не надо - делать не надо.
ищу программиста создать программу на платной основе, выгружать данные OHLC и индикаторы в файлик
 
Цитата
Владимир написал:
причём здесь избыточная точность не нужна и даже вредна.
Как я понял, ТС нужны данные для тестирования на истории.
Действительно, 100% точность в этом случае не обязательна. Но не вредна точно.
А вот, если встречаются пропуски в несколько минут (а у в экспорте финама такое встречается), то это - уже не гуд.

Цитата
Владимир написал:
Графиков?! Я хоть слово сказал про графики?
А в чём разница?
Надо делать так, как надо. А как не надо - делать не надо.
ищу программиста создать программу на платной основе, выгружать данные OHLC и индикаторы в файлик
 
Цитата
Владимир написал:
качайте с того же Финама любые свечи и делайте с ними что хотите. Ещё и быстрее будет, чем через Квик, не говоря уже про надёжность.
Про надёжность финамовских графиков:
https://forum.quik.ru/messages/forum1/message3246/topic297/#message3246
https://forum.quik.ru/messages/forum10/message53683/topic6327/#message53683
Надо делать так, как надо. А как не надо - делать не надо.
Баг - объём на последней минутке задваивается.
 
Цитата
Egor Zaytsev написал:
В версии 9.1 была исправлена ошибка "Удвоенное отображение объема на последней свече в окне графика."
Egor Zaytsev, вы с коллегами общаетесь?
https://forum.quik.ru/messages/forum1/message59344/topic6189/#message59344
Надо делать так, как надо. А как не надо - делать не надо.
Quik_9.1.0 не загружается
 
Vladimir Ivanov, есть какие-то результаты?
QUIK 9.3.1.11, Ethernet подключение
Опять завис на этапе "идёт установление связи с сервером". После нажатия кнопки разорвать соединение обе кнопки становятся неактивными  
Остается только прибить процесс через диспетчер, потому что сам он выгружаться не хочет. Короче, ничего не поменялось.
Причем Квики, которые с вечера были отключены от сервера, с утра успешно подключаются вручную.
Надо делать так, как надо. А как не надо - делать не надо.
Графики: подсказка на свечке
 
3) Отображать подсказку не только при наведении на тело свечи, но и на хвост свечи.
Надо делать так, как надо. А как не надо - делать не надо.
Графики: подсказка на свечке
 
Цитата
Stanislav Tvorogov написал:
Если по результатам дальнейшего анализа, включающего юридические аспекты, анализ на непротиворечивость с общей политикой компании, никаких возражений не возникнет, мы постараемся включить Ваши пожелания в план доработок при выпуске одной из следующих версий нашего ПО.

На какой стадии находится процесс анализа?
Надо делать так, как надо. А как не надо - делать не надо.
BUG: SetSelectedRow работает некорректно при использовании пользовательских фильтров или сортировки
 
Цитата
s_mike@rambler.ru написал:
вы идете по строкам сверху вниз и ищете в каждой строке в скрытом столбце нужный вам ключ. как нашли - выделяйте эту строку по номеру строки перебора, не по ключу.
GetCell, если вы её имели ввиду, работает с ячейками по номинальному номеру строки (и это правильно, тут к ней претензий нет. Одна только SetSelectedRow оказалась с дефектом в этом плане).
В вашем случае номер строки перебора всегда будет равен ключу.
Надо делать так, как надо. А как не надо - делать не надо.
BUG: SetSelectedRow работает некорректно при использовании пользовательских фильтров или сортировки
 
Цитата
s_mike@rambler.ru написал:
Выделяйте строки после поиска по этому ключу
И что вы найдёте? Номинальный номер строки? Я её и так знаю. А толку?
Надо делать так, как надо. А как не надо - делать не надо.
BUG: SetSelectedRow работает некорректно при использовании пользовательских фильтров или сортировки
 
Цитата
Daniil Pozdnyakov написал:
Касательно ответа на 2 вопрос. Привести пример, где в Lua-таблице с пользовательскими фильтрами выделяется строка функцией SetSelectedRow(), довольно сложно.
Это был скорее риторический вопрос. Потому что после применения фильтров и/или сортировки к таблице SetSelectedRow() становится бесполезной.

Цитата
Daniil Pozdnyakov написал:
можем зарегистрировать пожелание на добавление признака, показывающего, что строка отфильтрована в таблице созданной через CreateWindow()
Мне нужно выделять строки по их номинальному порядковому номеру. Что я буду делать с этим признаком?
Надо делать так, как надо. А как не надо - делать не надо.
[ Закрыто] Опять ошибка получения кол-ва ордеров скриптом
 
Цитата
Daniil Pozdnyakov написал:
Данная проблема, к сожалению, воспроизводилась не совсем корректно
Это как?

Цитата
Daniil Pozdnyakov написал:
изначально ошибку получить не удавалось
В целях улучшения взаимодействия и повышения информативности баг-репортов просьба более детально описать, что делали изначально и какие действия предприняли, что удалось получить ошибку.
Надо делать так, как надо. А как не надо - делать не надо.
[ Закрыто] Опять ошибка получения кол-ва ордеров скриптом
 
Daniil Pozdnyakov, сообщите, по какой причине вы утверждали:

Цитата
Daniil Pozdnyakov написал:
Перепроверили работу скриптов, на которые Вы ссылаетесь, уже с функцией CalcBuySell(). Они исправно выводят правильные данные.
Надо делать так, как надо. А как не надо - делать не надо.
BUG: Subscribe_Level_II_Quotes возвращает true даже если подписка на Level II по инструменту невозможна
 
В квике есть неторговые, информационные классы, по которым Level II не транслируется.
Но Subscribe по инструментам из этих классов возвращает true.
Надо делать так, как надо. А как не надо - делать не надо.
Дубликаты уведомлений onOrder v9.2.2.11
 
Есть другие факты:

https://forum.quik.ru/messages/forum10/message12868/topic1082/#message12868
Цитата
Sergey Gorokhov написал:
По данному обращению мы определили, что причиной множественных     отправок сделок (более двух) на клиентские места является неоптимальность в     серверном ПО QUIK. После ее устранения сделки могут быть отправлены на клиентское место максимум 2 раза - по     получению сделки из торговой системы и по факту ее обновления.

https://forum.quik.ru/messages/forum10/message13524/topic1082/#message13524
Цитата
Stanislav Tvorogov написал:
По данному обращению мы диагностируем что заявки, отправляются     пользователям столько раз, сколько раз они менялись на сервере (под     изменением понимается, как изменение статуса, остатка, так и     установка UID, trans_id). При этом по факту заявки могут быть     отправлены сразу в последнем, актуальном, состоянии. Поэтому клиенты     видят многократный апдэйт одной и той же заявки без ее видимых     изменений. В одной из следующих версий серверного ПО QUIK мы     постараемся исправить эту ситуацию, чтобы не дублировать отправку     заявки в одном и том же состоянии несколько раз.
Надо делать так, как надо. А как не надо - делать не надо.
Перемещение заявки 2 транзакциями
 
Цитата
Roman Azarov написал:
Цитата
Старатель написал:
Сократить время можно, если обновлять лимиты не только после получения уведомления по заявке, но и после ответа от биржи по транзакции.
Предлагаем зарегистрировать такое пожелание. Регистрируем?

Это в ваших же интересах в первую очередь, учитывая, что
Цитата
Roman Azarov написал:
Максимально сократить это время - является одной из наших основных задач.
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
 
Цитата
Daniil Pozdnyakov написал:
В следующий раз просьба предоставить ссылку на ветвь форума, где представлены скриншоты по описанной Вами проблеме

Daniil Pozdnyakov, в таком случае сообщите, по какой причине вы утверждали:
Цитата
Daniil Pozdnyakov написал:
Цитата
Старатель написал:
 
Цитата
Alexey Ivannikov  написал:
Проблема некорректного отображения объема дневных свечек до начала новой  торговой сессии
Это неточная формулировка.
Последняя свеча предыдущего дня остаётся искажённой и  после  начала торговой сессии.

 
Цитата
Alexey Ivannikov  написал:
с искажениями данных  в свечах меньших интервалов мы  до сих пор не сталкивались.
Давайте посмотрим вместе:
Открываем график H4 в Junior, смотрим последнюю свечу:
 
Теперь тот же график в бинарнике:
описанная ошибка была исправлена в версии терминала Quik 9.1.

Вы процитировали сообщение #26 с представленным скриншотом.
Надо делать так, как надо. А как не надо - делать не надо.
BUG: SetSelectedRow работает некорректно при использовании пользовательских фильтров или сортировки
 
Добрый день.
Скрытый текст


Применить к таблице фильтр, как на скриншоте: "Row больше 1"
При нажатии на любую клавишу, нужно выделить строку с фактическим порядковым номером 2.
Но выделяется строка с номером 3, о чём сообщает событие QTABLE_SELCHANGED.

1. Как выделять строки по фактическому порядковому номеру, с учётом того, что скрипт понятия не имеет о применённых фильтрах и сортировках?
2. Да в руководстве указано: "Функция работает с видимым представлением таблицы, в котором учитываются пользовательские фильтры и сортировка." Но нафига оно онужно? Можете привести хоть один реальный пример, когда нужно выделить строку в таблице, в которой "учитываются пользовательские фильтры и сортировка", принимая во внимание, что скрипт понятия не имеет о применённых фильтрах и сортировках?
Надо делать так, как надо. А как не надо - делать не надо.
Объемы торгов меняются на следующий день
 
Daniil Pozdnyakov, сообщите, по какой причине вы утверждали:
Цитата
Daniil Pozdnyakov написал:
Касательно неправильного отображения объёма на последней свече предыдущего дня. Данная проблема, которая была обнаружена в прошлых версиях терминала, была нами проверена на версии Quik 9.1. Она не воспроизвелась, объём последней свечи предыдущего дня отображается корректно, поэтому убедительная просьба прислать новые, актуальные скриншоты, на которых будет видно некорректное отображение объёма.
Надо делать так, как надо. А как не надо - делать не надо.
ошибка работы скрипта, ошибка появилась при смене 7 версии на 8
 
Цитата
s_mike@rambler.ru написал:
Сомн ительно, что это работало к вас в предыдущей версии.
Lua 5.3 / 5.4 имеет изменения в file:lines (···), добавляющие форматы, которые определяют, что читать. Т.о., функция ожидает строку в качестве аргумента, о чём и сообщает в ошибке.
В Lua 5.1 переданный аргумент просто игнорировался.
Надо делать так, как надо. А как не надо - делать не надо.
Страницы: Пред. 1 2 3 4 5 6 7 8 9 10 11 ... 46 След.
Наверх