forum.clarionlife.net

finsoftrz писал(а): 13 Сентябрь 2025, 20:17 и насколько на самом деле это востребовано

Интересно было бы посмотреть на реальное приложение с таким кандибобером.
Потому что если всё тоже прорисовывание по координатам сверху как кнопки - то это скорее концепт.

finsoftrz писал(а): 13 Сентябрь 2025, 20:17 А что там править, передавай как string.

Я тоже за одну переменную. Как в SQL. Есть varchar, у него есть свойство "кодировка", и всё. Единственное - проблема с длиной, типа программист сам должен помнить сколько символов влезет в строку. Либо объявлять с запасом.

finsoftrz писал(а): 13 Сентябрь 2025, 20:17 Еще, я не видел, чтобы поддерживали в одном приложении строки и в ansi и в юникоде. Либо все ansi, либо все юникод.

В принципе SQL допускает разные кодировки для разных полей (столбцов). Но вот это обрабатывать на клиенте... И смысла наверно нет, и трудоёмко.

finsoftrz писал(а): 13 Сентябрь 2025, 20:17 Кстати, в группах один товарищ допытовался, нужен ли на самом деле кому юникод и зачем. Может мысли у него есть какие.

А ему нужен? Откуда он? Понятно, что американцам вряд ли нужен. У них даже шпалы деревянные.

kreator писал(а): 14 Сентябрь 2025, 16:55 А ему нужен? Откуда он? Понятно, что американцам вряд ли нужен. У них даже шпалы деревянные.

По моему, американец. Тут все глубже. Юникод это стандарт для 64 битных систем. То есть общее направление это переход приложений на него, взамен кодовых страниц. Когда будут выпиливаться 32 разрядные приложения, будет выпиливаться и работа без юникода. Весь вопрос, сколько времени это займет, может очень долго. Большинство систем переползали на юникод где-то лет 10 назад. RZ вовремя начинал эту тему качать, судя по записи в блоге, занимались вопросом известные питерские товарищи.

Зная состояние SV (отсутствие постоянной команды разработчиков и малочисленная пользовательская база для продукта такого уровня), вероятность полноценной поддержки юникода и появления 64 битного компилятора крайне маловероятны. У нас вариантов то особых нет. Если досидеть до конца дееспособного возраста на 32 битном кларионе не вариант, то надо начинать потихоньку использовать какой-то другой инструмент параллельно. ХЗ, что. Для наших приложений ближе других виндев, там сейчас 25 версия, есть и поддержка юникода, и 64 бита. Хотя сама идеология разработки ближе к 1С, чем к клариону. Кстати, у них бесплатная 32 разрядная версия не совсем без ограничений. Я из любопытства иногда поглядываю, вываливало что-то про ограничение экспресс, видимо, не до конца там убрали.

finsoftrz писал(а): 14 Сентябрь 2025, 19:34 Юникод это стандарт для 64 битных систем.

Почему? В 32-битной Винде Юникод не поддерживается? Например, блокнотом. Обратное тоже верно - блокнот на 64-битной версии прекрасно читает не-Юникод текст. MS Office тем более.

Я имел ввиду, что 64 битное api работает нативно с юникодом, и MS рекомендует всем адаптировать свои приложения к юникоду.
Поддержка юникода в win32 это, судя по всему, рассматривается как переходный период. Так как очень много 32 разрядных приложений, которые юникод не используют. То есть тенденция есть, а сколько по времени займет выпиливание 32 разрядных приложений, одному богу известно. Пока поддерживается работа win32, маловероятно, что откажутся от поддержки национальных кодировок.

finsoftrz писал(а): 14 Сентябрь 2025, 22:24 64 битное api работает нативно с юникодом

Какое-такое api? Ну ладно, бог с ним. MS явно уже не будет ничего ужесточать. Другое дело сторонние библиотеки. Интересно, этот американец понимает, что 32-битных сборок скоро не будет и "наше" ПО встанет?

