Что бы это значило?

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

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

Владимир, чтобы помочь Вам в решении проблемы, то пришлите Ваш скрипт на котором возникает описанный эффект, а также архив рабочего места QUIK без ключей доступа. Прислать можно на адрес quiksupport@arqatech.com
 
Egor Zaytsev, Так он возникает раз в сто лет! На прошлой версии скрипта я вообще такого не видел, хотя код прорисовки таблицы, насколько  помню, не изменился ни в одной букве. Сегодня вот тоже скрипт работает на двух разных брокерах - и пока что всё тип-топ, хотя сделки уже были и там, и там. Более-менее заметное изменение кода состоит в том, что у меня теперь таблица "перебивается" чаще. Дело в том, что у меня раз в 15 секунд может измениться набор строк в таблице. Вначале я пытался удалять ненужные строки с помощью DeleteRow и вставлять новые с помощью InsertRow, но там возникали разные разные глюки, вроде пустых строк - я когда-то это описывал (кстати, этот эффект проявляется в таблице заявок в Квике даже при ручной торговле: после обрыва связи часть строк могут оказаться пустыми, и помогает только перезапуск Квика). Хотя не помню - возможно, даже он не помогает.

Затем я переделал скрипт без использования DeleteRow: новые строки вставлялись по InsertRow нормально, а при необходимости удаления ненужных строк я просто перебивал таблицу заново (Clear + InsertRow) - эта технология работала как часы.

Неприятность же состояла в том, что во входном файле тикеры у меня сгруппированы по классам и по алфавиту, а после вставки строк там получалась каша (новые строки ведь добавлялись в конец таблицы), поэтому я решил перебивать таблицу при любом изменении набора входящих в неё строк. Вот тут-то и начались подобные "эффекты". Поскольку код с очисткой и перебивкой таблицы остался также без изменений, единственное, что изменилось - это частота перебивки: она стала заметно выше и, следовательно, увеличилась вероятность столкнуться с транзакцией при прорисовке таблицы. Что именно здесь происходит - я не понимаю, но если в момент прорисовки отправляется транзакция, таблица обнуляется (не всегда, а очень редко). В момент перебивки таблицы отправка заявок невозможна (они в разных функциях), а вот при заполнении таблицы значениями (SetCell, SetColor) - возможно (и то, и другое происходит в одном и том же цикле по тикерам). Была бы ошибка устойчивой, я бы попробовал разнести эти процессы по разным циклам, но проявляется она РЕДКО.
 
Цитата
Владимир написал:
Egor Zaytsev, Так он возникает раз в сто лет! На прошлой версии скрипта я вообще такого не видел, хотя код прорисовки таблицы, насколько  помню, не изменился ни в одной букве. Сегодня вот тоже скрипт работает на двух разных брокерах - и пока что всё тип-топ, хотя сделки уже были и там, и там. Более-менее заметное изменение кода состоит в том, что у меня теперь таблица "перебивается" чаще. Дело в том, что у меня раз в 15 секунд может измениться набор строк в таблице. Вначале я пытался удалять ненужные строки с помощью DeleteRow и вставлять новые с помощью InsertRow, но там возникали разные разные глюки, вроде пустых строк - я когда-то это описывал (кстати, этот эффект проявляется в таблице заявок в Квике даже при ручной торговле: после обрыва связи часть строк могут оказаться пустыми, и помогает только перезапуск Квика). Хотя не помню - возможно, даже он не помогает.

Затем я переделал скрипт без использования DeleteRow: новые строки вставлялись по InsertRow нормально, а при необходимости удаления ненужных строк я просто перебивал таблицу заново (Clear + InsertRow) - эта технология работала как часы.

