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

Anton, По моему разумению, неплохо бы сделать так:

1. Юзер формирует таблицу текущих торгов, включая туда те инструменты, по которым ему интересны обновления (это даже не дело скрипта - это настройка Квика). Если юзер намерен и сам торговать (как я, например), эта таблица должна быть видимой (у меня она "едина в трёх лицах": а) акции, торгующиеся на рубли, б) на доллары и в) на евро), в противном случае может лежать в свёрнутом виде на какой-нибудь ненужной вкладке - тогда она выполняет роль инструкции Квику обновлять данные по этому набору инструментов, чтобы скрипт всегда имел по ним актуальные данные.

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

3. Квик сам обрабатывает все прерывания, а юзеровские "коллбеки" обслуживает в фоновом режиме как если бы они находились в потоке мейна. Таковых (у меня) всего лишь 4 штуки: OnStop, OnTimer, OnTrade, да OnOrder, и я (пока) не вижу смысла в остальных (ну, кроме обработки событий от юзера в моих таблицах).

Сложность - минимальная, скорость - максимальная, надёжность - максимальная. Ну сказка же, господа!

P.S. У меня два Квика для разных брокеров, у одного версия 8.7.1.3. у другого 8.10.1.1, на обоих мой скрипт прекрасно работает. А вот вчера зашёл к другу моему - не работает (у него версия 8.6 и ещё что-то там). Начал разбираться - оказывается, он ругается на goto и на метки (я всё-таки пристроил этот кастрированный goto для эмуляции украденного из языка continue). Ну это совсем уж свинство, господа! Язык, конечно, дерьмо, но соответствовать описанию он всё же должен! Версии плодятся, как тараканы - так почему бы не сделать одну, но нормальную?

1) OnTimer прекрасно эмулируется в цикле со sleep, там же указывается период срабатывания (у меня их даже два: раз в полторы секунды и раз в 15 секунд). А никакого OnInit вообще нет.

2) С потоками разработчики вообще перемудрили - нельзя туда пускать юзера вообще, не его это свинячье дело, в каком потоке что выполнять. И так уже управление теряется между потоками, а коллбеки способны подвесить Квик!

swerg, ... и переходим в другой форум.    

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

Когда-то давно (ещё и Windows не существовало) мы делали защиту, основанную на привязке к винту компьютера. Дело в том, что диски физически разные (длина дорожек разная), и можно, варьируя размер межсекторного промежутка при форматировании дорожки, шифровать эти данные и проверять на соответствие реальным размерам выбранных в качестве ключа дорожек конкретного диска. Но это уже даже не уровень BIOS - это работа напрямую с контроллером дисководов, и никакая нынешняя ОС туда прикладника просто не пустит. Да и вообще, неблагодарное это занятия - весь мир постепенно движется именно к открытому коду. НЕ НУЖНО ограничивать возможность запуска, даже если это было бы и возможно!

Ok, спасибо. А снимать заявки я не собираюсь вообще.    

Roman Azarov, И что делать? А по OnOrder это дело ловится? Если верить описанию, при любом изменении параметров заявки эта штуковина должна бы вызываться (именно по ней вкупе с OnTrade я и собираюсь отслеживать состояние торгов).

А мне нужен и ID отправляемой заявки - я его знаю НЕ ВСЕГДА. Вы все говорите о ситуации, когда заявку посылает сам робот, а если её послал юзер, независимо от робота?

