forum.clarionlife.net

Там есть разработчики? Вы неисправимый оптимист.

Кто-то же вот это всё собирает ...

А вообще почти целый день продолбился с разбором версий распростроняемых компонент Visual Studio.
Полный бардак. Видимо нужно встраивать в установщик прикладной программы накат текущего релиза компонент VC.

Продолжаем нашу рубрику "Найди отличие C12 от C11".
В окне настройки колонок LIST секция DATA теперь находится сразу за секцией HEADER - что намного удобней !

У меня без изменений. Я уже писал про то, что, видимо, они в с11 оставили отдельную ветку для всех предыдущих версий рантайма. Хз, почему. В частности, в с11 они изменили окна с пропертями шаблонов, сделав их шире.

finsoftrz писал(а): 28 Май 2025, 10:53У меня без изменений.

Что-то мне вот это всё начинает напоминать историю с рассёром Apache / Libre OpenOffice.
Т.е. когда существовало несколько самостийных сборок по сути одного и того же ...
На ClaHUB спонсоры Clarion DevCon жалуются, что их игнорят с AnyScreen и ожиданиями от Unicode ...

Известный в узких кругах адвокат SV Брюс Джонсон вещает, подождите немного, нам пока неизвестно, как включить юникод в с12, но его точно как-то должно быть можно включить.

finsoftrz писал(а): 28 Май 2025, 11:40 нам пока неизвестно, как включить юникод в с12

finsoftrz писал(а): 28 Май 2025, 11:40 нам пока неизвестно, как включить юникод

т.е. до этого они откровенно вешали лапшу?

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

finsoftrz писал(а): 28 Май 2025, 12:09 Я так понял, что поддержка юникода в с12 реализована. Но никто этого не видит, Брюс думает, должен быть какой-то переключатель, чтобы все начало работать, и из SV придет информация, где этот переключатель находится.

Он есть, но никто его не видит. Привидение?

Или он такой или он нас за таких... Рантайм не менялся миллион лет

Выключатель есть, но SV забыли где он?

finsoftrz писал(а): 28 Май 2025, 12:09 Брюс думает, должен быть какой-то переключатель

Брюс пытается вести просветительскую работу среди ожидальщиков поддержки Unicode ...
Показать в одном окне надписи на турецком и русском - не сложно. Но ведь это нужно где-то хранить.

Т.е. т.н. тип данных USTRING должен хранить от 1 до 4 Byte на символ (UTF-8).
И это тоже можно реализовать (и давно реализовано в том же WinAPI) ... но главный вопрос - это совместимость с ANSI.
Потому что сейчас же выползут переходильщики с C5 со своим Legacy и "а вот мне это не надо".

Например реализовали драйвер SQLite. Если я хочу в нём хранить строку с наименованием товара в 100 символов,
то должен объявить строку в 400 Byte ... но дело в том, что в SQLite нет такого типа данных. Есть TEXT без указания размера.
Если сделать USTRING безразмерным типом данных - то кроме прямой адресации STR[01] будут проблемы с индексами и т.д.
Хотя - это наиболее понятный путь. А STRING(XY) остаётся таким какой он есть.

Игорь Столяров писал(а): 28 Май 2025, 13:30 Например реализовали драйвер SQLite. Е

В драйверы достаточно включить поддержку юникоде в виде отдельных типов, как предлагали с самого начала. А в рантайме сделать функции для обычного String и для типов c юникоде. И всё, никаких особых сложностей.

Губин Игорь писал(а): 28 Май 2025, 13:39 В драйверы достаточно включить поддержку юникоде в виде отдельных типов. А в рантайме сделать функции для обычного String и для типов c юникоде

Да - это простой путь. В этом случае драйвер сам должен "умножать на 4" длину хранения под UTF-8.
Но проблема в том, что теряется совместимость с существующими приложениями в ANSI.

Более вероятен путь ДОБАВЛЕНИЯ специальных типов данных. Тогда драйвер будет поддерживать и
обычный ANSI STRING и Unicode USTRING. Ну и функции работы с USTRING, которые, кстати, можно прикрутить
сбоку RUNTIME, как сейчас прикручены функции работы с INT64 ...

Игорь Столяров писал(а): 28 Май 2025, 13:57 Более вероятен путь ДОБАВЛЕНИЯ специальных типов данных.

Так я это и предлагаю! Ввести новый тип строки с содержимым юникод.

Все функции для работы со строками придётся дописать в варианте для юникод, благо позволяет язык.

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

Давайте честно скажем, поддержка юникода и 64 бит в кларионе потребует значительного переписывания существующих приложений. С учётом того, что SV не имеет ресурсов, а пишущим на кларионе нужна в основном поддержка работающих приложений, все это выглядит безнадёжно. Если действительно нужен юникода и 64 бита, то проще перейти на инструменты, где это уже есть в готовом виде. И, я думаю, количество пишущих на кларионе, кому все это нужно, исчезающе мало.