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

Оперативки точно жрет немерено.
А не проще провести эксперимент самому?

Imersio Arrigo, я не собираюсь дальше продолжать с Вами спор, т.к. считаю это бесполезной тратой времени.

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

Уже подал, пожелание зарегистрировано:
https://forum.quik.ru/messages/forum1/message8857/topic928/#message8857

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

Если бы я не наблюдал такую картину на своем терминале много раз, то не писал бы об этом. Это не мои домыслы или предположения, а многократно подтвержденный факт.

Программа пока что не отжирала у меня больше полутора гигов оперативки. Обычно даже меньше, притом что открыто в ней очень много всего... И если важна стабильная работа, то вполне можно пожертвовать 1 или даже полутора гигами ОЗУ, в ущерб остальным приложениям (которые можно вообще не запускать на машине с терминалом).

Да, точно, невнимательно посмотрел :)

Не пойдет. Символ с кодом 0 - это отнюдь не "0".

Так будет красивей:

Все несколько сложней. При разворачивании квика совсем не обязательно начнется подгрузка данных из файла подкачки в память.
Зато такая подгрузка может начаться и при свернутом окне терминала, если ему в процессе работы вдруг понадобятся какие-то данные, которые были ранее удалены из памяти и, возможно, сброшены в файл подкачки (я не уверен, что они подгружаются из файла подкачки, а не из файлов данных самого терминала).
И процесс такой подгрузки данных с диска в память может оказаться настолько длительным, что в итоге связь с сервером разорвется по тайм-ауту.

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

Вообще-то прописывать в скрипте коды всех клавиш нет необходимости, это нужно только для управляющих клавиш.
Для всех остальных (алфавитно-цифровых) можно использовать простое преобразование кода клавиши в символ, например, так:

Да, понимает. Код каждой клавиши легко узнать, написав простенький скрипт, который будет выводить код нажатой клавиши.

Зацикливать внутри коллбэка ничего не нужно. Каждое новое нажатие клавиши приводит у новому вызову коллбэка, внутри которого это нажатие обрабатывается. Просто после начала редактирования текста в ячейке нужно установить значение какой-то переменной-флага в true, тогда при очередном вызове коллбэка он будет знать, что сейчас работает режим ввода текста и нужно добавить новый символ к строке и т.п. После нажатия Enter флаг ставите = false.

А если, к примеру, время на компьютере не совсем правильное и опережает время сервера, то Lastrecord может быть и больше, чем время сервера?

Что-то я не заметил, а где у вас присваиваются значения переменным cb_open и cb_close

Леонид, а что за терминал на рисунке?

А как без текста сделать метку в виде линии? Использовать файл с изображением?

Вряд ли это поможет исполнить заявку по цене, худшей, чем есть сейчас в стакане.

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

А разве может быть такое, чтобы объем на графике не соответствовал данным из ТВС (ну если не считать каких-то сбоев в работе сервера QUIK)?
Ведь графики строятся на сервере по тем же данным, которые мы видим в ТВС. Или я ошибаюсь?

Сохранить файл в другой кодировке (если была Win то в DOS, и наоборот)

А если написать

Для программиста-пользователя вашего терминала разница будет в том, что если ему нужно проанализировать историю изменений двух и более параметров в совокупности, то при использовании CreateDataSource ему нужно будет самостоятельно собирать внутри скрипта аналог ТИП с использованием значения count (при условии, что вы реализуете исправления в алгоритме формирования этого значения). Если же вы предоставите механизм непосредственного обращения к строкам ТИП из скрипта (аналогично работе с ТВС), то подобная задача сильно упростится. Поэтому подобное пожелание, на мой взгляд, заслуживает отдельной регистрации. А уж сможете ли вы его реализовать, и если сможете, то когда - это другой вопрос.

Поддерживаю пожелание.

Выше речь шла о мегабитах, а не мегабайтах, если вы об этом:
Так что делите это число на 8 (число бит в байте).

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