swerg, Да, к сожалению. Но у меня диалог фактически получился: основная таблица по тикерам с тремя режимами выдачи (возможно, лучше с четырьмя - ещё один режим "остановить/включить обновление таблицы, чтобы юзер мог спокойно изучить её текущее состояние), переключение между ними закольцовано по двойному клику по крайнему левому столбцу или по клавише "пробел". За всё остальное отвечает всплывающее меню (двойной клик по ячейке с именем тикера). Теоретически его вызов можно бы и задублировать на клавишу Enter, а выход из меню на Esc, но лично я клаву сюда решил подключать только по необходимости. В этом меню две кнопки "купить" и "продать" для немедленной отправки заявки (возможно, их стоит задублировать по клику на какие-нибудь ячейки строк основного меню), да настройка статуса тикера (фактически пара битовых флагов, объединённых в код статуса тикера) - разрешить/запретить роботу покупать/продавать самостоятельно по этому тикеру (по умолчанию всё запрещено). Вот, собственно, и весь диалог, и лично  не вижу причин для дальнейшего наращивания его функциональности. Юзер, разумеется, может самостоятельно совершать сделки (робот ловит это дело по OnTrade). С транзакциями я пока толком не разобрался, так что тупо запретил подачу заявок, пока не исполнена предыдущая. Возможно, так и оставлю в окончательной версии скрипта.

Анатолий, Ещё один знакомое слово увидел, а текст почитать не удосужился...    

TGB, Я не знаю, что там за "метрики берутся за основу" - я работаю только с текущими курсами (ну или там с минутными свечами, в которых меня интересует только цена закрытия), и мне абсолютно по барабану, чем именно вызваны движения курса: поведением толпы, инсайдерской информацией, вбросами в СМИ или ещё чем. Мой алгоритм работает на исторических данных точно так же, как и на реальных. И работает (тьфу-тьфу!) хорошо!

nikolz, Исторические данные отличаются от реальных лишь тем, что берутся из файла (из БД), а не поступают в реальном времени от того же Квика, а потому алгоритм, который хорошо работает на исторических данных будет столь же хорошо работать и на данных реальных - просто входной поток данных приходит из другого места. Алгоритм ZigZag тупой - это другое дело, и тупой он КАК на исторических данных, ТАК И на данных реальных.

Ого! Развёрнутое ТЗ от заказчика - штука уникальная! Хоть меня эта тема вообще не интересует - придётся почитать...  

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

Не бывает в природе таких уровней, которые рынок не может пробить. Как не бывает ситуаций "вот вот будет разворот" - бывает только "разворот уже есть".

Что такое "LOT = 0.01" - не понял.

Профит (убыток) по текущему рыночному ордеру у меня подсвечивается цветом фона в ячейке таблицы - дело не в "красивости", а в наглядности: чем синее фон, тем настойчивее рекомендация "купить", чем краснее - тем настойчивее рекомендация "продать". Один беглый взгляд на таблицу даёт больше, чем любой график.

Если "размер и цвет шрифта настраиваемый" - можно забыть про Lua.  

Скорость движения рынка - штука относительная. Во-первых, она сильно зависит от выбранного таймфрейма. Во-вторых, то, что для одного тикера нормальная скорость, для другого может характеризоваться как "бешеная".

"Ловить резкие развороты и движения рынка" - играть в МММ. У меня любые резкие движения тупо игнорируются - слишком велика вероятность быстрого возврата к "нормальному" состоянию.

Алгоритм очень разветвлённый, а потому потенциально напичкан ошибками, причём трудноуловимыми. Версий двадцать понадобится, чтобы такой алгоритм заработал. Я не Нострадамус, но...  

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

Оформляю свой скрипт в боевой режим, пытаюсь сделать максимально удобный UI для юзера (то бишь для себя,любимого) и, соответственно, сталкиваюсь с проблемами, описанными в этой ветке. По пунктам (нумерацию использую от головного поста Дениса):

1. Основной источник информации - та самая "таблица, созданная с помощью CreateWindow" с какими-то там столбцами. Столбцы и строки нумерую с единицы, при этом нулевая строка есть заголовки столбцов, а вот в нулевой (невидимый) столбец загоняю идентификаторы строк, полученные от InsertRow, что и рекомендую делать всем и всегда: проблема, описанная в пункте 1, снимается напрочь: да, клик мышкой по какой-либо ячейки даёт порядковый номер строки в конкретном представлении, но в нулевом столбце теперь сидит "настоящий" номер этой строки - именно по нему нужно обращаться при SetCell или SetColor.

2. Как сделать ячейку таблицы доступной для редактирования с клавиатуры, лично мне даже думать лень - очевидно, задача эта легко разрешима (кроме мигания курсора) с помощью GetCell, SetCell и подключения соответствующего обработчика от клавиатуры. Прогнозирую также кучу потенциальных проблем, связанных с потерей фокуса. Я же по dblClick по ячейке (с кодом тикера) вызываю всплывающее меню, и вообще клавой на Lua предпочитаю не пользоваться (в отличие от организации диалога на C - там именно клава есть основной механизм для обработки событий).

3. Клавиша Del (код 46) действительно не срабатывает на событии от QTABLE_CHAR, зато она прекрасно ловится по QTABLE_VKEY. А вот функциональные клавиши (кроме F11, F12) не ловятся - они зарезервированы Квиком. Комбинации с Ctrl-Alt-Shift также невозможны (у меня, к тому же, нажатие Shift выдаёт код 16, а Ctrl и Alt - одинаковый код 17) - да и хрен бы с ними!

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

6-14. А вот это даже знать не хочу! Диалог - шука непростая, и Lua - не тот язык, на котором нужно делать разные "красивости". Функциональность есть - и достаточно!

15. Создать собственный паспорт таблицы и настраивать его хоть в диалоге! Мне такое не нужно, и вряд ли когда-нить понадобится.

Jedem das Seine    

DVN, Именно! Лично я делаю это раз в полторы секунды, а заявки предпочитаю вообще не перемещать: продавать по bid и покупать по offer. Одним словом, предпочитаю обходиться вообще без стаканов.

DVN, Нет,, серьёзно - getParamEx можно взывать с "LAST", "BID", "OFFER - зачем же нужны стаканы?

DVN, Ну так читайте именно bid и offer - стаканы-то Вам зачем?    

Alexey Ivannikov, А у вас самих разве нет такого списка? Я здесь совсем недавно, но и я могу штуки три проблемы назвать.

Alexey Ivannikov, И то правда: путаются тут под ногами всякие юзеры - можно подумать, мы для них тут работаем.

Александр М, Пять баллов! Браво! На мой взгляд, это лучшее из всех возможных предложений. Раками и ногами "за".

Александр, Не заткнётесь... ну, повизжи лапуль, повизжи - по "методике вытравливания головожопых" говно должно отвизжаться.

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

Александр, Лапуль, головожопые - это наш профиль, и вытравливаю я их вполне профессионально - просто не хочется этим заниматься ЗДЕСЬ. Может, заткнётесь по-хорошему, а?

Nikolay, Кстати, всплывающее меню у меня заработало, и данные появились, и свой обработчик событий подключился. При клике по основной таблице ставлю флаг необходимости прорисовки меню, а в цикле по этому флагу вызываю функцию, которая набивает меню данными (Clear сделать забыл, так она при каждом новом вызове дополнительные строки лепит   ) и подключает к нему свой обработчик событий (не рискнул сделать это в main, там только AllocTable, да AddColumn). Короче, вся интересующая меня функциональность практически реализована.

Александр, Лапуль, я писал диалоговые программы, когда ещё никакого Win ваще не было, как и слова такого "api". OnInit мне НАФИГ НЕ НУЖЕН - есть main, и этого более, чем достаточно. И мне нужен диалог НА ЭТОМ языке, а не на какой-то подключаемой херне, написанной дядей Васей. Это не "решение", лапуль - это называется "говно".   Это при том, что С как раз мой любимейший язык на протяжении десятилетий, а Lua - очевидное говно. Но ЗДЕСЬ надо писать именно на Lua - язык ПОЛНОСТЬЮ обеспечивает необходимую функциональность - по крайней мере, для робота, которому все эти таблицы и весь этот диалог нафиг не нужны - это всего лишь дополнительный сервис для юзера, который торгует вместе с роботом.

Александр, Лапуль, я УЖЕ сделал какой-никакой диалог на Lua. И сделаю лучше - именно это я и хотел бы обсудить здесь, КАК это лучше сделать. Отойдите в сторонку, плиз, не путайтесь под ногами.

Александр, Лапуль, я ПИСАЛ подобные библиотеки! И добрая половина моих программ как раз диалоговые - в том числе, для проверки подключаемых к PC электронных модулей, в т.ч. с собственными микропроцессорами (загрузчик и пошаговый отладчик таких "внешних" программ тоже писал). Ну куда Вы прыгаете с голой жопой против танка, мальчишка сопливый?    

Александр, Лапуль, я не только 40 лет программистом - я ещё и почти 30 лет (я в Инете с 1992 года) гоняю всякую полуграмотную распальцованную шушеру.   В то время, кстати, никакого Гугла ещё и в помине не было, Альтависта была. И Яндекс уже был, и я был лично знаком с Ильёй Сегаловичем (была у нас одна совместная работёнка).

Я же сказал: меня НЕ ИНТЕРЕСУЮТ "сторонние библиотеки", меня интересует организация диалога на языке Lua! Сколько раз повторить, чтобы дошло, наконец?

Александр, Милок, если по теме сказать нечего, лучше помолчите, не нарывайтесь.    

TGB, Отчего же не рассмотреть? Во-первых, я и в страшном сне не могу представить такой "богатой функциональности", которая требует 5 минут для выполнения. Во-вторых, при чём тут, собственно, таблица? Это лишь обработчики от криворуких разработчиков - таблицы и вообще может не быть. В-третьих, ЕСЛИ события не успевают обработаться, ТО из них обычно образуется очередь, а при её переполнении вновь поступающие события просто сбрасываются - совершенно нормальное поведение даже на уровне многопроцессорных систем, а не какого-то сраного интерпретатора.

Вот И НЕ НАДО сваливать всё в одну кучу! Есть поток КВИКА, а есть потоки интерпретируемых им скриптов юзера - зачем же сваливать их в одну кучу?

Согласен, межпроцессное  взаимодействие особых проблем не представляет.

TGB, Да и колбеки не хило бы там же обрабатывать.    Что мы ловим? Скорость? Смешно - это же интерпретатор. Тем более, что по OnTrade она аж по три штуки колбека вызывает - на кой спрашивается?

Nikolay, сначала "в чем, собственно, проблема": мне хочется имет всплывающее меню, а оно у меня "всплывать" не хочет.  

Полностью согласен: таблица - это объект, а её прорисовка - один из его методов - что-то типа DrawTable, DrawRow, DrawCell.

Особо наполнять его обратными вызовами не хочется - меня тут на днях совершенно оглоушил Антон, рассказав, что обработчики здесь как священная корова, вызываются напрямую, и пока не закончат свою работу, Квик висит. Я пока вижу два обработчика: один на основную таблицу, другой на всплывающее меню. А "настройки окна" у меня действительно лежат в другой таблице (точнее, в дереве объектов), из которой я и набиваю таблицу визуализации - тоже согласен.

А почему бы и не "написать простыню в main"? Инициализация (у меня) - штука одноразовая (на сеанс) - ей самое место именно в main (OnInit я выбросил).

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

А вот не согласен! Я использую именно "номера колонок, строк как идентификатор ячейки"! У меня в основной таблице может быть до нескольких сотен строк и в данный момент там 22 столбца - номер использовать удобнее всего! Просто не надо забывать, что это на самом деле имя.

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

Nikolay,Во! Это уже что-то похожее на обсуждение! Но отвечу попозже - сейчас биржа открывается, а у меня там несколько интересных позиций намечается...

swerg, А при чём тут "визуальные элементы"? На этом форуме ещё несколько лет назад говорилось, что подготовка таблицы и прорисовка таблицы - это РАЗНЫЕ вещи, и давались предложения к разработчикам (проигнорированные) разделить эти вещи. Какое отношение к "визуальным элементам" имеет AllocTable? Или AddColumn? Или даже SetTableNotificationCallback, равно как и SetColor? Вот CreateWindow - имеет. Ну, SetCell, пожалуй, имеет (да и то спорный вопрос). Я свою таблицу визуализации готовлю именно в main! А строками её набиваю уже в "большом" прерывании (15-секундном), А ячейки значениями заполняю и раскрашиваю - уже в малом, полуторасекундном. При этом все три находятся именно в потоке main! Более того: ИМЕННО ТАК И НУЖНО делать - в данном случае "квиковцы" поступили совершенно правильно!

Да какой, в задницу, "полный код", если обсудить предлагается концепции, философию, алгоритмы? Кому он нужен, этот "полный код"? Я и хочу ОБСУДИТЬ, "что ожидается, как на самом деле и как сделать ожидаемое"! Я хочу поговорить С ПРОГРАММИСТАМИ! На кой мне эти "запускатели полного кода", которые "в вопросы такого плана вникать не будут"?

Господи, я же русским языком сказал: я хочу обсудить ДИАЛОГ НА LUA! Меня Не ИНТЕРЕСУЮТ все эти долбаные "полноценные интерфейса из внешних библиотек! ВААПЩЕ нее интересуют!

nikolz, Меня не интересуют API C для LUA, меня интересует тот вопрос, который вынесен в заголовок.

Если я ничего не напутал, возможности для организации диалога с пользователем (меню, чекбоксы, редактируемые поля и т.п.) практически отсутствуют. Между тем, скрипт в моём понимании есть не только (и даже не столько) торговый робот, сколько помощник юзера, обеспечивающий ему условия для комфортной торговли. Иными словами, он должен
а) снабжать пользователя необходимой актуальной информацией;
б) выполнять его команды;
в) самостоятельно совершать сделки в определённых юзером рамках;
г) быть в курсе действий пользователя, если тот торгует самостоятельно (режим "кентавра").

