s_mike@rambler.ru (Все сообщения пользователя)

A={nil,1,2}
unpack(A). Даст непредсказуемый вариант зависимости от порядка заполнения полей

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

остальные способы - это возня и рыдания.

да, можно  

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

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

при помощи внешней библиотеки на с++ возможность есть  

завтра )

*

Звёздочкой форум заменил название известного  * .

Знают, пользуют )

Можно было бы перебрать возможные параметры через createdatasource и откинуть те, на которые получен отказа подписке .

но!

Createdatasource подобна верблюду (что у него прямое?) и всегда возвращает успешную подписку, хоть на существующую бумагу, хоть на ролики с  *

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

Уважаемые разработчики.

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

Ошибки будем исправлять или наплевать на них и вообще пропади он пропадом, этот квик?

io.type (obj)

Проверяет, является ли obj валидным хендлером файла. Возвращает строку "file" если obj –
открытый хендлер файла, "closed file" если obj закрытый хендлер файла, или nil
если obj не является хендлером файла.

ответ к делу не пришьешь.

я вам писал о неправильном ответе createdatasource уже лет 5 назад и вы регистрировали, рассматривали, обсуждали, митинговали, постановили и дали торжественные обещания. Результат известен.

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

сейчас, когда терминал не может внятно сказать, удачно ли он подписался на котировку, нет возможности отследить, почему нет котировок. Или нет свечей в принципе, или они ещё не получены, или подписка не прошла.

а разве нумерация свечей останется неизменной? Старые свечи разве не могут обрезаться?

стандартными средствами - нет

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

Нет, нельзя.

самый правильный путь - это рассчитывать индикаторы прямо в скрипте. Тем более что это несложно

Возьмите новую, например здесь

require "bot4sale64"

success_code,error_string = bot4sale64.PlaySound(sound_file)

Странно, что терминал выдает успех на cresteddatasource, если реальная подписка не осуществлена.

и вдвойне странно, что если на oncleanup подписаться не смогли, то почему то и на onconnected тоже не удается..

Спасибо.

то есть в моем варианте все манипуляции на сигнал oncleanup просто не нужны и oncleanup всегда предваряет onconnected?

Lua 5.3

Оно?

Сам код привести довольно трудно. он весьма объёмный

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

Подписка на событие  oncleanup выглядит элементарно:

oncleanup.subscribe(function()
unsubscribe()
subscribe()
 end)

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

все те же действия происходят и по onconnected ровно тем же механизмом

onconnected.subscribe(function()
unsubscribe()
subscribe()
 end)

И с onconnected проблемы не возникают.

проверки возвращаемого значения createdatasource есть.

о. Арка наняла новеньких, они ещё въезжают.. ))

Евгений. Смысл поста вы том, что путем изменения настроек индикатора можно нарушать вид шкал и легенду диаграмм. Что является наглядным примером качества продукта.  Да ещё как выясняется и сотрудникинсотрудники в состоянии осознать написанное.

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

Подписка на инструмент сразу после смены сессии ошибок не возвращает, но и "мёд не носит" - свечи не приходят, колбек не дергается.

Как нужно делать правильно?

Спасибо.

Я вот совсем не копенгаген, где кого три и кто там самый толстый,

но если в пользовательском индикаторе сделать тип линии гистограмма и ширину линии 100, то на экране появится воскресший Сальвадор Дали.

Тайное знание находится в настройках индикатора:  ширина линии    

Строим индикатор с гистограммами (первый рисунок)

Увеличиваем ширину гистограмм - второй рисунок


Враги  съели легенду. Если сделать ширину еще больше - они сожрут и таймлайн (третий рисунок)

А что проверять то? Пример по ссылке в 5.1 работает (результат даже приведен) , а в 5.3 нет. Вот и вся проверка.


ВУИГП = DEBUG

Не совсем так, город белых штанов тут не при чем.

os_time берет секунды и первым делом отсчитывает от них часовой пояс. Если взять 0, то при часовом поясе европа получается 1969 год и луа огорчается.

