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

Артем, Нет, дело не в OnTrade - эта скотина недавно тоже обнулилась но в момент подачи заявки, а не прихода прерывания (алгоритмически это именно прерывания, так что мне привычнее так их называть). В OnTrade у меня (как и в любом другом обработчике) ничего не делается, только флаги разные расставляются, чтобы побыстрее умотать оттуда). Но тут, похоже,конфликт прорисовки таблицы (там у меня тоже ничего нет, кроме   SetCell, да SetColor - таблицу я сам рисую) с обработкой транзакции.

Для сравнения, примерно та же картинка после перезапуска скрипта:

Третий или четвёртый раз (только в этом году или, скорее всего, с конца февраля) наблюдаю такую вот картину:

Заголовки и номера строк видны, а содержимое ячеек как корова языком слизнула. Поскольку у меня там в разных ячейках разный не только цвет фона, но и цвет текста, остаётся предположить, что Квик либо рисует текст строго цветом фона либо на рисует его вообще. Насколько я успел заметить, появляется эта прелесть тогда, когда (возможно, в момент прорисовки таблицы) приходит прерывание OnTrade (не уверен, просто гипотеза). В любом случае, я сильно сомневаюсь, чтобы подобное был способен сотворить МОЙ код

Артем, Да ведь коллбеки и есть "информирование что что-то поменялось" - произошла сделка. И что такое "табличные данные"? И почему писать именно в стек? Я и так могу их отсортировать, как бы я их ни писал, только смысла нет: из множества прерываний по одной сделке лишь одно (любое, но лучше первое) следует обработать, а остальные отбросить. Алгоритмически это реализуется тривиально: если ID заявки и ID сделки совпадают с данными ранее пришедшего прерывания, новые данные отбрасываются. Не удаляются, а даже не записываются. Ну и, наконец, я не "опираюсь на последовательность вызова коллбеков" - я вообще считаю, что более одного колбека на одно событие есть маразм, грубейшая ошибка в программном обеспечении, которая, к сожалению, не исправляется годами. Так что вся эта конструкция создана лишь для компенсации этого глюка - в противном случае код упрощается до неприличия, даже по сравнению с моим первоначальным вариантом - не надо даже проверять на совпадение айдишек.

Последние недели две я вылизываю код своего робота (перфекционист хренов! ), и на данный момент у меня осталась непричёсанной только функция OnTrade. Функция довольно неприятная: как известно, прерывания OnTrade (как и OnOrder) приходят пачками, и нет никаких признаков, что проблема эта будет когда-нибудь решена. Самое противное, что прерывания эти приходят не только пачками, но и вразнобой, т.е возможен последовательный приход прерываний по одной и той же заявке order_num, но с разными кодами сделки trade_num, например: trade_num1, trade_num1, trade_num2, trade_num2, trade_num1, то есть первое прерывание trade_num1 мы должны обработать, второе - игнорировать, третье (другая сделка по той же заявке) - обработать, четвёртое - игнорировать, пятое (предыдущая сделка по той же заявке) - тоже игнорировать. Когда я писал обработчик, я предположил, что такой ситуации быть не может "потому, что не может быть никогда". Увы, я ошибся.

Очевидно, что снимать даже исполненные заявки просто так нельзя - обязательно напоремся на повторные прерывания с тем же кодом. Я и держал у себя айдишки заявок и сделок до конца сессии - всё равно они по окончанию снимаются автоматически. А чтобы не было вышеописанных глюков, поставил заглушку "1 заявка - 1 лот". Ни то, ни другое меня более не устраивает. От прерывания OnOrder (и его потенциальных глюков) я отказался с самого начала, но OnTrade хотелось бы сохранить - не в таблице же сделок ковыряться (тем более, там своих глюков наверняка предостаточно). Поэтому алгоритм торговли я сейчас вижу примерно так:

1. Обо всех "своих" заявках (либо сделанных самостоятельно, либо совершённых пользователем вручную через сервис контекстного меню) скрипт, конечно, знает, но ведь юзер может торговать и в обход скрипта, через стаканы! Поскольку скрипт ведёт учёт состояния портфеля, он должен знать и об этих сделках, и узнаёт он о них именно через OnTrade. При этом он способен определить, какая именно это сделка: своя или "левая", но для "левых" заявок он не знает, какой она величины (разве что получит статус "заявка исполнена").

2. Пользователь может не только подать заявку, но и снять её, причём не только свою, но и сделанную скриптом. О таких "подлянках" скрипт не может узнать в принципе (если отказаться от OnOrder и не ползать по таблицам).

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

4. Через некоторое время (скажем, 3-5 минут) скрипт должен принудительно снимать заявки. Собственно, закрытые заявки (здесь уже наверняка пришли все возможные прерывания) не снимаются - просто редактируется паспорт состояния соответствующего тикера, а вот активные (они могут быть только свои, заявки юзера скрипт снимать не имеет права) нужно убивать через KILL_ORDER.

Примерная структура паспорта (i-го тикера), касающаяся заявок/сделок:
[i]["Orders"] - сам паспорт (таблица Lua, то бишь дерево)
[i]["Orders"]["C"] - значение счётчика прерываний по таймеру, после которого можно снимать заявки (пока кажется разумным иметь общее для всех заявок, в противном случае нужно это поле воткнуть в паспорт заявки)
[i]["Orders"]["N"] - количество (незакрытых) заявок
[i]["Orders"][j] - массив паспортов заявок (я люблю C, так что нумерация с нуля).
[i]["Orders"][j]["ID"] - ID заявки в торговой системе
[i]["Orders"][j]["n"] - количество лотов в заявке (для "левых" заявок 0)
[i]["Orders"][j]["N"] - количество сделок по j-й заявке
[i]["Orders"][j][k] - массив паспортов сделок (нумерация с нуля) с (кажется) единственным значением в паспорте: [i]["Orders"][j][k] - ID сделки (чтобы игнорировать "лишние" прерывания)

Что-то громоздко получается... Где наврал?