Ну не то чтобы обманул... Просто не понял, что именно хотел Viktor MMM
Конечно, совершенно самостоятельный скрипт, содержащий функцию main(), так не получится запустить.
Но насчет того, что dofile просто вставляет в текущий скрипт текст из указанного файла, можно поспорить.
Согласно официальной документации функция dofile открывает указанный файл и выполняет его содержимое (хотя конечный итог получается практически такой же, как при вставке текста):

Скорей всего, у Сбера просто заблокирована возможность пинговать их сервер. Если телнет устанавливает соединение на нужный порт, то со связью все ок.
А ругань в вашем первом сообщении скорей всего была как-то связана с региональными языковыми настройками.

Можно, например так:

При желании можно также с помощью тех же самых средств QLua создать поля для ввода и редактирования строк (даже с мигающим внутри такого поля "курсором").
Но вообще средства для создания интерфейсов программ в QLua довольно примитивные, требуют немало времени и усилий от программиста, поэтому тут уже неоднократно звучали просьбы клиентов к разработчикам Quik о развитии этих средств.

пример выпадающих меню:

попытка номер 2

Вот простой пример такого окна:

Да, именно про таблицу с ячейками и отслеживание мыши. Если поковыряться, то можно даже красиво сделать. И не только кнопки Да/Нет, но и всякие чекбоксы и т.п. Если видели интерфейс Far, то он ведь фактически так же выглядит - все кнопки и т.п. из обычных текстовых символов. Зато не надо думать о побочных эффектах использования сторонних библиотек.

Вообще-то создать окно с надписью и кнопками Да Нет и обрабатывать его результаты можно и стандартными средствами QLua (работа с экранными таблицами).
Придется написать побольше кода, будет выглядеть не так красиво, но зато не нужно подключать никакие внешние библиотеки.

Фьючерсы и опционы, возможно, выбираются потому, что терминал всегда получает по ним данные, даже если никаких таблиц по ним не открыто.
Как объясняли разработчики, такова реализация работы терминала, вот ссылка на эту тему:
http://forum-archive.quik.ru/forum/quik/123962/

Признаюсь, я особо не вникал в функционал Вашей библиотеки, но сама возможность вызывать выполнение функций Lua в терминале посредством HTTP-запросов наводит на мысль, что использование такой библиотеки может быть сопряжено с большим риском (несанкционированное вмешательство в работу терминала посторонних лиц через Интернет с целью получения данных или совершения операций по счету).
Наличие открытого кода помогло бы уменьшить подобные опасения.

Было бы очень хорошо, если бы в архиве с каждой новой версией присутствовали также исходники Вашей DLL.

А Вы уверены, что не ошиблись?
В документации по Квик написано, что тип сделки в ТВС (купля или продажа) определяется направленностью заявки, инициирующей заключение сделки:
То есть, согласно вашей документации направление сделки определяется направлением второй заявки.

Разницы между фондовым и срочным рынками Московской биржи в данном случае быть не должно - это уже обсуждалось ранее на старом форуме (причем Вы сами давали тогда в конечном итоге правильный ответ, с учетом которого в дальнейшем была исправлена ваша документация):
http://forum-archive.quik.ru/forum/quik/118273/118273/

Может, не заявок, а сделок?

Интересно, а на объеме, отображаемом на графике, такая сделка тоже не отразится?
Или на значениях параметров ТТП типа "Количество во всех сделках" и "Оборот в деньгах"?

Вопрос еще в том, работает ли эта вещь с любыми классами инструментов (в том числе теми, которые обычно торгуются на бирже) или же такая "кухня" возможна лишь по специально созданным для этого классам инструментов. Во втором случае клиент должен явно указать согласие на обработку своих заявок внутри "кухни" путем выбора специального класса инструментов, не существующего на бирже (типа TQBR_KITCHEN вместо TQBR).

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