Неприятность же состояла в том, что во входном файле тикеры у меня сгруппированы по классам и по алфавиту, а после вставки строк там получалась каша (новые строки ведь добавлялись в конец таблицы), поэтому я решил перебивать таблицу при любом изменении набора входящих в неё строк. Вот тут-то и начались подобные "эффекты". Поскольку код с очисткой и перебивкой таблицы остался также без изменений, единственное, что изменилось - это частота перебивки: она стала заметно выше и, следовательно, увеличилась вероятность столкнуться с транзакцией при прорисовке таблицы. Что именно здесь происходит - я не понимаю, но если в момент прорисовки отправляется транзакция, таблица обнуляется (не всегда, а очень редко). В момент перебивки таблицы отправка заявок невозможна (они в разных функциях), а вот при заполнении таблицы значениями (SetCell, SetColor) - возможно (и то, и другое происходит в одном и том же цикле по тикерам). Была бы ошибка устойчивой, я бы попробовал разнести эти процессы по разным циклам, но проявляется она РЕДКО.
Без каких либо данных сложно дать ответ. Можно начать разбор именно со скрипта. Попробуем поймать эффект у себя, либо посмотрев на скрипт, что то сможем сказать.
 
Цитата
Владимир написал:
там у меня тоже ничего нет, кроме   SetCell, да SetColor
Работа с именно этмии функциями и может быть проблематичной. Чтобы убедиться, на чьей стороне ошибка, прямо перед вызовом этих функций проверьте, идентичный цвет фона и текста передаётся в них или различный. Можете также перенести весь код заполнения таблицы в ту часть, где он не может выполняться синхронно с другим кодом.
 
Egor Zaytsev, Да хотя бы гипотезу: ЧТО ИМЕННО В ПРИНЦИПЕ может происходить чтобы давать ТАКОЙ эффект? Ведь в SetColor и цвет фона, и цвет текста задаются обязательными аргументами!

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

Артем, Вот именно, что "работа с именно этми функциями и может быть проблематичной". Она уже приводила к потере управления при останове скрипта по OnStop (Антон когда-то здорово помог в локализации этой ошибки). И я абсолютно убеждён, "на чьей стороне ошибка" - НЕ МОЖЕТ мой код приводить к таким эффектам! НЕ МОЖЕТ!

Ха-ха-ха! Да я прямо перед вызовом ЗАДАЮ "идентичный цвет фона и текста"! Фрагмент кода прорисовки таблицы:
Код
k=0xFFFFFF;   -- по умолчанию строки чёрно-белые
l=0;   -- k - цвет фона, l - цвет текста
SetColor(T,a[i][10],-1,k,l,-1,-1);
k=W[a[i][1][3]+1];   -- цвет фона столбца кода тикера
l=L[a[i][1][1]+1];   -- цвет текста для разных валют
if a[i][1][8]==0 then k=0xFFFF;end;
if a[i][2]==0 then k=0x990000;l=0xFFFFFF;end;
SetColor(T,a[i][10],1,k,l,-1,-1);
SetCell(T,a[i][10],1,a[i][0]);-- заполняем данными строку таблицы
 
В программировании как в квантовой физике - всегда всё может быть. Попробуйте использовать измененный код. Он не должен выводить никаких сообщений при корректной работе. Попробуйте также подписаться на большое количество данных и высокую частоту обновления, чтобы максимально повысить вероятность появления ошибки.

Код
k=0xFFFFFF;   -- по умолчанию строки чёрно-белые
l=0;   -- k - цвет фона, l - цвет текста
SetColor(T,a[i][10],-1,k,l,-1,-1);
k=W[a[i][1][3]+1];   -- цвет фона столбца кода тикера
l=L[a[i][1][1]+1];   -- цвет текста для разных валют
if a[i][1][8]==0 then k=0xFFFF;end;
if a[i][2]==0 then k=0x990000;l=0xFFFFFF;end;

if k == l then message ( "Идентичный цвет фона и текста" ) end

SetColor(T,a[i][10],1,k,l,-1,-1);
SetCell(T,a[i][10],1,a[i][0]);-- заполняем данными строку таблицы
 