BlaZed, Да мне, в общем, пофиг - меня устраивает и раз в секунду, и даже реже (сейчас малый обработчик стоит на полутора секундах, большой, как и раньше, на 15. Задержку в 150 мс я поставил не для того, чтобы данные почаще обновлялись, а для того, чтобы на мышку побыстрее реагировало.

Nikolay, Во! Это - похоже!  

Игорь М, Непохоже. Там у меня вообще стоит 10 секунд, а данные обновляются НАМНОГО чаще!

Старатель, Очень самокритично, лапуль! Мне давно уже даже не смешно слышать стоны местных гуру по самым смехотворным проблемам. У нормальных программистов всё давно едет, а у вас... я уже не раз здесь говорил, что "дело было не в бобине".  

Старатель, А мне незачем её читать - я и так знаю, что никаких проблем быть НЕ МОЖЕТ, причём НА ЛЮБОЙ версии в UI64 ЛЮБОЕ 19-значное число влезает с потрохами. Мой скрипт также прекрасно работает НА ЛЮБОЙ версии Lua, номера которых я не знаю и знать не хочу.

Старатель, Какая разница, какая версия Lua? Проблемы В ПРИНЦИПЕ не может быть при использовании unsigned int64! Вот при signed - МОЖЕТ быть, туда НЕ ВСЕ 19-значные числа влезают. И с какого бодуна "здесь используется signed"? Это то же самое число, которое отличается лишь интерпретацией его старшего бита: либо как знаковый разряд либо нет. А что там за проблемы - прочтите самую первую ветку в этом разделе. Лично я её даже не открывал - мне  хватило только её названия: "Важно(!): Грядущие изменения на срочном рынке МБ: поддержка работы с 19-значными номерами заявок и сделок". Хренли там "поддерживать", программисты?    

Старатель, Вы всё никак не успокоитесь? я же показал цитатами ИЗ ВАШЕЙ "документации", что Вы подменили понятия о типах данных конструкций языка типами данных библиотеки.По поводу последней цитаты - видел, повторяю: в языке НЕТ ни типа integer, ни типа float. Если бы они были, не было бы никакой проблемы с 19-значными кодами. И целочисленный тип вовсе не обязательно signed. Ещё 16 октября я писал:
В 64-разрядный integer спокойно влезают даже 20-значные числа - более 18 квинтиллионов! Там работают ВСЕ 64 разряда до единого, и результат не округляется НИКОГДА! А теперь берём калькулятор в левую руку:
0xFFFFFFFFFFFFFFFF в десятичной системе счисления составит 18 446 744 073 709 515 615

Anton, Полистаем 3.4.3...

Bitwise operators, насколько я знаю, здесь вообще нет.

All other arithmetic operations applied to mixed numbers (integers and floats) convert the integer operand to a float - это нормально, но у нас-то была строка!

Ага, вот: "Several places in Lua coerce strings to numbers when necessary". Хренассе, "necessary"!

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

Старатель, Тычок в мегатонные доки? Хотел сразу отписать стандартное: "Читайте сами, раз уж ничего оттуда внятно процитировать не можете". Ну да ладно - пролистаем бегло на первый раз...

Ну так почитайте хотя бы представленную Вами документацию:
1. Lua is a dynamically typed language. This means that variables do not have types; only values do.
2. There are eight basic types in Lua: nil, boolean, number, string, function, userdata, thread, and table.
3. lua_Number. The type of floats in Lua. By default this type is double, but that can be changed to a single float or a long double.
4. Mathematical Functions. This library provides basic mathematical functions. It provides all its functions and constants inside the table math.
5. math.type (x). Returns "integer" if x is an integer, "float" if it is a float, or fail if x is not a number.

P.S. Врот именно, что "результаты ожидаемы"! Умножаем строку на число - этому придурку пофиг! Я и писал чёрте когда:
Ну не делайте из меня идиота! я прекрасно знаю, что строка НЕ равно число! В моём коде индексы SP НЕ "заданы как числа", и я НЕ "пытаюсь обратиться к ним как к строкам". Я лишь ПРЕДПОЛАГАЮ, что раз уж эта антиллехтуальная сволочь не даёт мне возможность самостоятельно описать тип данных, то должна же она ХОТЬ ЧТО-ТО соображать!
Я НЕ "использую числа а где-то строки" - Я НЕ ИМЕЮ ВОЗМОЖНОСТИ самостоятельно описать тип данных, а потому ВЫНУЖДЕН полагаться на антиллехт этого придурка! И у меня ВЕЗДЕ "однотипный способ получения данных" - код я Вам ПРИВЁЛ.

Старатель,
А попробовал! Между прочим, а почему Вы определяете тип с помощью math.type? Тем более, что ни типа integer, ни типа float в языке нет. Мне тут тысячекратно советовали "читать документацию", так в ней чёрным по белом написано: Тип значения, сохранённого в переменной, можно выяснить при помощи стандартной функции type.
А теперь совсем смешно:

Старатель, Я уже приводил полный текст, уже тогда. Как именно я собирался обходить этот глюк с динамической типизацией (и как фактически обошёл)  писал тогда же. Цитирую:
И если вместо обычного описания int a; float b; string c; приходится ТАК извращаться, то это просто УБИЙСТВЕННАЯ характеристику языку! Кому и зачем это надо? Я уж лучше в момент записи данных в таблицы буду принудительно их заворачивать в tostring или tonumber (ещё не решил) и, при необходимости, "разворачивать" их в нужный тип в нужный момент. Если она И ПОСЛЕ ЭТОГО начнёт путать типы данных - это уже в морг.

Старатель, В той теме ошибка была НЕ моя, и связана она была именно с динамической типизацией. Ещё одна фраза по одной из приведённых ссылок:
Да неужели? Не подскажете, почему же в моём примере a[i][1][1] - строка, а после j=a[i][1][1j вдруг оказывается ЧИСЛОМ? И почему добрая половина моих переменных, которые я ВСЕ ДО ЕДИНОГО заносил как строки вдруг оказываются числами?

BlaZed, Ошибаетесь! Я же вижу, как у меня меняются данные, получаемые именно из TTT по BID и OFFER!

Nikolay, Вот! Свечи, кстати, я тоже считаю сам - так надёжнее. :)

Старатель, Вот, чуток покопался, один из примеров (тот самый, про который я говорил):
Значит, говорите, "a[i][1][1] должно быть числом а не строкой"? Допустим. А "j", простите, ЧЕМ должно быть после j=a[i][1][1]? Я ведь ему присваиваю именно СТРОКУ, если Вам верить! Так с какого же бодуна j вдруг оказывается ЧИСЛОМ, и message(i..": SP["..j.."]="..SP[j]) вдруг даёт правильный результат, а message(i..": SP["..a[i][1][1].."]="..SP[j]) - неправильный?

И ещё немного по глюкам - уже только ссылками:
https://forum.quik.ru/messages/forum10/message48635/topic3419/#message48635
https://forum.quik.ru/messages/forum10/message48706/topic3419/#message48706
https://forum.quik.ru/messages/forum10/message49459/topic5872/#message49459

Nikolay, Именно эти слова я и говорил ТОГДА - почти дословно.    

Старатель, Да и мне уже тыщу лет как не надо - я давным-давно "обвистовал" свой код конструкциями вида:
i=j; -- компенсация глюка с переменной цикла
или
i=F; -- костыль от дебилизма с goto
::q:: -- метка аварийного выхода

Nikolay, Ах, да - и переменные были локальные (те, которые индексы).

Nikolay, Кстати, о птичках: проблема с типами была именно В ПЕРВОМ варианте, а во втором она исчезала,    

Nikolay, О, Господи! БЫВАЕТ такое поведение! Ладно, покопаюсь сам на досуге в своих записях - пока не до того...

Старатель, Конкретный лень искать - покопайтесь сами в моих сообщениях, там подобных примеров было штуки три.

Старатель, Да приводил уже, Господи! Почти сразу после моего появления здесь! Когда элемент брался по двойной индексации a=b[i[j]] тип был один, а если заменить на k=i[j];a=b[k] - другой.  

Nikolay, Да я уже тыщу раз говорил: я НЕ МОГУ записать в переменную значение какого-либо типа - это как уж моча в голову интерпретатору ударит. И это ПЕРВЫЙ попавшийся мне язык за мои 40 лет программирования, в котором уничтожен тип integer! Даже в JS, у которого тоже этот идиотский "тип var") он имеется!