Возможности редактирования полей (например, указание цены покупки/продажи) или там чекбоксов я не нашёл, от слова "совсем". Короче, весь диалог, видимо, приходится строить только на "таблицах Lua". В использовании клавиатуры для диалога (например, стрелки, клавиши Enter, Escape) я пока не вижу особой необходимости, а вот мышку задействовать хотелось бы.

Сначала я создал собственную таблицу, похожую на таблицу текущих торгов, но содержащую интересующие меня сведения (текущая цена, информация о моих сделках, подсчёт текущей прибыли/убытка по каждому тикеру и т.п.), стал подкрашивать разные поля для наглядности. Всё бы хорошо, но таблица получилась довольно громоздкой, и я стал выдавать её в трёх режимах:
а) все тикеры, которые у меня есть или которые я хотел бы приобрести при случае;
б) все тикеры, по которым у меня есть покупки;
в) все тикеры, которые, по мнению скрипта, заслуживают моего внимания в данный момент (самый компактный вид).

Переключение режимов я организовал по двойному клику по левому столбцу (который с номерами строк и который в некоторых случаях было бы очень неплохо убрать, но я не умею), повесив на таблицу свой обработчик с помощью SetTableNotificationCallback(T,E), примерно так:А в мейне проинициализировал:
iB=1; -- тип выдачи: 1 - нужные, 2 - свои, 3 - все
B={2,3,1}; -- переключатель по типу выдачи (левый столбец)
В качестве кнопки "сохранить результаты" приспособил заголовок левого столбца (в который тоже не хило бы записать что-то типа "Save", но я не умею).

