Galkov, и чем же я тебе не угодил?

Я хотел только уточнить: английский, но с русским системным языком? То есть, можешь называть файлы по русски? Потому что есть разница, просто есть поддержка русского языка, или он является языком системы по-умолчанию.

1) Не испытываю потребности в угождении, или нет - давно вышел из детского возраста.
2) tsdima автор адаптации VBJScript под FPC
3) Скриншоты не дают никакой информации. Мы тоже можем тебя завалить по мылу таковыми, отгадай - станет ли легче ?

Я системный администратор в корпорации G..l, у нас возникли проблемы по использованию Quota Server на доменных контроллерах. Я написал скрипт на VBScript для квотирования диского пространства на сетевых ресурсах пользователей, но так вышло, что им могу пользоваться только я, поэтому руководиль группы попросил меня сделать хоть какой-то интерфейс для скрипта, то есть превратить его в программу. Так как я не имею права ставить на компьютер нелицензионное ПО, то выбрал HiAsm как быстрое, бесплатное средство для разработки.

В корпорации используется ТОЛЬКО английский Windows XP, 2003 и т.п. На рабочии станции ставим MultulanguageUserInterface, что я и имею на своей рабочей станции. И менюшки и файлы на русском поддерживаются, только я использую английский интерфейс Windows. А вот на виртуальной машине, на которой я могу поставить все что угодно, я установил русский интерфейс, там же HiAsm стоит.

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

Итог:
1. Windows XP SP2 Eng + Russian MUI + French MUI
2. HiAsm 3.62 (160)
3. Компилятор FPC (Делфи нет)

[size=-2]------ Добавлено в 12:42
Galkov, Тебе сколько лет? Ты откуда?

Под FPC действительно есть проблемы с русскими. И скорее всего это КОЛ-овская функция OleStrToStrVar. Размер правильно определяется, а вот сама конвертация - почему-то с ошибкой.

Так чего делать? Скачал вот это вдобавок ко всему http://www.hiasm.narod.ru/Compiler.exe.

Проверил:
compilers.txt
[Delphi]
path=%curdir%compiler\dcc32.exe
cmd="%fname%" "-U%opath%." -Q "-E%opath%
ext=dpr

projects.txt
[Delphi]
Name=Delphi & FPC
Info=Проекты для Windows на базе компиляторов Delphi и FPC
Make=delphi
Units=pas
[Other]
Name=Файлы
Info=Простые форматы файлов
Units=

Ну и как узнать какой компилятор используется?

[size=-2]------ Добавлено в 13:19
Command line: fpc.exe '"C:\Program Files\HiAsm\Elements\Delphi\code\_QuotaEditor.pas"' -Sd -Mdelphi '"-FEC:\Docu... тра-та-та

[size=-2]------ Добавлено в 13:20
FPC используется все-равно

Vitaliy, есть кнопочка "Скомпилировать проект", у этой кнопки есть выбор, какой компилятор из установленных использовать

Уря! Запустил компилятор delphi - оказалось пакет с компилятором распаковался не туда :-( - и ведь не предлагал даже куда распаковаться - ну в общем спменил пути в настройках и заработало :-)

Русский язык теперь правится в базе данных

[size=-2]------ Добавлено в 13:30
Леонид, да не так все просто, не просто выбрать надо, а до этого еще активизировать в Tools -> Compilers

Но все-равно спасибо за содействие

[size=-2]------ Добавлено в 13:38
И светодиод больше не ругается... А чье это детище FPC?

Товарищь Florian Klaempfl накрапал.

Я тут посмотрел туды-сюды, виновата системная StringToWideChar, таким образом в скрипт строки попадают уже с пробелами. Комментарии тоже выглядят прикольно - одни пробелы Отказаться от этой функции будет непросто ...

З.Ы. Кроме того, она вроде неявно используется если переменной типа WideString присвоить String ...

А я думал, что это ты ее накрапал
Для Delphi она вроде определена в System.dcu
А для FPC - в KOLComObj.pas

[size=-2]------ Добавлено в 14:17
и еще думаю, что некое "автоматическое" определение кодовой страницы никогда не будет нормально работать везде

Надо ее определять "жестко" по кодовой странице среды в момент компиляции... Но никак не в момент исполнения...

Может и я. Были вроде, проблемы, с какой-то строковой функцией.

[size=-2]------ Добавлено в 14:59
Когда системная CodePage английская, то тут уж ничего не поделаешь. Буквы с кодами $80-$FF не могут быть отображены в Unicode, а FPC видимо использует вместо вопросика пробел. Вобщем, пора переходить на Unicode
Но в Дельфи это-ж как-то работает

А мне кажется, основное отличие при переходе на Unocode как раз том и будет заключаться: кодовая страница будет "жестко" определяться на этапе компиляции.
И кажется - не более того....

И это что, суперсложная задача

Galkov, переход на Unicode достаточно сложная задача. Вместо CreateWindowA нужно будет использовать CreateWindowW, вместо SendMessageA - SendMessageW, ну и так по всем функциям, в имени которых есть последняя большая буква A. Естесственно, учитывать, что строковые параметры типа PWideChar, а не PAnsiChar. На данный момент, KOL не предназначен для такого перехода.

А я про что

Мне представляется что проще отследить сегодняшнее использование нами фигни типа StringToWideChar, и перекрыть их при необходимости своими.

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