BlaZed, Не проще. Оккам запрещает: ведь BID и OFFER по-любому нужны. К тому же, о тормозах здесь и речи быть не может - это же фактически две соседние цены в стакане. доступные даже без наличия самого стакана. Я в меню обновляю эти цены раз в 150 мс - куда уж чаще? Ну, теперь ещё буду читать перед отправкой заявки - по затратам ресурсов это не стоящие внимания копейки. Свечи же (у меня они минимум 15-секундные, у Вас, я полагаю, не меньше) намного тормознутее.

Старатель, Ха-ха-ха! А попробуйте сделать это же с переменной! Тем более, при этой долбаной "динамической типизации" и числовым типом NUMBER - ни int, ни float здесь не предусмотрены. В противном случае, не было бы хотя бы этой дурацкой "проблемы" с 19-значными номерами заявок и сделок.

s_mike@rambler.ru, Ну так поменьше визжите.    Тип INTEGER вернули [Y/N]? Ответить на вопрос способны, "чтец документации" [Y/N]? А если не вернули, см. мой предыдущий вопрос.

s_mike@rambler.ru, Да неужели?! И что, тип INTEGER ввели? А если нет, на кой всё это кастрированное убожество?

Nikolay, Какие уж тут, к чёрту, "быстродействие и наглядность"? Вместо одной ассемблерной команды - вызов функции, вместо угробленного типа INTEGER и красавцев-операторов типа &, | или >>= убожество с указанием номера бита...    