С помощью Lua "и какой-то матери" эта конструкция заработала вполне удовлетворительно, но это, так сказать, "групповуха", команды для ВСЕЙ таблицы. А вот при клике по ЯЧЕЙКЕ (с кодом тикера) хотелось бы иметь уже всплывающее меню, специфицирующее действия конкретно по этому тикеру, со своим обработчиком, примерно так:
"Купить" - приказ немедленно купить;
"Продать" - приказ немедленно продать;
"Auto" - разрешить скрипту самостоятельно совершать сделки с этим тикером;
"Вручную" - сделки по этому тикеру выполняет пользователь, и только он.

Проинициализировал такую таблицу прямо в мейн (как и таблицу визуализации результатов), а в обработчике повесил на клик по ячейке с кодом тикера соответствующий CreateWindow, и тут началась АМБУЛА.

Окно-то прорисовывается, но ПУСТОЕ. Подумал: я же в обработчике его вызываю! Стал там только устанавливать флаг необходимости прорисовки окна меню, а в цикле (в котором sleep) вставил:
if ft==1 then CreateWindow(t);ft=0;end;
Пофиг - окно снова рисуется, и снова пустое (заголовков и номеров строк тоже нет). Помню, там какая-то последовательность операторов была важна (уже забыл, какая) - может, в этом дело? Или прямо в цикле надо набивать таблицу значениями. Короче, мне это дело надоело, отложил до завтра, а здесь хотел бы послушать соображения на тему организации диалога. Например, неплохо было бы иметь аналогичную таблицу (вызываемую, видимо, по горячей клавише) с настройками работы скрипта прямо в процессе его исполнения.

