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

Лучше сразу функцию, которая могла бы изменять ширину колонок, в т.ч. и нулевой, после создания таблицы. А также функцию получения текущей ширины колонки, чтобы можно было сохранить параметры таблицы для следующей сессии.
Возможно, у вас назначен колбек на окно, который останавливает скрипт при его закрытии. Тут я рассматривал эту проблему.

Там же я поднимал вопрос:
На что был дан ответ:

Да, можно на них.
Перед первым запуском теста удалите файл "alltrade.dat" и очистите секцию [ALL_TRADES_DATA] в файле INFO.INI

PS: обратил внимание, что, если открыта ТВС (в ТВС могут быть выбраны бумаги, отличные от заказываемых в скрипте), то заказ всех сделок по большому числу бумаг длится гораздо дольше. При этом возрастает вероятность краха терминала во время заказа.

Думаю, вы в состоянии оценить возможности вашего "сервера" и задать для каждого графика необходимое количество свечей.
А вот эту мысль не понял:
Количество добавляемых свечей в единицу времени зависит не от количества отображаемых свечей, а от количества открытых графиков.

Уберите, наконец, это ограничение на отображение максимум 3000 свечей. Неудобно анализировать историю на младших таймфреймах.
При этом чтобы не грузить терминал пользователь может задать в настройках "Отображать последние x свечей", что уже реализовано.

А я уже не удивляюсь...
Но вот упорство сотрудников ARQA, с которым они "не хотят" видеть те проблемы, о которых им рапортуют, уже бесит.

2_сотрудникам_ARQA: учитывая количество багов, найденных мной и исправленных благодаря этому, в ИТС QUIK, можно сказать, что я выполняю работу ваших бета-тестеров, которых у вас нет. Пора бы уже меня принять в штат и поставить на полное довольствие.
С кем можно пообщаться по этому поводу?

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

Ваши конкуренты пошли дальше:
Иногда полезно "подглядывать" за конкурентами.

Под БД я имел ввиду внутреннее хранилище Квик.

А что насчёт этого факта? Рекомендую всё же обратить внимание на него: при падении Квика нередко часть сделок "выпадает" из БД.
В этом можно убедиться, вызвав неоднократное падение Квика во время загрузки сделок (см. пост #1) и сравнив полученное число сделок с количеством закачанных сделок при штатной загрузке.
Падение Квика при использовании Lua-скриптов - не редкое явление в текущей реализации. Посему необходимо обеспечить целостность таблицы всех сделок при загрузке.

Ну вот, пришли тут и нас нафлудили...

Так кто-нибудь из разработчиков может однозначно ответить на вопросы?

Как вариант:
или

Что-то мне подсказывает, что при попытке остановить такой скрипт терминал зависнет.
В любом случае проще предусмотреть закрытие окна в коде, если оно более не требуется, по окончании скрипта.
Считаю вполне нормальным такое поведение.

А это зависит от цели создания окна.
Скрипт, например, может выполнять разовую (т.е., без цикла в main) работу длительного характера с выводом результатов работы на экран.

Ну вот этого уж точно не стоит делать: если пользователь сам не позаботился о закрытии окна при завершении скрипта, то значит так нужно.
Чтобы не получать колбеки от "старых" окон можно поступить, как я писал выше:

Николай Камынин, это вы для меня всё написали? Зачем? Что вы пытались этим доказать?
Пример #3 показывает, как работать с последней сделкой из колбека. Что тут не ясно?
Что до этого, то мне не понятно, откуда у nil может быть номер сделки? Не поясните?

Потому что в хранилище Квика сделка попадает после отработки колбека. Поэтому внутри колбека getNumberOf возвращает количество сделок без учёта последней. И взять её значение из таблицы функцией getItem невозможно.
Но вот почему у вас ноль, а не nil - вот это вопрос.

Дело в том, что функция CreateDataSource() заказывает данные по интересующему параметру только в том случае, если этот параметр задан вручную в настройках меню "Связь - Списки...", т.е. полной автономности скрипта в этом месте не достичь.

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

Я писал об этом эффекте: http://forum-archive.quik.ru/forum/lua/124592/124756/
После некоторых раздумий пришёл к выводу, что эту особенность можно использовать для работы со "старым" окном после перезапуска скрипта.   :)  
Можно просто закрыть "мертвое" окно перед повторным запуском скрипта   ;-)  

Если не предусмотрено закрытие окна при штатной остановке скрипта и работа со "старым" окном после этого не требуется, то я обычно удаляю колбек:

Реализация возможности задавать горячие клавиши для любого пункта меню, как это сделано в foobar2000, поставила бы точку в запросах такого типа.

Нет, не так.

Параметры "Кол-во сделок" и "Общее кол-во", по которым я могу сверить сделки по споту, не годятся для ФОРТС:
все сделки сохраняются за период 10:00-23:50, а указанные выше параметры учитывают сделки за период 19:00-18:45

