Clarion 11-12

[finsoftrz]

По юникоду разные решения уже есть.

И они решают ввод/вывод в экранных формах и на печать?! Чтение/запись юникода в файлы, в рамках своих потребностей, я уже давно делаю без проблем...

Можно достаточно несложно подцепить scintilla. Это сишная dll библиотека редактора, взаимодействие с которой осуществляется через виндовые события. Поддерживает работу с юникодом. Я пробовал отображать содержимое файлов в utf8. Есть режим readonly просто для отображения. Другие варианты это activeX контролы.

[finsoftrz]

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

У Михаила было решение для вывода на экран строк в юникоде, в том числе и в LIST. Можете его стимульнуть, если действительно надо.

[finsoftrz]

По юникоду разные решения уже есть

Скажите честно, у Вас много программ, где нужно в одном окне (списке) показывать текст в разных национальных кодировках ?
Я вот даже затрудняюсь ответить куда бы это можно было прикрутить (у нас есть пользователи в СНГ, Украине, ОАЭ ...)

А по 64 битам недавно озвучивался вариант вызова 64 битных утилит

Тот же вопрос. Я сталкивался с данными в INT64 только в [плохое слово] API OZON.
Где вообще всё сделано на INT64, даже флаги. Не потому что нужно, а потому что можем.
Ну сделали через GROUP и DECIMAL ... Или Вы про запуск бесконечных внешних EXE при работе программы ?

В юникоде потребности не возникало, как, думаю, у подавляющего большинства. Сталкивался только в егаис, где кто-то заводил название алкоголя в вебовском приложении, скорее всего, и вставлял в него специальные символы на юникоде, которые я при парсинге в vbscript убирал через регулярные выражения. Наверно, не очень понятно, но это долго рассказывать.

По 64 бит я имел ввиду запуск 64 битных скриптовых движков. Столкнулся с таким при работе с криптографией. В конкретном случае нашлась старая 32 битная библиотека, а в какой-то ситуации может и не найтись. Запуск внешних 64 битных утилит тоже может помочь в некоторых случаях, когда нет 32 битных аналогов.

[Игорь Столяров]

когда нет 32 битных аналогов

А вот тут нас ждёт большой разнобой всего ...
У пользователя обычная Windows 10 x64 / 11. Он может поставить разные версии x32 / x64 прикладной программы.
И началось. Библиотеки разные, драйвера разные, есть ли в светлом будующем ActivX / OLE (который Microsoft уже
давно "закрыла") - неизвестно ... .

Это если только полностью переводить проект на x64 ... А куда деть пользователей под Win7 (да и WinXP ещё тоже) ?

[finsoftrz]

Мы можем определить разрядность винды через win api, и использовать интерфейс с 64 битными скриптовыми движками по условию.

[Игорь Столяров]

Мы можем определить разрядность винды через win api

Конечно можем. Причём даже без WinAPI: SYSTEM{PROP:WindowsVersion,7}

Вопрос в другом. Под Windows x64 может работать приложение x64 и x32 (как оно собственно сейчас и работает).
И вот здесь нужно будет городить все расхождения в запуске скриптов, вызове библиотек, драйверов и т.д.

На меня уже с вторую неделю кладут с болтом, после просьбы устранить маленькую проблему в IngasoftPlus EasyOpenOffice.
Представляете, что будет при переходе на x64 DLL ? Я - не представлю.

[finsoftrz]

SYSTEM{PROP:WindowsVersion,7} это мелкие плюшки-обертки в рантайме с12. В с6 определяется через GetNativeSystemInfo из kernel32.dll.
По скриптам, проверям ос на 64, если да, то натравливаем 64 битный движек на свой скрипт, если нет, то пишем соответствующее сообщение. Если есть решение для win32, то не заморачиваемся, и используем win32 движек на 64 битной оси (если он конечно, он есть, а то Pyton, к примеру, не поддерживает обратную совместимость). Тут все просто, речь про некоторые специфические ситуации.

И 64 битного клариона не будет никогда. Полноценной поддержки юникода тоже. Об этом можно не беспокоиться.

[Игорь Столяров]

И 64 битного клариона не будет никогда. Полноценной поддержки юникода тоже. Об этом можно не беспокоиться.

После выхода C12 Вы уже лишены почётного звания предсказателя форума !

[finsoftrz]

Это сложно назвать выходом. Изменения, которые нельзя увидеть. Так можно было бы просто перекомпилить С11 и сказать, вот вам, с12 вышел. Хотя я доволен, не стало этой ядовитой красной иконки.

[Игорь Столяров]

перекомпилить С11 и сказать, вот вам, с12 вышел.

Ну собственно так и сделали ... но денег за работу не спросили, потому и жаловаться оснований нет.
Тупая пересборка C11.1 гарантирует, что новых ошибок не добавлено - и это уже хорошо. Ждёмс ...

[kreator]

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

У Михаила было решение для вывода на экран строк в юникоде, в том числе и в LIST. Можете его стимульнуть, если действительно надо.

Я к тому, что Юникод не помешал бы. Особенно в полноценном виде. Нужен был ещё лет 10 назад или 15.
По поводу 64-бит. У кого БД TPS, тому сильно проще. А с другими БД нужен 32-битный клиент, 32-битный драйвер ODBC. Как только вендор решит, что больше не надо собирать 32-битные версии, всё, нам конец.

[RaFaeL]

Как только вендор решит, что больше не надо собирать 32-битные версии, всё, нам конец.

Сидеть на старых версиях и всего делов

[Игорь Столяров]

Как только вендор решит, что больше не надо собирать 32-битные версии, всё, нам конец.

Но переход на x64 поставит много других вопросов. Где брать библиотеки ?
- LibCurl - есть;
- FreeImage - есть;
- LibXLSXWriter надеюсь, что удасться собрать - т.к. он открытый;
- ZInt - исходники есть, нужно пробовать ... но там такая ж..а со всем этим OpenSource ...
- Всё разработки т.к. называемых "3d Party Clarion" (кроме CapeSoft + Брюс) уже потеряли компетенции.

[kreator]

Как только вендор решит, что больше не надо собирать 32-битные версии, всё, нам конец.

Сидеть на старых версиях и всего делов

Часто не от разработчиков это зависит. Порой клиент сам решает какую ось поставить, какой сервер.

Как только вендор решит, что больше не надо собирать 32-битные версии, всё, нам конец.

Но переход на x64 поставит много других вопросов. Где брать библиотеки ?
- LibCurl - есть;
- FreeImage - есть;
- LibXLSXWriter надеюсь, что удасться собрать - т.к. он открытый;
- ZInt - исходники есть, нужно пробовать ... но там такая ж..а со всем этим OpenSource ...
- Всё разработки т.к. называемых "3d Party Clarion" (кроме CapeSoft + Брюс) уже потеряли компетенции.

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

[finsoftrz]

Все зависит от того, насколько важно приложение для клиента. Если действительно важно, то будут сидеть до упора, так как заменить на что-то это очень затратно. Люди до сих пор на коболе системы юзают и не жужжат.
Нам, по большому счету, 64 битные приложения не нужны. Вопрос про возможность без лишних переделелок собрать их так, чтобы они работали нативно, без wow64. Тогда зачем это нужно, если уже есть wow64? Его для этого и разрабатывали, чтобы людям не надо было переделывать кучу конкретных приложений.