Обсудим, господа?

Anton, Правильно ли я понимаю, что при нажатии кнопки останова скрипта управление передастся именно в МОЙ обработчик OnStop, и если я туда воткну функцию записи результатов в файл (не занимаясь при этом "табличными" делами, требующие обращения к функциям основного потока), то ни одна собака не посмеет прервать мой обработчик, и файл результатов будет-таки гарантированно записан?

Anton, Не, Вам я верю на слово. Одуреть! Воистину, программисты вымерли...

Anton, Сильно сомневаюсь! OnStop ЮЗЕРА - это вовсе не OnStop Квика, равно как и другие обработчики - тем более, эмулятор прерывания по таймеру - это же самое важное прерывание в компе, высший приоритет! А тут какой-то дебил, вроде меня, начнёт там выполнять всякую хрень вроде задачи коммивояжёра - он что, Квик подвесит? Как говорил Станиславский, НЕ ВЕРЮ! Главный поток ОБЯЗАН получить управление по нажатию кнопки, причём НЕМЕДЛЕННО! Чем бы он там ни был занят в OnTrade.

Roman Azarov, Ну, раз "Дело имеем с таблицей созданной с помощью CreateWindow(t_id)", я полагаю, что это примерно такая же таблица, как и у меня.

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

УХ ТЫ! Прямо пока писал про OnTrade, на одном из моих Квиков выскочило сообщение (у меня там сейчас стоит заглушка):
function OnTrade(trade)
message("OnTrade! "..trade.price.." "..trade.qty.." "..trade.value.." "..trade.sec_code.." "..trade.class_code);end;

