1) В версии HMS 3.0 появился существенный недостаток для дополнений. В интерфейсе IHmsScriptEditor не вызывается функция SetRunning при смене режима отладки.
Например, при нажатии F8 или на кнопку "Выполнить скрипт".
Из-за этого редактор не всегда может осознать, что теперь включился режим отладки (или выключился).

Временным решением в дополнении HMSEditor_addon пока сделал так, что в событии смены каретки я делаю вызов GetCurrentState, где определяю режим.
Но это значит, что редактор переключит режим только после того, как что-то в редакторе будет нажато или сделано.
Однако, если просто во время отладки нажать кнопку проверки синтаксиса чтобы выйти из режима отладки - редактор будет отображать всё так, как-будто ничего не произошло, хотя на самом деле режим сменился.

2) Функции HmsStringToHex и HmsCryptFormatEncode("HEX", ... ) возвращают неверные данные, если код символа больше 127.
Например: HmsStringToHex( chr(200) ) должен возвращать "с8", вместо этого возвращает "45".
Все подкасты или скрипты использующие эти функции не будут работать или будут работать неправильно.

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

_________________
SONY KDL-32CX520

Переустановился до 3,0 и перестало iptv работать, при тестовом транскодировании выдаёт ошибку "не удаётся найти vlc.exe "


Уже и обновился до 3.01 и vlc переустановил и путь в программе к нему прописал

Настройка - Транскодер - Профили - Список транскодеров - VLC - Изменить - Путь - указать путь к vlc.exe

В версии 3.0 функция chr возвращает WideChar (2 байта), в предыдущих версиях возвращался AnsiChar (1 байт) и вопрос о работе функции в данном случае остается открытым.


На данный момент HmsStringToHex ожидает "правильно" преобразованную Ansi-строку в Wide-строку (преобразование использует страницу 1251),
которая проходила бы обратное преобразование (Wide - Ansi).
Функция AnsiChr, которая будет возращать "правильно" преобразованный символ будет добавлена, но в зависимости от реальной задачи, наверно надо использовать другое решение (без использования Chr, AnsiChr).

Стал переписывать скрипт набора текста с телека, наткнулся на новую проблему.
Команда HmsRegexMatch('(.)', 'Я', sVal) возвращает не тот символ (как я понимаю первый код широкого символа).
Причём HmsRegexMatch('(..)', 'ЯЯ', sVal) вернёт в sVal не два символа, как ожидается по регулярке, а одну букву 'Я'.
А это уже проблема. Версия HMS 3.01.

Несомненно, переход на поддержку отображения интернациональных символов - это хорошо.

P.S.: И ключевой символ \w в регулярках теперь не вылавливает русские буквы.

_________________
SONY KDL-32CX520

На данный момент, проблему решает добавление опции

const
  PCRE_UTF8 = $00000800;

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

Работает

[\p{L}|\p{N}|_]

но возможно можно проще

Я тут с ходу не смог придумать, как получить однобайтовую ANSI 1251 строку из Wide строки, например, если нужен запрос к стороннему сайту именно такой.
Т.е. вот есть Wide-строка на русском, как её можно перекодировать в обычную чтобы закодировать потом HmsHttpEncode?

В общем, хотелось бы, чтобы можно было пользоваться перекодировкой по типу HmsHtmlToText(text, 65001).

P.S.: А всё, нашёл то что нужно. Вместо HmsHttpEncode использовать HmsPercentEncode. Что интересно, дают очень разные результаты.
HmsPercentEncode('Привет') = %CF%F0%E8%E2%E5%F2
HmsHttpEncode('Привет') = %26%231055%3B%26%231088%3B%26%231080%3B%26%231074%3B%26%231077%3B%26%231090%3B

Хотелось бы знать, как эти функции будут работать в дальнейшем.

_________________
SONY KDL-32CX520

В HmsHttpEncode есть параметр по-умолчанию aAnsi: Boolean = False

HmsHttpEncode('Привет', True)=%CF%F0%E8%E2%E5%F2
HmsHttpEncode(HmsUtf8Encode('Привет'), True)=%D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82

Затрудняюсь ответить, возможно HmsHttpEncode с aAnsi=False будет автоматически преобразовывать строку в Utf-8 и кодировать, текущая реализация по-моему использует ASCII кодирование, возможно оно уже неактуально.