finsoftrz писал(а): 12 Сентябрь 2025, 19:21 Не понял, совсем отказались от использования zint? Я как бы тоже через него двумерные шк вывожу

Конечно нет ! Никто ни кто, и не от чего не отказывался.
1. Если Вы формируете картинки с кодами через запуск EXE - то вообще нет никаких изменений;
2. Если через класс ZINT - то там тоже сейчас поддерживается крайняя версия библиотеки ZINT 2.15.0.

Проблема в том, что мне удалось собрать рабочий ZINT.DLL только с зависимостью от vcruntime140.dll
Это накладывает некоторые особенности по его использованию ...

Можно и это обойти, но нужна информация, документация и поддержка со стороны авторов.
Но у меня на сентябрь уже исчерпан лимит сил по общению с недооценёнными гениями программирования.

Я работаю через zint.dll, только класс свой, по мотивам того, что Вы когда-то выкладывали.

Поля ввода строк с юникодом.

На всякий случай поясню по скриншоту. Это использована библиотека scintilla, написанная на С. Размер dll около 1мб. Она достаточно распространенная, в интернете много информации. Обычно используют в разных средах и языках программирования для создания встроенных редакторов кода. Никаких прототипов функций не требуется, взаимодействие через виндовые сообщения. То есть, у нас работа через сабклассинг. Для clarion есть опенсорсный класс обертка, который сделали англоязычные коллеги в начале нулевых, последнее дополнение было в 2015 году. Библиотека может работать с utf8. Возможностей много, можно много чего настроить (например, контекстное меню, горячие клавиши). В принципе, можно использовать как альтернативные строки ввода с поддержкой юникода. В окне добавляется region и напускается на него экземпляр класса. Кода немного, по сути, одна инициализация и присвоение/сохранение значений. То есть, простой контрол шаблон. Класс требует некоторой доводки, чтобы переназначить работу клавиш enter, tab и т.п. и получить поведение, как в обычных строках ввода.

Любопытно. А что ж все ноют-то, что юникода нет?

Дед Пахом писал(а): 16 Октябрь 2025, 12:18 Любопытно. А что ж все ноют-то, что юникода нет?

Потому, что это не родное. Для того, чтобы использовать все возможности Clarion, включая дизайнер, prop:, event: и т.п., надо "немного" довести. Аналогичное потребуется для List, String, Button, работы с файлами... Т.е., фактически, потребуется написать новый рантайм

Работа с юникод в пределах окна особо не критична, т.к. в 80% покрывается CHARSET, а вот заголовки окон, т.е. всё, где работает системный шрифт... Я, в своё время, написал шаблон, который заменял заголовки окон на имитацию контролами окна. Но новые/исправляемые глюки Clarion и обновления разных версий виндов с новыми/исправляемыми глюками API приводили к тому, что, как не вылизывай, смотрится криво и невозможно написать универсальный код.

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

Кстати, во многих других системах заголовки окон выглядят нестандартно. Видимо, тоже имитируют контролами. И на хабе периодически кто-то про такое пишет. Я не вникал в нюансы, так как мне такое не нужно. На первый взгляд, а какие там могут быть проблемы? Самое сложное реализовать перетаскивание окна, держа нажатым mouse left на какой-то области. И найти альтернативу таким вещам, как mdi tab.

Выглядит так, что почти все, что нужно для использования юникода, у нас уже есть. Даже вывод в LIST вроде через win api, не знаю, как Михаил это делает. Ещё прикрутить библиотеку для работы со строками в юникоде. Вроде в win api такая есть. Или на С в интернете поискать, или на clarion форк написать.

finsoftrz писал(а): 17 Октябрь 2025, 8:02 Самое сложное реализовать перетаскивание окна, держа нажатым mouse left на какой-то области

Какая то заготовка... тут делал вроде за окно в любой части легко таскалось.