Сообщение такое:
OnTrade! -141.0 1.0 -141.0 RUREQTV INSTR
Это что за пьяные выходки?    (брокер - Сбер)

Anton, Так тела колбеков и расположены в мейне! Впрочем, не проверял - я по-прежнему считаю функцию внутри цикла "колбеком" - это же фактически прерывание по таймеру. Так что, если я нажму на кнопку останова, а скрипт в это время будет обрабатывать прерывание OnTrade, то управление должно вернуться КУДА?

Anton, Тоже не поможет - в момент останова скрипт может выполнять код какого-то обработчика, а не сидеть в мейне на sleep. Но, в любом случае, делать нужно именно "по-хорошему" - так наглючит уж никак не больше. А "по-плохому" скрипт должен периодически сохранять важные данные - по таймеру, по какому-нить OnTrade или даже по кнопке "Сохранить результаты".

Roman Azarov, Проверил - это тоже не поможет: это же не окно Квика, а окно скрипта. Во-первых, действие "закрепить окно" не просто закрепляет его на вкладке, но и отрубает возможность перемещать окно даже внутри вкладки. Во-вторых, если убить Квик, не останавливая скрипт, он автоматически запустится при повторном запуске Квика, и окно создаст именно на той вкладке, на которой Квик был убит, несмотря ни на какие закрепления.

Стал подключать обработку событий от юзера - с ходу напоролся на ситуацию, за которую я когда-то высмеивал Дениса: SetCell у меня заносит данные по ID строки таблицы, которую я получил от InsertRow(T,-1), и заносит правильно. Правда, при удалении строк у него крыша едет, и он начинает заносить правильные значения в неправильные номера строк, и потому при удалении строк (при вставке всё нормально работает) приходится перебивать заново всю таблицу: Clear(T) + колода InsertRow(T,-1). А вот при клике на ячейку мышкой GetCell получает данные уже не по ID строки таблицы, а по её порядковому номеру в конкретном представлении, который действительно зависит от сортировки. Добавил в таблицу ещё один (невидимый) столбец, в который заношу ID тикера в МОЕЙ таблице тикеров, а там одним из полей сидит lD строки таблицы, полученный от InsertRow (если тикер в данный момент показывается в таблице). То есть нужны сразу три (закольцованных) индекса: один для GetCell по событиям от мышки, второй для SetCell для правки данных в таблице и третий для моих алгоритмов. Ах, да - все данные в таблицу заношу только как строки и читаю только как image, а не как value, дабы избежать потенциальных проблем с преобразованием типов от "интеллекта" интерпретатора. Работает...  

swerg, Может, хватит, господа?   Сначала один нёс какую-то клиническую ахинею про "роботов и всякие прочие глупости", да ещё с гнутыми пальцами вроде "вы даже понимаете суть вопроса". Получил щелчок по носу - теперь чего-то шипит про "троллей". Потом второй начал пальцы гнуть на тему API в том же ключе: "По-моему вы ничего не понимаете", да про int-float ("Как бы по мягче сказать, что вы не разбираетесь в теме. Повторю в квике 7, lua 5.1 - в нем не числа хранятся типом double, соответственно нельзя хранить int64"), да про "не надо путать стек процессора и стек Lua - это разные стеки. Вам бы документацию почитать и хорошенько разобраться в луа", да про "выучи английский", да про "умение читать документацию и гуглить", после чего вообще забился в истерике. Потом третий понёс пургу про "монстров фондового рынка", и тоже с гнутыми пальцами: "Вы еще далеки от понимания реальности фондовых рынков" и совсем уж клинический бред с ещё большей распальцовкой: "вот некоторые из аксиом, которые надо усвоить и научится программировать", затем бред про мантиссы ("для справки: Разрядность мантиссы в 64 битном вещественном числе составляет 52 бита, что  позволяет точно отобразить лишь 16 разрядное десятичное целое число, а не  18 квинтиллионов, как наивно полагает Владимир"), затем про "это VM а не интерпретатор", и тоже с истерикой: " в языках и виртуальных машинах вы ноль без палочки"... я прям утомился этому неучу по носу щёлкать!   Потом Вы. Ваша квалификация несколько выше, но стиль тот же, вплоть до прямой лжи: "Как уже всем известно, документацию Владимир не читает". А причина-то в другом - просто я с раннего детства не перевариваю распальцованных дураков и редко спускаю им их "поучения".