Вы это делали имеено в тот момент, когда "отваливался" QUIK?
Поставьте ping на более длительное время, и для начала WiFi-роутера. Посмотрите, какие показания в момент разрыва связи с сервером.

При экспорте всех сделок в БД обнаружилось, что в один из торговых дней из архива "выпала" часть сделок в середине дня.
Поэтому возникла необходимость проверки, все ли сделки закачаны.
Для спота это можно проверить по параметрам "Кол-во сделок" и "Общее кол-во". Для ФОРТС сложнее: с вечерней сессии отсчёт начинается по-новой.
Есть идеи, как проверить закачку всех сделок для ФОРТС?

Самое первое, что нужно сделать в этом случае, это - проверить качество WiFi-соединения, например командой ping, даже того же роутера.
Часто планшеты, телефоны теряют связь с WiFi-роутером краткосрочно. Этого достаточно, чтобы QUIK разорвал связь с сервером.

Какая практика? Разработчики не в курсе?

Вопрос автора темы изначально был:
Далее, согласно документации
Потому и спрашиваю, есть ли смысл в использовании функции Clear() перед DestroyTable() или DestroyTable() делает то же, что и Clear()?

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

Ответьте, пожалуйста на поставленные вопросы.

Есть ли смысл в использовании функции Clear() перед DestroyTable()?

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

В v.6.16 есть проблемы при завершении скрипта кнопкой "Остановить":
если main() завершится раньше OnStop(), то вызов каких-либо функций QLUA из OnStop() приводит к падению терминала:
http://forum-archive.quik.ru/forum/lua/124475/124533/?page=2/#m124533

Есть некоторая числовая переменная value и условие filter, заданное строкой, например:

Нужно вывести результат применения условия к переменной, как-то так:

К сожалению, это решение немногим лучше его отсутствия: сервер будет перебираться заданное количество раз только при первом обрыве связи, при последующих обрывах - всё меньшее число раз, и, в итоге, перескочит на другой сервер.
Так что вопрос остаётся открытый:

Хотя, наверное, не так. Учитывая, что при вычислении интервала времени между двумя событиями необходимо два измерения, то погрешность может составлять до 30 мс.

А это зависит от величины измеряемого интервала времени. Если не ошибаюсь, погрешность измерения os.clock() может быть от 0.5 до 15 мс.

USE_CASE_SENSITIVE_CONSTANTS

Тогда:

CLASSCODE и  SECCODE не надо указывать?

Что есть "виснет"? Не отвечает на время задержки или зависает "намертво" так, что нужно снимать задачу из диспетчера?

FutLimit.cbplimit ?

Выставляйте заявку в теле main(), а не в колбеках.

Скрытый текст

Цитата sam063rus пишет: ну и? Я хотел показать, что скрипт QLUA не закончил работу, и можно вызывать любые функции QLUA из скрипта. Цитата sam063rus пишет: Цитата main Функция, реализующая основной поток выполнения в скрипте. Для ее выполнения терминал QUIK создает отдельный поток. Скрипт считается работающим, пока работает функция main(). При завершении работы функции main() скрипт переходит в состояние «остановлен». Если скрипт находится в состоянии «остановлен», то не происходит вызовов функций обработки событий терминала QUIK, содержащихся в этом скрипте. С точки зрения самого QUIK здесь нет противоречия   :)   : "Скрипт считается работающим, пока работает функция main()". Кнопка "Остановить" активируется только, когда начинает работать main(). Соответственно, если main() отсутствует в коде скрипта, то и кнопка "Остановить" не активируется. Работает так, как описано в документации. Или описано так, как реализовано.   :)   Просто факты.

sam063rus, как по-вашему, как должен повести себя скрипт, что должно произойти с формой в вашем примере?

Перепишите вот так функцию asd() из первого кода, будет интересней   :)  

Какой dmp? Дампы после ошибки "Internal exception happend" я отправлял. Мне ответили, что ошибка найдена и будет исправлена.

Это уже другой вопрос. После остановки скрипта
кнопкой "Остановить" сбрасываются настройки всех выбранных инструментов для заказа всех сделок.

Продлите, пожалуйста, тестовый доступ: UID: 81512

И там ещё смайлы какие-то непонятные. В коде не должно быть смайлов.

Это ошибка или что?

Вот, правда, не проверял, что там возвращается, но из документации к v.6.16.1.15:

Я не решал подобных задач, но полагаю, что для тех параметров, которые изменяются реже одного раза в мс (а это все параметры из ТТП), можно построить таблицу соответствий вида:
где par1_i, par2_i - значение каждого параметра, синхронизированные по значению ms, как заполняется Таблица изменений параметров:

Другими словами, использование простых переменных (строковых, числовых, булевых...) потокобезопасно, в отличие от таблиц?

Egor Zaytsev,
Да уж хоть что-нибудь реализуйте. Или отреагируйте как-нибудь на предложение.

Егор, это пожелание на доработку.