Столкнулся с забавным явлением: у меня робот торгует, ориентируясь только на LAST, а в контекстном меню я пришпилил две кнопки "купить" и "продать" (для ручной торговли через скрипт), и там я повесил уже не LAST, а BID и OFFER (чтобы сделка исполнялась почти мгновенно, но не по рыночной цене). Всё бы хорошо, но сегодня я вдруг увидел там нули: LAST показывает нормальную цену последней сделки (впрочем, она её показывает даже при работе без Инета), а BID и OFFER обнулились. Начал разбираться - оказалось, что нули она показывает не для всех тикеров, а только для тех, по которым торги в данный момент не ведутся (вечерняя сессия на Мосбирже, когда после 19:00 торгуются только "голубые фишки"). Я не раз нарывался на диагностику "Торги по этому финансовому инструменту сейчас не ведутся" когда я или робот хотели что-то купить/продать "не вовремя". А теперь - вот он, индикатор: при подаче заявки буду проверять на 0 эти параметры и не торговать "чем попало". Не знаю, кто и как это делает (если делает), но этот индикатор мне кажется самым удобным. Рекомендую!

Незнайка, Да хоть бы и так - кому нужны эти флаги? К тому же не такие уж и "взаимоисключающие": а вдруг в файле импорта сидят операторы :Lua, которые интерпретируются через loadstring? По крайней мере в моём входном файле сделано именно так.

Anton, Оптимист...    

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

Evgeniy Karnaukhov, Понял, спасибо. Есть такие: три штуки от одного брокера, начиная с 8 октября и заканчивая 14 ноября прошлого года и 4 от другого: один тоже прошлогодний и три февральские. Приму к сведению.

Alexandr Shumilin, Ещё легче проверить это у меня: это была ПЕРВАЯ за сутки заявка на продажу этого тикера, а стоп-заявки я не ставил ни разу в жизни. Мне, конечно, можно не верить, но я-то знаю! К тому же,  не вру ваще никада.    

Roman Azarov, Иными словами, вы (Квик) просто отправляете заявку на продажу, не разбираясь, есть ли у продающего достаточное количество акций или нет? Тогда действительно жульничает брокер. Но это плохо укладывается у меня в голове: брокер сообщил Квику реальное состояние портфеля, и после этого он запрещает мне продавать мои же акции? Это же, по сути, приговор брокеру! Хорошо, я внимательнейшим образом прослежу за подобными ситуациями, и если подобное повторится, буду разбираться с брокером, спасибо.

Константин, Ладно, живите, не трону.  

Evgeniy Karnaukhov, добрый день, Евгений. А что за файл дампа? По выходу какие-то файлы создаются, а Квик у меня падает чрезвычайно редко. Не помню - возможно, он упал вообще в первый раз.

Roman Azarov, Добрый день, Роман.

Первое. что я сделал, получив такую диагностику - заглянул в клиентский портфель: "Да вот же эти акции, стопочкой лежат"! То есть Квик ЗНАЕТ, что акции у меня есть - в портфеле все данные точные. Так какие у меня могут быть претензии к брокеру? Акции - мои, следовательно, я имею право их продать в любой момент. И Квик, и брокер знают, что они мои. Откуда же берётся запрет?

Игорь М, Мне не брокер, а Квик говорит про запреты! К брокеру у меня претензий нет (ни к одному из) - у них данные пока что сходятся тютелька в тютельку! А если вдруг не сходятся, то там совсем другой разговор должен быть, с протоколами сделок за все времена - возможно, в суде. А здесь у меня ДРУГОЙ вопрос: КАКАЯ СВОЛОЧЬ навешала Квику лапшу про мои акции, что он тут мне лекции начал читать про запреты шортов? Брокера обвинять у меня нет оснований, а вот разработчиков - есть!

Nikolay, А сервер брокера здесь каким боком?

Я и так знаю, сколько у меня акций, каких и почём, и это я проверяю прямо у себя на компе. Так что если я подаю заявку, то я уже ЗНАЮ, "какое количество доступно для заявки данного направления". Что там за "проверку параметров заявки на сервере" может учинить брокер? Он считать не умеет?

Ссылки на "периоды высокой нагрузки на сервере брокера" смешны - сколько вообще потенциальных клиентов такого брокера на планете Земля? Всяко на пару порядков меньше, чем у других Инет-сервисов, вроде социальных сетей. Нагрузка велика? Наращивай мощность, если ты брокер! Что значит "задержка может быть существенной"? За пару недель они способны мои акции посчитать?  