А "вопрос, который давно Вас заботит", выеденного яйца не стоит, ибо main есть ВСЕГДА! Поймите же, наконец, простую вещь: ЛЮБОЙ интерпретатор ОБЯЗАН знать, когда и с какого места нужно начинать интерпретировать представленный код, когда и в каком месте нужно прекратить это делать. И лучший способ это сделать - создать утилиту с согласованным именем: тот самый main. Эта технология была разработана ещё в прошлом тысячелетии - тогда на планете Земля ещё водились программисты. И на Ваш вопрос: "А если скрипт сам захотел остановиться - откуда OnStop возьмётся?!" ответ уже давался: сбрасывайте этот дурацкий флаг isRun НЕ ТОЛЬКО в OnStop, а в любом другом месте, где он "захотел остановиться". Или воткните в этот дурацкий цикл НЕ ТОЛЬКО sleep, но и хоть сотню конструкций if blah-blah-blah then break;end;

P.S. На всякий случай только что проверил оба способа - всё прекрасно работает.

swerg, Чушь. Кто именно и с какого бодуна вдруг станет "брать скрипт" и, тем более, "начнёт него дергать колбеки по мере поступления событий". Как этот "кто-то" вообще узнает, что нужно делать? Как узнает, где там "колбеки"? По фиксированным именам? Кто вообще сказал, что скрипт запрашивает колбеки? Может, они ему нафиг не нужны. А что "ничего "что-то" выполнять постоянно не требуется", я и пытаюсь вдолбить чуть ли не всю эту ветку - не придурошный цикл с анализом флага останова, у примитивный wait.

Artem, Господи, что вам всем так неймётся?..

Не знаю, "мода" эта как-то мимо нас прошла. Что за мода, бейсики писать? Ежу понятно, что язык, предназначенный именно для компа, исполняется заметно быстрее, чем "человеческий". По моим оценкам, там только один порядок.

Если "грамотность" проявляется в перлах типа "Это VM а не интерпретатор", то я предпочитаю быть малограмотным.    

nikolz, О, Господи! Говорил уже, что "знатоков развелось - прям плюнуть негде".

Открываем книжицу "Руководство пользователя" от ARQA - так там буквально в названии чёрным по белому: "ИНТЕРПРЕТАТОР языка Lua".

VM, да будет Вам известно, это ТОЖЕ интерпретатор! Только на другом языке интерпретируемые данные записаны.

Anton, Обыкновенная. Все скрипты есть просто куски текста, так что никаких потоков там нет и быть не может. Дойдут руки у интерпретатора - выполнит команду, нет - так и будут лежать голым текстом.

Да ничего я не придумывал"! Синонимы команд - обычный сервис: кому-то удобнее begin-end, кому-то {} - почему бы не дать такую возможность? А уж в именах объектов и их атрибутов синонимов и вообще может быть выше крыши (я имею в виду базы данных).

Владимир, Вот ещё парочка фрагментов из моей книги:

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