Артем, Сударь, я 40 лет программистом, причём, главным образом, системщик - уж мне ли не знать, что "в программировании может быть"? :smile:

О, Господи! Простите, но Ваш "изменённый код" - это детский сад. И я не собираюсь как-то извращаться, чтобы ловить всякие глюки В ЧУЖОМ софте! У меня просто в голове не укладывается: как можно изуродовать софт, чтобы он вытворял ТАКОЕ? Как можно изуродовать софт, чтобы на одно событие он выдавал кучу прерываний? Как можно изуродовать софт, чтобы он не успевал за юзером отслеживать его нажатия на клавиши? Как можно изуродовать софт, чтобы чуть ли не еженедельно выпускался очередной костыль по имени "версия 11.22.33.44"? Скрипт мой, слава Богу, пока что и так работает, даже с такой изуродованной таблицей. Боюсь, ненадолго... :sad:

Во, блин! Опять, сволочь, обнулилась! Подслушивает, что ли? :smile:  
 
ресурсы GDI
 
Детский-не детский, а дебаг проводить таки надо, а не просто пологаться на "да я 40 лет программирую, ошибок не допускаю принципиально" - как минимум чтобы претензии не голословно предъявлять. Да и вообще, как бы знать положено что репорты багов даются с минимально воспроизводимым кодом а не "у меня тут что-то не работает, свой показывать не буду, давайте чините".
 
Артем, Ну не таким же образом! Если я задаю "k=0xFFFFFF;l=0;" то что, я на следующем шаге должен проверять, что они разные? И так все 11 раз (именно столько у меня SetColor на вывод таблицы)? Да если ХОТЬ РАЗ они будут равны, язык НЕМЕДЛЕННО нужно отправлять на помойку!
 
Владимир, ну так там цвета и из других источников берутся, а не только указываются литерально.


Попробуйте составить отдельный самодостаточный код который воспроизводит ошибку. Попытайтесь уменьшить количество кода чтобы можно было понять, в каких именно ситуациях ошибка возникает. Тогда во-первых ошибку можно будет избежать, а во-вторых отдать в трекер для исправления.
 
Артем, Где "там"? В моём коде? НЕТ у меня никаких "других источников"!

Блин, да откуда мне знать "в каких именно ситуациях ошибка возникает"?! я и спрашиваю у техподдержки хотя бы гипотезу, как можно умудриться получить такое? Лично у меня просто фантазии не хватает!
 
Владимир, попробуйте создать таблицу заполненную нулями со случайно раскрашенными полями и высокой частотой обновления. Если проблема в QUIK то ошибка должна воспроизводиться и на синтетической таблице.
 
Артем, Блин, НА КОЙ мне этим онанизмом заниматься? Я ПОЛЬЗОВАТЕЛЬ этого софта, а не разработчик! И, как я говорил ещё в первом посте, поскольку у меня в разных местах используется разный цвет текста и фона, то хоть в одной ячейке должно быть хоть что-то видно! А раз нет, либо она ВНУТРИ своей функции вдруг устанавливает цвет текста равный цвету фона (а не наоборот, кстати) либо вообще не прорисовывает текст. Tertium non datur!
 
В английском языке есть такая идиома, "assuming makes an ass out of you and me". Индукционные заключения валидны только при полноте данных, а в этой ситуации отсутствует большое их количество. Мои предложения направлены на заполнение этого вакуума. Напоминаю, что баги легче фиксить если существует хороший репорт, так что "заниматься онанизмом" это в ваших интересах.
 
Артем, Вы, лично Вы способны предложить ХОТЬ ОНУ гипотезу такого поведения[Y/N]? КАКИЕ ИМЕННО "данные" Вы хотите получить и ЧЕМ ИМЕННО они Вам помогут?
 
Владимир, Мне - ничем, я пользуюсь только программным интерфейсом. Вам оно может помочь либо точно установить источник ошибкок который вы можете обогнуть в своем коде, либо создать точный багрепорт для разработчиков QUIK чтобы они могли его быстрее исправить. Под лежачий камень вода не течет.
 