s_mike@rambler.ru, Не надо считать меня за идиота. Никаких "предыдущих заявок" нет.

Господа разработчики! Что за хрень? Я пытаюсь продать СВОИ акции, они у меня ЕСТЬ, они принесли мне прибыль, которую я собираюсь зафиксировать. Какой, в задницу, может быть "шорт"? Раз пять уже такое случалось, но. как правило, со второй или третьей попытки акции всё-таки удавалось продать. Но на этот раз Квик с упорством носорога зудит: "Данный инструмент запрещен для операции шорт". Это глюк в программе или неизвестный мне доселе способ воровства моих денег?

Вячеслав, О, Господи! Вы хотите сказать, что с того времени ещё чего-то в эту помойку намешали?

Кому как - по мне так очень даже актуальный. Собственно, я пользуюсь только LAST - для скрипта больше и не надо ничего. Ну, при старте читаю LOTSIZE, хотя он меняется раз в сто лет и нужен только для некоторых рублёвых акций (раньше не читал, брал из входного файла). Ну, для "ручной" продажи/покупки через скрипт с недавнего времени стал подсовывать BID и OFFER (чтобы вероятность мгновенного исполнения заявок приближалась к единице). Ну, отельным столбцом в таблице даю LASTCHANGE, для ориентировки юзера. Иными словами, всё, кроме LAST используется для лишь для разных примочек, для "красивостей". А если таблица ещё и меняет свои поля как перчатки, забивая его всяким барахлом, то это есть место для потенциальных глюков, коих здесь и так предостаточно. И вообще, getParamEx есть функция для получения информации ПО ТИКЕРУ! То есть валюта однозначно определяется кодом класса (а это аргумент а не возвращаемое значение), а вся инфа по торговым сессиям вообще никакого отношения к тикеру не имеет - это НЕ ЕСТЬ проблемы getParamEx.

Да скоко ж можно давать-то? Есть всё в документации...