Поясню свой вопрос.
Сейчас еще раз провел несложный эксперимент - пометил галочками все классы в меню "Связь/Заказ всех сделок", после чего установил связь с сервером. При этом ни одного тикового графика и ТВС открыто не было. Через час отключился от сервера и открыл ТВС - ни одной сделки за это время не поступило.
Но если бы я при установленном соединении с сервером открыл ТВС хотя бы по одному единственному инструменту, то в итоге терминал получил бы сделки по всем инструментам из тех классов, которые были отмечены в меню "Связь/Заказ всех сделок".

А почему информация по всем сделкам для классов, выбранных в меню "Связь/Заказ всех сделок", не будет поступать в терминал, если в нем не открыто ни одного тикового графика или ТВС хотя бы по одному инструменту?
Получается, что с одной стороны, настройки в меню "Связь/Заказ всех сделок" имеют решающее значение при определении списка классов/инструментов, по которым будут приходить сделки (так как сделки будут приходить по всем выбранным там классам и/или инструментам, даже если по ним не открыты тиковые графики или ТВС), но с другой стороны если в терминале вообще не будет открыто ни одного тикового графика или ТВС, то сделки вообще не будут поступать в терминал. То есть, случайно закрыв единственный тиковый график или ТВС по одному инструменту, можно прервать получение данных по целому списку других инструментов или классов.
Можно исправить такое поведение терминала? То есть сделать так, чтобы обезличенные сделки поступали в терминал с учетом настроек в меню "Связь/Заказ всех сделок" независимо от наличия или отсутствия в терминале тиковых графиков и ТВС?

Здравствуйте!
Правильно ли я понимаю, что для того чтобы в терминал (в ТВС) поступали все обезличенные сделки по нескольким классам достаточно отметить их галочками в меню "Связь / Заказ всех сделок", но при этом нет необходимости открывать тиковые графики или ТВС по всем этим классам, а достаточно иметь открытую ТВС хотя бы даже по одному какому-нибудь инструменту из любого другого класса?

* в коде луа

в строке в коле луа нужно писать \\ вместо \

delphiec _, было бы очень хорошо, если бы Вы выкладывали вместе с остальными файлами также исходник Вашей DLL.

То есть если график не открыт, то CreateDataSource вообще не выдаст нам свечи, сохраненные в кэше?

Я думал, что Вы сравниваете количество свечей на двух графиках Сбера между собой, а потом с графиком Si.

Совершенно верно

По-моему, Вы не вникли в смысл темы, которая обсуждалась выше.
Речь идет о получении истории свечей при первоначальном вызове CreateDataSource (которая обычно достигает 3000 свечей за прошлые дни, плюс сегодняшние свечи). Этот процесс занимает неопределенное время (особенно при одновременном открытии источников данных по нескольким инструментам), а скрипт должен ждать окончания загрузки данных.
Прежде всего нам нужно знать, есть ли вообще такая история на сервере.
Если на момент вызова CreateDataSource на сервере нет ни одной свечи, то мы можем ждать бесконечно долго пока функция Size() вернет значение, большее 0, или придет коллбэк.
Смысл запрашивать количество свечей на сервере есть, и он состоит в том, чтобы избежать подобных ситуаций.

А почему бы не сделать дополнительную функцию, при вызове которой будет возвращаться количество свечей, которое было на сервере по заданному инструменту на момент вызова этой функции?
Она отрабатывала бы намного быстрей, чем CreateDataSource, т.к. не требовалось бы передавать весь массив свечей на терминал.
Вызвав ее, мы смогли бы узнать, какое минимальное количество свечей должна вернуть нам CreateDataSource.
И, самое главное, эта функция всегда возвращала бы нам какое-то определенное значение, даже если свечей по данному инструменту на сервере нет.
Если при вызове этой новой функции мы получим 0, то будем знать, что нет смысла ждать поступления каких-либо данных. Таким образом, проблема бесконечного ожидания была бы устранена на 100%.
По-моему, нет ничего невозможного в реализации такой функции.
Прошу зарегистрировать соответствующее пожелание на доработку.