Артем, Вы здесь недавно. Я, в общем, тоже, но я ещё несколько месяцев назад писал, что мне СТЫДНО писать компенсаторную заглушку на ситуацию, когда на одно событие приходит целая колода прерываний. Несколько месяцев преодолевал рвотные позывы, на днях написал. Ошибка эта не исправляется ГОДАМИ, несмотря на многократные указывания на неё разных юзеров. Более того: И НЕ СОБИРАЕТСЯ исправляться. Так что у меня на разработчиков надежды почти нет. С этим глюком мне тоже тошно разбираться: он неприличный, и может быть объяснён либо неряшливостью, либо низкой квалификацией - неизвестно, что хуже. Разве что какой-нибудь Антон снова подскажет какую-нибудь идею, как это было с потерей управления... Кстати, я пользуюсь чистейшим Lua, и более ничем, и я НЕ МОГУ "обогнуть в своём коде" ни SetColor, ни SetCell - это разработчики представили для работы с таблицами, и больше здесь ничего нет. А сторонними библиотеками я не пользуюсь, и пользоваться не собираюсь.
 
Цитата
Владимир написал:
А сторонними библиотеками я не пользуюсь, и пользоваться не собираюсь.
В данном случае видимо зря. Могу порекомендовать подцепить SDL2, в нем есть биндинги для OpenGL.
 
Артем, Нет, не зря. Необходимая функциональность для Квика ничтожна, и даже такой убогий язык, как Lua с его встроенными возможности, полностью позволяет реализовать эту функциональность. Собственно, я её уже реализовал. Если бы ещё не эти дурацкие глюки...
 
Разнёс я на всякий пожарный прорисовку таблицы и принятие решений по разным циклам. Теперь пока таблица полностью не прорисована, не может быть никаких никаких заявок, а когда идут заявки, не может быть никаких изменений в таблице. Вроде, работает. Хотя она и раньше "вроде, работала". :smile:  
 
Цитата
Владимир написал:
Egor Zaytsev, Да хотя бы гипотезу: ЧТО ИМЕННО В ПРИНЦИПЕ может происходить чтобы давать ТАКОЙ эффект? Ведь в SetColor и цвет фона, и цвет текста задаются обязательными аргументами!

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

Артем, Вот именно, что "работа с именно этми функциями и может быть проблематичной". Она уже приводила к потере управления при останове скрипта по OnStop (Антон когда-то здорово помог в локализации этой ошибки). И я абсолютно убеждён, "на чьей стороне ошибка" - НЕ МОЖЕТ мой код приводить к таким эффектам! НЕ МОЖЕТ!

Ха-ха-ха! Да я прямо перед вызовом ЗАДАЮ "идентичный цвет фона и текста"! Фрагмент кода прорисовки таблицы:
Код
  k =  0xFFFFFF ;    -- по умолчанию строки чёрно-белые 
l =  0 ;    -- k - цвет фона, l - цвет текста 
 SetColor (T,a[i][ 10 ], -  1 ,k,l, -  1 , -  1 );
k = W[a[i][ 1 ][ 3 ] +  1 ];    -- цвет фона столбца кода тикера 
l = L[a[i][ 1 ][ 1 ] +  1 ];    -- цвет текста для разных валют 
 if  a[i][ 1 ][ 8 ] =  =  0   then  k =  0xFFFF ; end ;
 if  a[i][ 2 ] =  =  0   then  k =  0x990000 ;l =  0xFFFFFF ; end ;
 SetColor (T,a[i][ 10 ], 1 ,k,l, -  1 , -  1 );
 SetCell (T,a[i][ 10 ], 1 ,a[i][ 0 ]); -- заполняем данными строку таблицы   
Добрый день.
Из гипотез, то согласимся с комментарием пользователя swerg, что дело в ресурсах GDI.
 