Список возможных идентификаторов параметров, передаваемых в функцию getParamEx()

 STATUS                  STRING   Статус
 LOTSIZE                 NUMERIC  Размер лота
 BID                     NUMERIC  Лучшая цена спроса
 BIDDEPTH                NUMERIC  Спрос по лучшей цене
 BIDDEPTHT               NUMERIC  Суммарный спрос
 NUMBIDS                 NUMERIC  Количество заявок на покупку
 OFFER                   NUMERIC  Лучшая цена предложения
 OFFERDEPTH              NUMERIC  Предложение по лучшей цене
 OFFERDEPTHT             NUMERIC  Суммарное предложение
 NUMOFFERS               NUMERIC  Количество заявок на продажу
 OPEN                    NUMERIC  Цена открытия
 HIGH                    NUMERIC  Максимальная цена сделки
 LOW                     NUMERIC  Минимальная цена сделки
 LAST                    NUMERIC  Цена последней сделки
 CHANGE                  NUMERIC  Разница цены последней к предыдущей сессии
 QTY                     NUMERIC  Количество бумаг в последней сделке
 TIME                    STRING   Время последней сделки
 VOLTODAY                NUMERIC  Количество бумаг в обезличенных сделках
 VALTODAY                NUMERIC  Оборот в деньгах
 TRADINGSTATUS           STRING   Состояние сессии
 VALUE                   NUMERIC  Оборот в деньгах последней сделки
 WAPRICE                 NUMERIC  Средневзвешенная цена
 HIGHBID                 NUMERIC  Лучшая цена спроса сегодня
 LOWOFFER                NUMERIC  Лучшая цена предложения сегодня
 NUMTRADES               NUMERIC  Количество сделок за сегодня
 PREVPRICE               NUMERIC  Цена закрытия
 PREVWAPRICE             NUMERIC  Предыдущая оценка
 CLOSEPRICE              NUMERIC  Цена периода закрытия
 LASTCHANGE              NUMERIC  % изменения от закрытия
 PRIMARYDIST             STRING   Размещение
 ACCRUEDINT              NUMERIC  Накопленный купонный доход
 YIELD                   NUMERIC  Доходность последней сделки
 COUPONVALUE             NUMERIC  Размер купона
 YIELDATPREVWAPRICE      NUMERIC  Доходность по предыдущей оценке
 YIELDATWAPRICE          NUMERIC  Доходность по оценке
 PRICEMINUSPREVWAPRICE   NUMERIC  Разница цены последней к предыдущей оценке
 CLOSEYIELD              NUMERIC  Доходность закрытия
 CURRENTVALUE            NUMERIC  Текущее значение индексов Московской Биржи
 LASTVALUE               NUMERIC  Значение индексов Московской Биржи на закрытие предыдущего дня
 LASTTOPREVSTLPRC        NUMERIC  Разница цены последней к предыдущей сессии
 PREVSETTLEPRICE         NUMERIC  Предыдущая расчетная цена
 PRICEMVTLIMIT           NUMERIC  Лимит изменения цены
 PRICEMVTLIMITT1         NUMERIC  Лимит изменения цены T1
 MAXOUTVOLUME            NUMERIC  Лимит объема активных заявок (в контрактах)
 PRICEMAX                NUMERIC  Максимально возможная цена
 PRICEMIN                NUMERIC  Минимально возможная цена
 NEGVALTODAY             NUMERIC  Оборот внесистемных в деньгах
 NEGNUMTRADES            NUMERIC  Количество внесистемных сделок за сегодня
 NUMCONTRACTS            NUMERIC  Количество открытых позиций
 CLOSETIME               STRING   Время закрытия предыдущих торгов (для индексов РТС)
 OPENVAL                 NUMERIC  Значение индекса РТС на момент открытия торгов
 CHNGOPEN                NUMERIC  Изменение текущего индекса РТС по сравнению со значением открытия
 CHNGCLOSE               NUMERIC  Изменение текущего индекса РТС по сравнению со значением закрытия
 BUYDEPO                 NUMERIC  Гарантийное обеспечение продавца
 SELLDEPO                NUMERIC  Гарантийное обеспечение покупателя
 CHANGETIME              STRING   Время последнего изменения
 SELLPROFIT              NUMERIC  Доходность продажи
 BUYPROFIT               NUMERIC  Доходность покупки
 TRADECHANGE             NUMERIC  Разница цены последней к предыдущей сделки (FORTS, ФБ СПБ, СПВБ)
 FACEVALUE               NUMERIC  Номинал (для бумаг СПВБ)
 MARKETPRICE             NUMERIC  Рыночная цена вчера
 MARKETPRICETODAY        NUMERIC  Рыночная цена
 NEXTCOUPON              NUMERIC  Дата выплаты купона
 BUYBACKPRICE            NUMERIC  Цена оферты
 BUYBACKDATE             NUMERIC  Дата оферты
 ISSUESIZE               NUMERIC  Объем обращения
 PREVDATE                NUMERIC  Дата предыдущего торгового дня
 DURATION                NUMERIC  Дюрация
 LOPENPRICE              NUMERIC  Официальная цена открытия
 LCURRENTPRICE           NUMERIC  Официальная текущая цена
 LCLOSEPRICE             NUMERIC  Официальная цена закрытия
 QUOTEBASIS              STRING   Тип цены
 PREVADMITTEDQUOT        NUMERIC  Признаваемая котировка предыдущего дня
 LASTBID                 NUMERIC  Лучшая спрос на момент завершения периода торгов
 LASTOFFER               NUMERIC  Лучшее предложение на момент завершения торгов
 PREVLEGALCLOSEPR        NUMERIC  Цена закрытия предыдущего дня
 COUPONPERIOD            NUMERIC  Длительность купона
 MARKETPRICE2            NUMERIC  Рыночная цена 2
 ADMITTEDQUOTE           NUMERIC  Признаваемая котировка
 BGOP                    NUMERIC  БГО по покрытым позициям
 BGONP                   NUMERIC  БГО по непокрытым позициям
 STRIKE                  NUMERIC  Цена страйк
 STEPPRICET              NUMERIC  Стоимость шага цены
 STEPPRICE               NUMERIC  Стоимость шага цены (для новых контрактов FORTS и RTS Standard)
 SETTLEPRICE             NUMERIC  Расчетная цена
 OPTIONTYPE              STRING   Тип опциона
 OPTIONBASE              STRING   Базовый актив
 VOLATILITY              NUMERIC  Волатильность опциона
 THEORPRICE              NUMERIC  Теоретическая цена
 PERCENTRATE             NUMERIC  Агрегированная ставка
 ISPERCENT               STRING   Тип цены фьючерса
 CLSTATE                 STRING   Статус клиринга
 CLPRICE                 NUMERIC  Котировка последнего клиринга
 STARTTIME               STRING   Начало основной сессии
 ENDTIME                 STRING   Окончание основной сессии
 EVNSTARTTIME            STRING   Начало вечерней сессии
 EVNENDTIME              STRING   Окончание вечерней сессии
 MONSTARTTIME            STRING   Начало утренней сессии
 MONENDTIME              STRING   Окончание утренней сессии
 CURSTEPPRICE            STRING   Валюта шага цены
 REALVMPRICE             NUMERIC  Текущая рыночная котировка
 MARG                    STRING   Маржируемый
 EXPDATE                 NUMERIC  Дата исполнения инструмента
 CROSSRATE               NUMERIC  Курс
 BASEPRICE               NUMERIC  Базовый курс
 HIGHVAL                 NUMERIC  Максимальное значение (RTSIND)
 LOWVAL                  NUMERIC  Минимальное значение (RTSIND)
 ICHANGE                 NUMERIC  Изменение (RTSIND)
 IOPEN                   NUMERIC  Значение на момент открытия (RTSIND)
 PCHANGE                 NUMERIC  Процент изменения (RTSIND)
 OPENPERIODPRICE         NUMERIC  Цена предторгового периода
 MIN_CURR_LAST           NUMERIC  Минимальная текущая цена
 SETTLECODE              STRING   Код расчетов по умолчанию
 STEPPRICECL             DOUBLE   Стоимость шага цены для клиринга
 STEPPRICEPRCL           DOUBLE   Стоимость шага цены для промклиринга
 MIN_CURR_LAST_TI        STRING   Время изменения минимальной текущей цены
 PREVLOTSIZE             DOUBLE   Предыдущее значение размера лота
 LOTSIZECHANGEDAT        DOUBLE   Дата последнего изменения размера лота
 CLOSING_AUCTION_PRICE   NUMERIC  Цена послеторгового аукциона
 CLOSING_AUCTION_VOLUME  NUMERIC  Количество в сделках послеторгового аукциона
 LONGNAME                STRING   Полное название бумаги
 SHORTNAME               STRING   Краткое название бумаги
 CODE                    STRING   Код бумаги
 CLASSNAME               STRING   Название класса
 CLASS_CODE              STRING   Код класса
 TRADE_DATE_CODE         DOUBLE   Дата торгов
 MAT_DATE                DOUBLE   Дата погашения
 DAYS_TO_MAT_DATE        DOUBLE   Число дней до погашения
 SEC_FACE_VALUE          DOUBLE   Номинал бумаги
 SEC_FACE_UNIT           STRING   Валюта номинала
 SEC_SCALE               DOUBLE   Точность цены
 SEC_PRICE_STEP          DOUBLE   Минимальный шаг цены
 SECTYPE                 STRING   Тип инструмента

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

Евгений, Да, но как вообще это может быть? Чтобы комп не успевал за сраной клавой - такого не было даже на моём первом компе с его 640К ОЗУ, 5М винта и 4.7 МГц! Это как же надо изуродовать софтину!

Я, честно говоря, даже не смотрю на версии - тупо обновляю всё, что предлагают - уже около десятка раз обновлял. У меня тоже два брокера, причём у каждого разные версии. Много разного дерьма видел и в Квике, и в Луа, но от ТАКОГО пока что Бог миловал. Несколько заявок секунду тоже пару раз случалось, но и там всё работало как часы...