lazarus символ по коду
UTF8 strings and characters/ru
Contents
Красота UTF-8
Байты, начинающиеся с ‘0’ (0xxxxxxx), зарезервированы для ASCII-совместимых однобайтовых символов. В многобайтовых кодовых точках число 1 в старшем байте определяет количество байтов, которое занимает кодовая точка. Наподобие этого:
Конструкция UTF-8 имеет некоторые преимущества по сравнению с другими кодировками:
Примеры
Простой перебор символов, как если бы строка представляла собой массив элементов одинакового размера, не работает с Юникодом. Это не что-то конкретное для UTF-8, стандарт Unicode сложен, а слово «символ» неоднозначно. Если вы хотите перебрать все кодовые точки строки UTF-8, есть два основных способа:
Поиск подстроки
Из-за особой природы UTF8 вы можете просто использовать обычные строковые функции для поиска в подстроке. Поиск правильной строки UTF-8 с помощью Pos всегда будет возвращать правильную позицию байта UTF-8:
Поиск и копирование
Еще один пример того, как Pos(), Copy() и Length() работают с UTF-8. Эта функция не имеет кода для работы с кодировкой UTF-8, но она всегда работает с любым действительным текстом UTF-8.
Перебор строки в поисках символов ASCII
Если вы хотите найти только символы в ASCII-области, вы можете использовать тип Char и сравнивать с Txt[i], как в старые времена. Большинство парсеров делают это, и они продолжают работать.
Итерация по строке в поисках символов Юникода или текста
Если вы хотите найти все вхождения определенного символа или подстроки в строку, вы можете повторно вызывать PosEx().
Если вы хотите проверить другой текст внутри цикла, вы все равно можете использовать быстрые функции Copy() и Length(). Можно использовать специальные функции UTF-8, но они не нужны.
Цикл можно оптимизировать, перескакивая через уже обработанные части.
Перебор строки с анализом отдельных кодовых точек
Этот код копирует каждую кодовую точку в переменную типа String, которая затем может быть обработана далее.
Доступ к байтам внутри одной кодовой точки UTF8
Кодовые точки в кодировке UTF-8 могут различаться по длине, поэтому лучшим решением для доступа к ним является использование итерации. Для перебора кодовых точек используйте этот код:
Доступ к N-й кодовой точке UTF8
Помимо итерации можно также иметь произвольный доступ к кодовым точкам UTF-8.
Отображение кодовых точек с UTF8CharacterToUnicode
Ниже показано, как отобразить 32-битное значение кодовой точки каждой кодовой точки в строке UTF8:
Составные символы
Из-за неоднозначности Unicode функции сравнения и Pos() могут показывать неожиданное поведение, например, когда одна строка содержит составные символы, а другая использует прямые коды для той же буквы. RTL автоматически это не обрабатывает. Это характерно не для какой-либо кодировки, а для Unicode в целом.
macOS
Файловые функции модуля FileUtil также заботятся о специфическом поведении macOS: macOS нормализует имена файлов. Например, имя файла ‘ä.txt’ может быть закодировано в Unicode двумя различными последовательностями (#$C3#$A4 и ‘a’#$CC#$88). Под Linux и BSD вы можете создать имя файла с обеими кодировками. macOS автоматически преобразует умляут в трехбайтовую последовательность. Это означает:
LCL Unicode Support/ru
Contents
Введение
Начиная с 0.9.25 Lazarus полностью поддерживает юникод (Unicode) на всех платформах, исключая Gtk 1. На этой странице размещены инструкции для пользователей Lazarus, планы на будущее, описаны основные концепции и детали реализации.
Инструкции для пользователей
Хотя в Lazarus есть юникодные наборы виджетов, важно отметить, что не всё в юникоде. Кодировка строк и правильное преобразование между библиотеками, ожидающими разные кодировки, является ответственностью разработчика.
Обычно библиотекой используется единая кодировка строк (речь о динамической библиотеке DLL или пакете Lazarus). Каждая библиотека обычно ожидает одну кодировку, которой может быть юникод (UTF-8 для Lazarus) или ANSI (что означает системную кодировку, которая может быть UTF-8 или другой). RTL и FCL в FPC версий 2.4-2.6 ожидают строки ANSI.
Преобразование между юникодом и ANSI возможно при помощи функций UTF8ToAnsi и AnsiToUTF8 модуля System или UTF8ToSys и SysToUTF8 модуля FileUtil (Lazarus). Последние две мощнее (быстрее), но добавят к программе больше кода.
FPC не юникодный
Библиотеки Free Pascal времени исполнения (RTL) и свободных компонентов (FCL) в текущих версиях FPC (по 2.6.1) используют ANSI, поэтому требуется преобразование строк, получаемых из юникодных или переделываемых в юникодные библиотек (например, LCL).
Преобразование между ANSI и юникодом
Допустим, нужно передать в файловую функцию из RTL строку, полученную из TEdit:
И в обратную сторону:
Важно: UTF8ToAnsi возвратит пустую строку, если строка в UTF-8 содержит неверные символы.
Важно: AnsiToUTF8 и UTF8ToAnsi требуют менеджера «широких» строк (widestring) в Linux, BSD и macOS. Можно воспользоваться функциями SysToUTF8 или UTF8ToSys (из модуля FileUtil) или добавить менеджер, включив cwstring одним из первых модулей в разделе uses программы.
Строки WideString и AnsiString
При передаче AnsiString в качестве WideString требуется преобразование кодировки.
Работа со строками и символами UTF-8
В Lazarus до версии 0.9.30 включительно функции LCL для работы с UTF-8 находились в модуле LCLProc. В Lazarus 0.9.31 и последующих они в целях совместимости по-прежнему доступны при подключении LCLProc, но сам код работы с UTF-8 находится в модуле lazutf8 пакета lazutils.
Для выполнения операций над строками в UTF-8 используйте функции модуля lazutf8 вместо предоставляемых модулем SysUtils из FPC, поскольку SysUtils не готов для работы с юникодом, а lazutf8 готов. Просто замените утилиты из SysUtils на эквивалентные из lazutf8, имеющие те же имена с префиксом UTF-8.
Учтите также, что перебор символов как элементов строки-массива не подходит для юникода. Эта особенность присуща не только UTF-8, юникод не предполагает фиксированный размер каждого символа. Возможны два основных способа перебора символов строки в кодировке UTF-8:
Поиск подстроки
Благодаря особенностям UTF-8 для поиска подстроки подходят обычные функции поиска подстроки. Несмотря на мультибайтность, первый байт не может быть спутан со вторым. Поэтому поиск корректной подстроки в UTF-8 при помощи Pos всегда возвращает правильную позицию с точки зрения UTF-8:
Доступ к символам UTF-8
Доступ к n-му символу UTF-8
Иногда помимо последовательного требуется и произвольный доступ к символам UTF-8.
Получение кодов символов при помощи UTF8CharacterToUnicode
Пример демонстрирует получение 32-битного кода каждого символа строки в UTF-8:
UTF-8 Copy, Length, LowerCase и т.п.
В модуле lazutf8 (LCLProc для Lazarus 0.9.30 и ранее) реализованы практически все операции над строками в UTF-8. Ниже приведён список утилит из lazutf8.pas:
Работа с именами файлов и каталогов
Элементы управления и функции Lazarus ожидают имена файлов и каталогов в кодировке UTF-8, но RTL использует для таких имён строки в ANSI.
Например, пусть кнопка назначает текущий каталог свойству Directory элемента TFileListBox. Функция RTL GetCurrentDir использует ANSI, а не юникод, поэтому требуется преобразование:
Модуль FileUtil содержит общие файловые функции в варианте UTF-8:
Восточно-азиатские языки в Windows
Шрифт элементов управления пользовательского интерфейса по умолчанию (Tahoma) в Windows XP в состоянии правильно отображать несколько письменностей/алфавитов/языков, включая арабский, русский (кириллица) и западноевропейские языки (латинский/греческий алфавиты), но не восточно-азиатские как китайский, японский и корейский.
Для корректного отображения указанных языков стандартным шрифтом достаточно в Панели управления выбрать Региональные настройки, щёлкнуть вкладку Языки и установить поддержку восточно-азиатских языков. Естественно, что в версиях Windows XP на указанных языках этот пакет включён по умолчанию. Дополнительные инструкции здесь.
Более позднее версии Windows скорее всего не требуют установки дополнений для поддержки указанных языков.
Особенности Free Pascal
Примечание. Некоторые текстовые редакторы в MS Windows могут полагать, что файлы используют системную кодовую страницу (кодировку OEM) и отображают в них неправильные символы. Не добавляйте BOM. Если добавить BOM, то придётся изменить все строковые присваивания.
Когда отсутствует BOM (и кодировка не задана параметром) компилятор считает, что строка в системной кодировке и копирует каждый байт в строку без преобразований. LCL ожидает строки именно в таком виде.
Основы юникода
Стандарт Unicode сопоставляет целые от 0 до 10FFFF(h) символам. Каждое такое сопоставление именуется кодовой точкой (code point). Другими словами, юникодные символы определены для кодовых точек от U+000000 до U+10FFFF (от 0 до 1 114 111).
Для представления кодовых точек как уникальных байтовых последовательностей существуют три основных схемы. Эти схемы называют форматами юникодных преобразований: UTF-8, UTF-16 и UTF-32. Преобразование между всеми ними возможно. Их основные свойства:
UTF-8 обладает несколькими важными и полезными свойствами: Содержимое интерпретируется как последовательность байтов, поэтому понятие порядка байт «от младшего» или «от старшего» отсутствует. Юникодные символы от U+0000 до U+007F (ASCII) кодируются байтами от 00h до 7Fh (совместимо с ASCII). Это значит, что файлы и строки, содержащие только 7-битные символы ASCII, кодируются одинаково в ASCII и в UTF-8. Все символы больше U+007F кодируются как последовательность нескольких байтов, у каждого из которых старшие биты установлены в 1. Последовательность байт одного символа заведомо не содержится в более длинной последовательности байт другого символа. Это позволяет без затруднений искать подстроки. Первый байт мультибайтовой последовательности (представляющей не-ASCII символ) всегда принадлежит диапазону от C0h до FDh и показывает количество последующих байт для этого символа. Все последующие байты мультибайтной последовательности принадлежат диапазону от 80h до BFh. Это позволяет легко выполнять ресинхронизацию и способствует надежности.
UTF-16 обладает следующими важными свойствами: Используется одно 16-битное слово для кодирования символов от U+0000 до U+d7ff и два 16-битных слова для кодирования всех остальных символов.
В заключение, любой юникодный символ возможно представить как один 4-байтный/32-битный элемент в UTF-32.
Детали реализации
Lazarus/LCL обычно использует только UTF-8
Начиная с Lazarus 0.9.31 интерфейс GTK1 объявлен устаревшим, все интерфейсы LCL совместимы с юникодом, Lazarus и LCL используют строки только в кодировке UTF-8, если явно не указано, что функция/процедура принимает другие кодировки.
Перевод интерфейса Win32 на юникод
Обзор
Сперва, и это самое важное, во избежание поломки существующего интерфейса ANSI следует все юникодные интерфейсные модификации заключить в IFDEF WindowsUnicodeSupport. После стабилизации модификаций все IFDEF-ы будут убраны и останется только юникодная часть. К тому моменту все существующие программы, использующие символы ANSI, потребуют миграции на юникод.
Win9x не поддерживает юникод
Платформы Широкие функции, присутствующие в Windows 9x
Некоторые функции широкого API присутствуют в Windows 9x. Вот список таких функций: http://support.microsoft.com/kb/210341
Функции, требующие версий Ansi и Wide
Снимки экрана
Кодовые страницы FPC
Почему LCL не использует кодовые страницы для исходных текстов?
-Fcutf8 и <$codepage utf8>существуют не первый год.
Следующие программы требуют FPC 2.7.1. Описанные трудности существуют и на более старых компиляторах.
Приведённый выше код прост и понятен, жаль только, что работает подобное лишь в простейших случаях. Посмотрим на программу ниже:
Так что же пошло не так?
Одурачить компилятор при помощи ‘ä=’+#$C3#$A4 не выйдет. Придётся определить две отдельные строковые константы.
Использование символов не из диапазона UCS-2 приведёт к
Вот это да, всё как хотелось. Можно даже смешивать строковые константы в ASCII и не-ASCII. Без указания кодовой страницы компилятор просто сохраняет строковые константы как последовательности байтов. А это и есть UTF-8.
В этом одна из причин того, почему LCL приложения не используют флаги кодировок.
В msegui реализована экосистема широких строк, которая работает лучше, чем кодовые страницы.
RTL с кодовой страницей UTF-8 по умолчанию
Обычно RTL использует для строк системную кодовую страницу (например, FileExists или TStringList.LoadFromFile). Под Windows RTL не использует юникод, вам недоступны символы вне вашей языковой группы. LCL работает с кодировкой UTF-8, поддерживающей все символы юникода. Под Linux и macOS системной кодовой страницей обычно является UTF-8, поэтому для них RTL по умолчанию использует CP_UTF8.
LCL Unicode Support/ru
Contents
Введение
Начиная с 0.9.25 Lazarus полностью поддерживает юникод (Unicode) на всех платформах, исключая Gtk 1. На этой странице размещены инструкции для пользователей Lazarus, планы на будущее, описаны основные концепции и детали реализации.
Инструкции для пользователей
Хотя в Lazarus есть юникодные наборы виджетов, важно отметить, что не всё в юникоде. Кодировка строк и правильное преобразование между библиотеками, ожидающими разные кодировки, является ответственностью разработчика.
Обычно библиотекой используется единая кодировка строк (речь о динамической библиотеке DLL или пакете Lazarus). Каждая библиотека обычно ожидает одну кодировку, которой может быть юникод (UTF-8 для Lazarus) или ANSI (что означает системную кодировку, которая может быть UTF-8 или другой). RTL и FCL в FPC версий 2.4-2.6 ожидают строки ANSI.
Преобразование между юникодом и ANSI возможно при помощи функций UTF8ToAnsi и AnsiToUTF8 модуля System или UTF8ToSys и SysToUTF8 модуля FileUtil (Lazarus). Последние две мощнее (быстрее), но добавят к программе больше кода.
FPC не юникодный
Библиотеки Free Pascal времени исполнения (RTL) и свободных компонентов (FCL) в текущих версиях FPC (по 2.6.1) используют ANSI, поэтому требуется преобразование строк, получаемых из юникодных или переделываемых в юникодные библиотек (например, LCL).
Преобразование между ANSI и юникодом
Допустим, нужно передать в файловую функцию из RTL строку, полученную из TEdit:
И в обратную сторону:
Важно: UTF8ToAnsi возвратит пустую строку, если строка в UTF-8 содержит неверные символы.
Важно: AnsiToUTF8 и UTF8ToAnsi требуют менеджера «широких» строк (widestring) в Linux, BSD и macOS. Можно воспользоваться функциями SysToUTF8 или UTF8ToSys (из модуля FileUtil) или добавить менеджер, включив cwstring одним из первых модулей в разделе uses программы.
Строки WideString и AnsiString
При передаче AnsiString в качестве WideString требуется преобразование кодировки.
Работа со строками и символами UTF-8
В Lazarus до версии 0.9.30 включительно функции LCL для работы с UTF-8 находились в модуле LCLProc. В Lazarus 0.9.31 и последующих они в целях совместимости по-прежнему доступны при подключении LCLProc, но сам код работы с UTF-8 находится в модуле lazutf8 пакета lazutils.
Для выполнения операций над строками в UTF-8 используйте функции модуля lazutf8 вместо предоставляемых модулем SysUtils из FPC, поскольку SysUtils не готов для работы с юникодом, а lazutf8 готов. Просто замените утилиты из SysUtils на эквивалентные из lazutf8, имеющие те же имена с префиксом UTF-8.
Учтите также, что перебор символов как элементов строки-массива не подходит для юникода. Эта особенность присуща не только UTF-8, юникод не предполагает фиксированный размер каждого символа. Возможны два основных способа перебора символов строки в кодировке UTF-8:
Поиск подстроки
Благодаря особенностям UTF-8 для поиска подстроки подходят обычные функции поиска подстроки. Несмотря на мультибайтность, первый байт не может быть спутан со вторым. Поэтому поиск корректной подстроки в UTF-8 при помощи Pos всегда возвращает правильную позицию с точки зрения UTF-8:
Доступ к символам UTF-8
Доступ к n-му символу UTF-8
Иногда помимо последовательного требуется и произвольный доступ к символам UTF-8.
Получение кодов символов при помощи UTF8CharacterToUnicode
Пример демонстрирует получение 32-битного кода каждого символа строки в UTF-8:
UTF-8 Copy, Length, LowerCase и т.п.
В модуле lazutf8 (LCLProc для Lazarus 0.9.30 и ранее) реализованы практически все операции над строками в UTF-8. Ниже приведён список утилит из lazutf8.pas:
Работа с именами файлов и каталогов
Элементы управления и функции Lazarus ожидают имена файлов и каталогов в кодировке UTF-8, но RTL использует для таких имён строки в ANSI.
Например, пусть кнопка назначает текущий каталог свойству Directory элемента TFileListBox. Функция RTL GetCurrentDir использует ANSI, а не юникод, поэтому требуется преобразование:
Модуль FileUtil содержит общие файловые функции в варианте UTF-8:
Восточно-азиатские языки в Windows
Шрифт элементов управления пользовательского интерфейса по умолчанию (Tahoma) в Windows XP в состоянии правильно отображать несколько письменностей/алфавитов/языков, включая арабский, русский (кириллица) и западноевропейские языки (латинский/греческий алфавиты), но не восточно-азиатские как китайский, японский и корейский.
Для корректного отображения указанных языков стандартным шрифтом достаточно в Панели управления выбрать Региональные настройки, щёлкнуть вкладку Языки и установить поддержку восточно-азиатских языков. Естественно, что в версиях Windows XP на указанных языках этот пакет включён по умолчанию. Дополнительные инструкции здесь.
Более позднее версии Windows скорее всего не требуют установки дополнений для поддержки указанных языков.
Особенности Free Pascal
Примечание. Некоторые текстовые редакторы в MS Windows могут полагать, что файлы используют системную кодовую страницу (кодировку OEM) и отображают в них неправильные символы. Не добавляйте BOM. Если добавить BOM, то придётся изменить все строковые присваивания.
Когда отсутствует BOM (и кодировка не задана параметром) компилятор считает, что строка в системной кодировке и копирует каждый байт в строку без преобразований. LCL ожидает строки именно в таком виде.
Основы юникода
Стандарт Unicode сопоставляет целые от 0 до 10FFFF(h) символам. Каждое такое сопоставление именуется кодовой точкой (code point). Другими словами, юникодные символы определены для кодовых точек от U+000000 до U+10FFFF (от 0 до 1 114 111).
Для представления кодовых точек как уникальных байтовых последовательностей существуют три основных схемы. Эти схемы называют форматами юникодных преобразований: UTF-8, UTF-16 и UTF-32. Преобразование между всеми ними возможно. Их основные свойства:
UTF-8 обладает несколькими важными и полезными свойствами: Содержимое интерпретируется как последовательность байтов, поэтому понятие порядка байт «от младшего» или «от старшего» отсутствует. Юникодные символы от U+0000 до U+007F (ASCII) кодируются байтами от 00h до 7Fh (совместимо с ASCII). Это значит, что файлы и строки, содержащие только 7-битные символы ASCII, кодируются одинаково в ASCII и в UTF-8. Все символы больше U+007F кодируются как последовательность нескольких байтов, у каждого из которых старшие биты установлены в 1. Последовательность байт одного символа заведомо не содержится в более длинной последовательности байт другого символа. Это позволяет без затруднений искать подстроки. Первый байт мультибайтовой последовательности (представляющей не-ASCII символ) всегда принадлежит диапазону от C0h до FDh и показывает количество последующих байт для этого символа. Все последующие байты мультибайтной последовательности принадлежат диапазону от 80h до BFh. Это позволяет легко выполнять ресинхронизацию и способствует надежности.
UTF-16 обладает следующими важными свойствами: Используется одно 16-битное слово для кодирования символов от U+0000 до U+d7ff и два 16-битных слова для кодирования всех остальных символов.
В заключение, любой юникодный символ возможно представить как один 4-байтный/32-битный элемент в UTF-32.
Детали реализации
Lazarus/LCL обычно использует только UTF-8
Начиная с Lazarus 0.9.31 интерфейс GTK1 объявлен устаревшим, все интерфейсы LCL совместимы с юникодом, Lazarus и LCL используют строки только в кодировке UTF-8, если явно не указано, что функция/процедура принимает другие кодировки.
Перевод интерфейса Win32 на юникод
Обзор
Сперва, и это самое важное, во избежание поломки существующего интерфейса ANSI следует все юникодные интерфейсные модификации заключить в IFDEF WindowsUnicodeSupport. После стабилизации модификаций все IFDEF-ы будут убраны и останется только юникодная часть. К тому моменту все существующие программы, использующие символы ANSI, потребуют миграции на юникод.
Win9x не поддерживает юникод
Платформы Широкие функции, присутствующие в Windows 9x
Некоторые функции широкого API присутствуют в Windows 9x. Вот список таких функций: http://support.microsoft.com/kb/210341
Функции, требующие версий Ansi и Wide
Снимки экрана
Кодовые страницы FPC
Почему LCL не использует кодовые страницы для исходных текстов?
-Fcutf8 и <$codepage utf8>существуют не первый год.
Следующие программы требуют FPC 2.7.1. Описанные трудности существуют и на более старых компиляторах.
Приведённый выше код прост и понятен, жаль только, что работает подобное лишь в простейших случаях. Посмотрим на программу ниже:
Так что же пошло не так?
Одурачить компилятор при помощи ‘ä=’+#$C3#$A4 не выйдет. Придётся определить две отдельные строковые константы.
Использование символов не из диапазона UCS-2 приведёт к
Вот это да, всё как хотелось. Можно даже смешивать строковые константы в ASCII и не-ASCII. Без указания кодовой страницы компилятор просто сохраняет строковые константы как последовательности байтов. А это и есть UTF-8.
В этом одна из причин того, почему LCL приложения не используют флаги кодировок.
В msegui реализована экосистема широких строк, которая работает лучше, чем кодовые страницы.
RTL с кодовой страницей UTF-8 по умолчанию
Обычно RTL использует для строк системную кодовую страницу (например, FileExists или TStringList.LoadFromFile). Под Windows RTL не использует юникод, вам недоступны символы вне вашей языковой группы. LCL работает с кодировкой UTF-8, поддерживающей все символы юникода. Под Linux и macOS системной кодовой страницей обычно является UTF-8, поэтому для них RTL по умолчанию использует CP_UTF8.
Lazarus символ по коду
Знакомство с символьными и строковыми типами данных, использование компонентов для работы со строками.
Понятия «символ» и «строка»
Нажмите кнопку «Пуск«, выберите команду «Выполнить» и в окне «Запуск программы» укажите
Здесь мы имеем возможность переключаться на четыре системы исчисления:
Итак, подведем некоторые итоги.
Символьные типы данных
Этот пример выполнять не нужно, он просто демонстрирует использование кавычек в строковых выражениях, и возможность в выражении соединять несколько строк в одну с помощью знака » + «. Однако вернемся к нашему проекту. После того, как мы присвоили символьной переменной большую английскую букву «Z», мы вывели содержимое переменной с помощью строки
Таким образом, мы можем работать с отдельными символами. Однако если вы исправите код, и вместо буквы «Z» в строке
Если строка получается длинной, то после запятой можно переносить текст на другую строку.
Теперь вернемся к обработчику нажатия на кнопку и переделаем его:
Теперь всё сработает как надо, и русский символ » Я » выйдет так же, как английский » Z «.
Однако, это еще не всё. Символы можно вводить, указывая их номер в таблице символов. Для этого перед номером нужно указать символ » # «, например:
Сохраните проект, скомпилируйте и запустите на выполнение. Теперь содержимое двух символьных переменных выходит в одном сообщении, но каждое на своей строке.
Строковые типы данных
Как видите, поскольку строка в Lazarus имеет формат UTF8, то никаких особых ухищрений для работы со строками тут не нужно, в переменную типа String можно записать любой, в том числе и русский текст. Размер строки String неограничен, однако имеется возможность жестко задать размер. Такой способ используется, когда вы точно знаете, что больше данного размера строка не будет. В этом случае размер указывается после ключевого слова String в квадратных скобках, например:
Имейте в виду, что тип String является динамичным, то есть, заранее память для него не выделяется. Строго говоря, выделяется память на указатель строки, а не на саму строку. Физически строке выделяется необходимая память только в момент присвоения ей какого-то значения. Однако нередко возникает необходимость очистить такую строку. Для этого достаточно присвоить ей пустые кавычки, без пробелов и без каких-либо других символов:
Строковой переменной можно присваивать значения символьных переменных или констант, например:
Помимо String в Lazarus есть и другие строковые типы.
Сохраните проект, скомпилируйте и запустите. При нажатии на вторую кнопку у вас выйдет сообщение из трех строк
Резюмируем некоторые положения:
Компоненты для ввода строк
Компонент TEdit
На форму установите компонент TEdit (если не помните, где он находится, смотрите «Анатомия проекта» ). По умолчанию, он имеет ширину 80 пикселей (свойство Width ), увеличьте его до 200. Теперь давайте разбираться с основными свойствами этого компонента, которые могут нам понадобиться, для этого он должен быть выделен.
Начнем с самого начала. Рекомендую прочитать пояснения к свойству, а затем «поиграть» с его значениями, меняя их и запуская программу на выполнение, чтобы посмотреть результат. Затем вернуть значение по умолчанию, если не будет предложено иное, после чего переходить к следующему свойству. Таким образом, вы познакомитесь с компонентом более подробно.
Компонент TLabelEdit
На вкладке Additional Палитры компонентов есть странный компонент TLabelEdit :
Можете щелкнуть по кнопке «—» слева от свойства, закрыв список подсвойств, больше ничего интересного там нет. Посмотрим, какие свойства еще нам понадобятся.
Компонент TMaskEdit
Когда оно раскрыто, мы видим следующую картину:
В строке «Маска ввода» мы можем указать маску, которая будет влиять на формат заполняемой пользователем строки. В маске можно применять некоторые символы, вводимые в каждой позиции, и символы, добавляемые самой маской. Маска может иметь следующие символы:
| 0 | В данной позиции должна быть цифра. Если пользователь введет не все цифры маски, будет создана исключительная ситуация, и он не сможет продолжать работу, не заполнив все положенные цифры. Если такая ситуация возникла у вас во время тестового выполнения программы, можете закрыть программу командой «Запуск->Сбросить отладчик». |
| 9 | В данной позиции может быть либо цифра, или ничего. |
| # | В данной позиции может быть знак «+», «-«, цифра, или ничего. |
| L | В данной позиции должна быть буква. |
| l | В данной позиции должна быть буква или ничего. |
| A | В данной позиции должна быть буква или цифра. |
| a | В данной позиции должна быть буква или цифра, или ничего. |
| C | В данной позиции должен быть любой символ. |
| c | В данной позиции должен быть любой символ, или ничего. |
Кроме того, в маске можно использовать различные разделители:
| : | Обычно применяется для разделения часов, минут, секунд. |
| / | Обычно применяется для разделения года, месяца, дня. |
| — | Обычно применяется для разделения цифр, например, в телефонных номерах. |
Давайте укажем в строке «Маска ввода» маску телефона:
В Редакторе масок помимо строки «Маска ввода» есть и другие строки. В строке «Символы для пробелов» мы можем указать символ, который будет выводиться маской в том месте, где пользователь должен будет что-то ввести. По умолчанию, это символ подчеркивания » _ «. Пользователь будет видеть пустую маску телефона, как
Мы можем использовать и другие символы для заполнения пробелов.
Ниже в Редакторе масок есть флажок «Сохранить литерал«. Этот флажок включает или выключает возможность сохранения в тексте символов-разделителей. Если флажок включен, то в тексте сохранятся символы маски вместе с символами-разделителями, например:
Если флажок выключен, то в конечном тексте останутся только символы маски:
В строке «Тестовый ввод» мы можем опробовать полученную маску, не запуская программу на выполнение.
Итак, для нашего примера в строке «Маска ввода» укажите
В «Символы для пробелов» оставьте » _ «. Флажок «Сохранять литерал» пусть будет включен. Как только нажмете «ОК«, свойство EditMask изменится, теперь в нем будет текст:
Таким образом, мы могли бы и не пользоваться Редактором масок, а указать маску вручную. Например, введя значение