Egor Zaytsev, Нет, не могу согласиться: при чём здесь вообще GDI? Или, по крайней мере, какое мне дело до GDI? И почему раньше никаких проблем с "ресурсами GDI" не было? Графики у меня нет, и кроме двух таблиц, созданных с помощью AllocTable (одна эта, другая для контекстного меню) тоже ничего нет. Вчера я разнёс обращения к Квику на прорисовку таблицы и подачу транзакций ему же по разным циклам - пока всё работает. Но и вчера до определённого момента тоже всё работало, а потом раз пять таблица обнулялась, причём смена режима (Clear) не помогала (DestroyTable + AllocTable не пробовал).
 
Оба-на! Не помогло и разнесение по разным циклам - опять эта сволочь обнулилась... :sad:  
 
Блин, вынес создание таблицы из main в отдельную функцию, а в обработчик повесил на Enter DestroyTable+CreateWindow+SetWindowPos. Теперь снова ждать, пока эта скотина обнулится. Если уж И ЭТО не поможет...
 
Дождался! Убийство окна, таблицы и создание новой таблицы восстанавливает-таки нормальный текст в ячейках! Ура, товарищи! Как можно написать подобную "математику"...  
 
Сгенерировал большой объем табличных данных методом Перлина, никаких ошибок не заметил. Значения ячеек устанавливаются нормально, никакого шаманства не требуется. При вызове слишком высокого количества SetCell и т.п. в секунду, прорисовка таблицы начинает лагать, что в целом и ожидается - можно обновления засовывать в очередь и постепенно данные кормить в таблицу. На моей машине 40х40 ячеек с периодичностью обновления 100 мсек немного лагает но в целом справляется. Если периодичность увеличить до 10 мсек то таблица так лагает что даже сама не прорисовывается и надо кликать, но данные никуда не пропадают и ошибок не возникает.






У вас код так скажем "не без помарок" и "ошибка" совпадает с получением новых данных и соответственно отрисовкой таблицы, с учётом этого самый вероятный вариант это что просто у вас где-то в коде происходит потеря данных, вот они и из таблицы исчезают.
 
Артем, Меня не интересует, заметили Вы что-либо или не заметили. Эта ошибка СУЩЕСТВУЕТ (хотя проявляется довольно редко - менее 10 раз за всё время). Никакого "слишком высокого количества SetCell и т.п. в секунду" у меня нет - всего там порядка 10-20 тысяч ячеек, а на экране видны и вообще около тысячи Что там "начинает лагать" меня тоже не интересует - пропадают данные! Вернее, не пропадают, а становятся невидимыми - скрипт и после этого работает нормально. А скрин получающейся картинки я приводил. Обновление данных у меня раз в полторы секунды. В принципе, меня эта ошибка больше не интересует - научился лечить. Но для софта Квика это недопустимо.

В коде у меня НЕ МОЖЕТ происходить никакой "потери данных" - они находятся В ДРУГОЙ таблице и время от времени просто передаются в таблицу визуализации с помощью SetCell и SetColor. Реальная же торговля идёт именно по данным этой самой "другой таблицы", и она нормально работает даже при таких "весёлых картинках".
 
Цитата
Владимир написал:
ЧТО ИМЕННО В ПРИНЦИПЕ может происходить чтобы давать ТАКОЙ эффект?

Получить такой эффект можно таким вот нехитрым способом:
Код
SetColor(id, QTABLE_NO_INDEX, QTABLE_NO_INDEX, QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR, QTABLE_DEFAULT_COLOR)
или таким:
Код
SetColor(id, QTABLE_NO_INDEX, QTABLE_NO_INDEX, QTABLE_DEFAULT_COLOR, 0, 0, 0)