касаемо 5.1.   Не замечалось. Быстрее всего там была возможность работать с отрицательным юникстиме без преобразования os.date. в 5.3 решили навести порядок и при пересборке своих скриптов в режиме ВУИГП (проверках всего и вся) я и увидел эту шляпу.

Проверять что было в 5.1 лень.

Перекомпилировал свои скрипты, наткнулся:

Открываем https://www.lua.org/pil/22.1.html,  Видим пример

print(os.time{year=1970, month=1, day=1, hour=0})      --> 10800

Не верим, проверяем.

print(os.time{year=1970, month=1, day=1, hour=0})
Console:1: time result cannot be represented in this installation

И правильно не верим, как выясняется. И в терминале и в стандалоне одинаково.

а вот

print(os.time{year=1970, month=1, day=1, hour=0})


Оказывается.

Теперь lua смотрит часовой пояс. У меня часовой пояс +1, и
print(os.time{year=1970, month=1, day=1, hour=1}) работает и дает 0

Смотрел в документацию на луа - ничего не нашел. На 5.1 в часовой пояс луа не смотрела.

А напишите мне почтой, что вам требуется. Возможно я вам что то готовое порекомендую.

А зачем писать этот индикатор?

Вы можете вывести эти данные на график стандартным способом, просто в терминале

Используйте luac.exe для проверки синтаксиса перед запуском скрипта.  

Александр, давайте посмеемся вместе ..

поищите текстовым редактором в вашем тексте


CLAS_SCODE

И правда, чё там.  Надо автомобиль сбацать- базару нет! Берем четыре колеса, четыре стула, эта, таво....  а! две калитки, одну мою, вторую соседскую - и пару бутылок беленькой. И забацаем до вечера. Чё мы, хуже мерина с поршом? И стоить будет 1000 рублей, из них половина - бухло.

Чушь.

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

Александр, я вам гарантирую ,проблема что проблема в отсутствующем коде класса в транзакции.

наведите резкость, посмотрите, как вы передаёте код класса в транзакцию.

проверьте код класса в транзакции

Тогда заодно исправьте и индикаторы.Если задать в тексте на луа

Settings = {   ['PARAM'] = 5,
   line = чегототам
}

то при старте индикатора setting.Param содержит (int) 5, а после изменения его пользователем уже (float) 5.0

О чем и речь....

текcтовое представление не рассматриваем вообще


Сергей, я правильно понял, что

при записи в столбец qtable_int64_type переданное значение 123.45 всегда будет преобразовано в int64 (123) и именно в таком виде запомнено где-то в кишках терминала?

По getcell я получу уже именно как lua integer (123) ? Или я получу его как float (lua number) с обрезанной дробной частью (123.0)? или все же я получу исходный lua number 123.45?

Не используйте unpack, если индикатор может иметь значение Ия nil в любой линии.

по факту оказывается, что в в колонки int и int64 можно писать и int и  int64. Значения показываются, никаких округлений не происходит.

читать как

по факту оказывается, что в в колонки int и int64 можно писать и integer и  double. Значения показываются, никаких округлений не происходит.

Сергей, я не знаю, как более понятно объяснить.

давайте попробую так:

есть тип колонки qtable-string-type.  В него можно записать значение типа string

есть qtable_double_type для плавающих чисел

есть qtable_int_type. Логично предположить, что в эта колонку можно записать только integer

по факту оказывается, что в в колонки int и int64 можно писать и int и  int64. Значения показываются, никаких округлений не происходит.

какая в таком случае разница между qtable_int qtable_int64 и wtable_double?  Никакой.

отсутствие разницы было как то объяснимо на луа 5.1. сейчас же на луа 5.3 после введения integer типа  ожидаешь соответствия, но по прежнему все валится в одну кучу


более подробно не могу.  Если опять непонятно - надо уже просить помощь зала.

Дорогая редакция!

Создайте пользовательскую таблицу на языке qlua, одну колонку сделайте типом QTABLE_INT64_TYPE и выведите в нее число 1.2345

Я слышал, что 1.2345 никак не есть int64. Возможно меня обманули....

Я правильно понимаю, что колонки пользовательских таблиц этих типов по прежнему уверенным домкратом выводят float циферки? )