В своё время начальник буквально заставил нас написать «инструкцию пользователя» (у нас на неё никогда не хватало времени), фрагменты которой я и предлагаю вашему вниманию.
2. При генерации выходного файла могут быть открыты одновременно до трёх управляющих файлов разных типов:
• текущий конфигурационный файл;
• файл текущего шаблона;
• текущий входной файл данных.
3. Любой из управляющих файлов может содержать вложенные файлы, подключаемые командой #include FileName[#LabelName]. После обработки вложенного файла (или по команде #return) генератор возвращается к обработке родительского файла. Команда #jump FileName[#LabelName] осуществляет передачу управления между файлами одного типа, при этом возврат к обработке родительского файла не происходит. Переход внутри текущего файла выполняется по команде #goto LabelName.
7. Информация в конфигурационном файле предназначена для управления последовательностью генерации выходных файлов и определения глобальных переменных. Текущий выходной файл генерится на основании информации, содержащейся в файле текущего шаблона и текущем входном файле данных. Переключение входного потока данных между ними (режим сопрограмм) осуществляется при появлении во входном потоке символа-разделителя частей, определяемого командой EndOfPartSymbol. Генерация выходного файла заканчивается по окончанию первого файла шаблона, открытого при начале генерации (или файла, на который он был переключен директивой #jump). После окончания генерации выходного файла программа переходит к обработке очередной команды файла конфигурации. Работа программы завершается по окончанию файла конфигурации, открытого при старте программы (или файла, на который он был переключен директивой #jump).
II. Объявление и использование переменных
1. Переменные, как и команды, могут описываться в любом из трёх управляющих файлов. Область действия переменных по умолчанию устанавливается от момента её объявления до конца обработки файла, в котором она была определена.
2. Переопределение переменной (директива #replace), объявленной во внешнем файле по отношению к данному, автоматически упрятывает старое значение переменной и восстанавливает его по окончанию обработки файла, в котором она была переопределена (или по команде #pop VarName). Переопределение переменной, объявленной в том же файле, уничтожает её предыдущее значение, поэтому, в случае необходимости его сохранения, нужно воспользоваться командой #push VarName.
3. Любая переменная может содержать вложенные переменные, имена которых задаются непосредственно в теле родительской переменной и отмечаются с двух сторон символами-ограничителями VarSymbol.
5. Системные команды и переменные начинаются с символа «_». Переопределять системные команды и переменные не рекомендуется.
6. Значение переменной, если оно начинается с ограничителя, должно также оканчиваться ограничителем, что дает возможность описывать многострочные переменные. В противном случае, конец тела переменной определяется по символу конца строки или началу комментария. Разделитель частей файла может встречаться в теле переменной.
III. Массивы, указатели, функции, циклы
1. Массив однородных переменных объявляется по директиве #array. Элементы массива (значения переменных и/или их имена) задаются внутри ограничителей массива (скобки {} или #begin, #end) и отделяются друг от друга разделителями переменных (по умолчанию запятыми). Чтобы отличать имена переменных от их значений, имена должны ограничиваться с двух сторон символами-ограничителями переменных, задаваемых командой VarSymbol.
2. Указатель на массив (переменную) задается командой #pointer. С указателем могут выполняться арифметические операции, которые переводят указатель к заданному элементу (индексу) массива. Индексы нумеруются с нуля.
3. Описание функции задается командой #func  (FuncName ([Arguments]), вызов функции – командой #run FuncName ([Arguments]). Контроль количества и типов аргументов функции не производится. Ошибки такого рода выявляются на стадии исполнения и приводят к аварийному завершению работы генератора (InvalidData).
4. Программирование циклических операций выполняется по команде #for, при этом непосредственно после директивы #for описываются действия, выполняемые до цикла, после директивы #until – условие прекращения цикла (аналогичное по смыслу команде #if), после директивы #do идёт само тело цикла до команды #next. Допускаются вложенные циклы.


Или даже:
Примеры команд:
#if ((Тип == DOCUMENT) && ((Дата == NULL) || (Автор == NULL))) #then #inc.var (Total_Sum) – посчитать количество узлов типа DOCUMENT, у которых не указан либо автор, либо дата создания. Результат подсчёта сложить со значением ячейки Total_Sum, ранее определенной в шаблоне командой #var (но реально созданной в теле SINT-программы).
#run FuncName ([Arguments]) – вызов функции.
#include my_template – вызов вложенного шаблона по имени файла.
#call my_template#my_func – вызов функции, расположенной в теле внешнего шаблона.
#call #my_func – вызов функции, расположенной в теле текущего шаблона.
Последние три примера (отметим, что команды #call и #include являются синонимами) представляют собой аналог вызова процедуры в обычных языках программирования. Адрес возврата запоминается в стеке очередей, затем открывается (при необходимости) новый шаблон и (если указано имя вызываемой процедуры) файловый курсор переводится на начало этой процедуры. Определение адреса процедуры заключается в поиске её имени, которое представляет собой метку, заданную командой #label. Возврат из процедуры осуществляется по команде #return (или по достижению конца файла шаблона). По команде #goto или #jump выполняется такой же переход по метке, но не затрагивающий стек очередей.