В результате текст во всех ячейках пропадает. Вернее окрашивается в цвет фона. Причём, после этого перекрашивание ячеек бесполезно - текст по-прежнему будет принимать цвет фона.
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Старатель, Про QTABLE_DEFAULT_COLOR первый раз слышу, но эффект именно такой: "текст во всех ячейках пропадает и перекрашивание ячеек бесполезно". Не помогает даже Clear - только DestroyTable+AllocTable! Остаётся выяснить, почему сия хрень возникает чрезвычайно редко - тем более, что никто никаких QTABLE_DEFAULT_COLOR ей не задавал. У меня лично мало сомнений, что эту QTABLE_DEFAULT_COLOR нужно придушить в зародыше!
 
Источник проблемы найден - не прошло и полгода, но потребовался сторонний эксперт т.к. ТС сам разбираться отказывается. Теперь можно с одной стороны передать багрепорт, а с другой стороны не вызывать функцию SetColor если первые три аргумента равны -1.
 
Могут быть различные комбинации:
Код
SetColor(id, QTABLE_NO_INDEX, QTABLE_NO_INDEX, 0xFFFFFF, 0, 0xFFFFFF, QTABLE_DEFAULT_COLOR)
Я не могу быть заинтересован в устранении ошибок в чужом ПО больше, чем его разработчик.
 
Артем, Источник проблемы НЕ найден, и ему явно не полгода, а гораздо больше. Меня этот глюк больше не интересует, и никаких "багрепортов" он не вызывает - система работает нормально, только таблица пустая, а первые три аргумента (точнее, третий, четвёртый и пятый) НИКОГДА не равны -1. Вот два последних равны ВСЕГДА - мне они нафиг не нужны, но без них эта хреновина "просто не работает".
 
Два последних можно делать такими же как два предыдущих, а не использовать QTABLE_DEFAULT_COLOR.
Код
SetColor ( tab, y, x, bgcol, txtcol, bgcol, txtcol )
Зато понятно почему мой генератор такой ошибки не встретил - там не использовалось ни QTABLE_NO_INDEX ни QTABLE_DEFAULT_COLOR, все значения были указаны явно.
 
Артем, Во-первых, это я сделал по рекомендации сотрудников арки, и до сегодняшнего дня даже не подозревал, что QTABLE_DEFAULT_COLOR тоже равна -1 и даже о том, что она вообще существует. И с какой радости я должен "два последних делать такими же как два предыдущих", если меня вообще не интересует, что там? Ещё в октябре я писал:

Некоторые функции допускают необязательные аргументы (например, основание системы счисления в tonumber), а другие - нет. Так,
SetColor (iTable, iRow, iCol, BCol, TCol)
НЕ работает, а если подставить туда два дополнительных аргумента , SelBCol, SelTCol, равные QTABLE_NO_INDEX (-1) - начинает работать! Поскольку мне совершенно не были нужны выделенные ячейки, до необходимости переделать вызов в
SetColor (iTable, iRow, iCol, BCol, TCol, SelBCol, SelTCol, -1, -1)
без подсказки от службы техподдержки я бы просто не додумался НИКОГДА!
 
Опять писатели инструкций говна в дупу залили, ну что-ж такое-то, сколько можно?!
 
Артем, Так не пишите, сударь, не корчите из себя профи, не идёт Вам это - у Вас же всё написано НА ЛБУ! :wink:  
 
Глюк, описанный в топике, иногда проявляется (сегодня вот был), но теперь он легко лечится, и меня более не интересует. Но вот только что проявилась совсем интересная штуковина, с которой мне пока что не доводилось сталкиваться: заявка "успешно регистрируется", и в ту же секунду снимается, причём молча, без уведомления "заявка снята", в таблице заявок статус "снята", торги идут (я для контроля попробовал продать через скрипт другой тикер - всё прекрасно), но на этот (OII_SPB, Oceaneering International, Inc.) сегодня "что-то нашло": пять раз пытался продать, и все пять раз "очень удачно", с вышеописанным результатом. Кстати, 7 часов назад скрипт уже продавал именно эти акции, и вполне успешно (как и всегда ранее). И чо это за хрень?  :shock:  
 
Владимир, может брокер приостановил торги по инструменту?
 
Так должно быть уведомление, а его нет! Обычно бывает "инструмент не торгуется" или "обнаружена активная блокировка". Кстати, после моих пяти попыток сам скрипт попытался продать те же акции с тем же успехом, а ещё через час всё же продал.
 
Владимир, добрый день!

Цитата
Владимир написал:
заявка "успешно регистрируется", и в ту же секунду снимается, причём молча, без уведомления "заявка снята", в таблице заявок статус "снята"
Наиболее вероятно, что выставляете лимитированную заявку с условием "Немедленно или отклонить".
В случае отсутствия встречного предложения, такая заявка переходит в статус "Снята" сразу же после выставления.
Рекомендуем проверить эту ситуацию.

В случае, если разобраться самостоятельно не удастся, при повторении проблемы просим прислать снимки экрана с окном ввода заявки (или параметрами поданной из скрипта транзакции) и таблицей котировок на момент выставления заявки.
 
Roman Azarov, Я пытался продавать через свой скрипт (там у меня какая-то пародия на диалог написана), а там все заявки лимитированные, все подаются единообразно и даже одним и тем же куском кода. Что до условия "Немедленно или отклонить", я так понимаю, что это задаётся перед отправкой sendTransaction, причём это EXECUTION_CONDITION =  «FILL_OR_KILL». Я считал, что это необязательный параметр и ничего не заполнял. Может быть, следует явно прописать в коде EXECUTION_CONDITION =  «PUT_IN_QUEUE»?
 
Владимир,

EXECUTION_CONDITION по умолчанию имеет значение "PUT_IN_QUEUE" ("Поставить в очередь").

Цитата
Владимир написал:
все подаются единообразно и даже одним и тем же куском кода
Пришлите, пожалуйста, данный фрагмент кода.
 
Roman Azarov, Да без проблем!
Код
A.ACTION="NEW_ORDER";      -- вид заявки
A.OPERATION=l;         -- покупка (BUY) или продажа (SELL)
A.CLASSCODE=a[n][1][0];      -- код класса инструмента
A.SECCODE=a[n][0];      -- код инструмента
A.TYPE="L";         -- заявки всегда лимитированные
TC=TC+1;         -- идентификатор транзакции
A.TRANS_ID=tostring(TC);   -- возможно, будет использоваться для поиска
A.CLIENT_CODE=CC;      -- код клиента
if l=="B" then          -- заявка на покупку
 if j<=k*1.001 then k=j;end;   -- покупаем по цене предложения для скорости
end;            -- конец условия "заявка на покупку"
if l=="S" then          -- заявка на продажу
 if i>=k*0.999 then k=i;end;   -- продаём по цене спроса для скорости
end;            -- конец условия "заявка на продажу"
A.PRICE=d(k);         -- цена покупки/продажи
A.QUANTITY=d(i);      -- количество лотов
A.ACCOUNT=AC;         -- торговый счёт
j=sendTransaction(A);      -- посылаем заявку
if j~="" then...
Снятие ещё проще:
Код
TC=TC+1;         -- заявка активна, будем снимать
A.TRANS_ID=tostring(TC);   -- идентификатор транзакции
A.ACTION="KILL_ORDER";      -- на снятие заявки
A.ORDER_KEY=tostring(s.order_num);
l=sendTransaction(A);      -- посылаем заявку
if l~="" then...
 
Владимир,

С данными параметрами действительно должна подаваться лимитированная заявка с условием "Поставить в очередь".
В случае повторения проблемы, пришлите, пожалуйста подробный пример (снимок экрана с таблицей сообщений, снимок экрана с таблицей заявок и стаканом котировок на момент выставления).
 
Roman Azarov, Ok, только это явно очень редкая штука - я такое увидел впервые.
Страницы: 1
Читают тему (гостей: 1)
Наверх