Вышедшая в сентябре прошлого Delphi XE2 содержит рекордное количество нововведений.
Краткие обзоры возможностей Delphi XE2 уже публиковались на Хабре. Но, очевидно, самым ярким новшеством стала платформа FireMonkey, и здесь я хотел бы уделить немного внимания именно ей.
Я сделал небольшую подборку ссылок на материалы, которые, как я надеюсь, помогут вам составить более-менее адекватное представление об этой платформе. Но прежде, для тех, кто не в курсе, я вкратце расскажу, что же такое FireMonkey.
Embarcadero Technologies позиционирует FireMonkey как платформу для создания полнофункциональных бизнес-приложений для Windows, Mac и iOS. При этом данная платформа является нативной для каждой из ОС, т.е. при работе приложения, созданного с помощью FireMonkey, не используется ни каких дополнительных надстроек.
FireMonkey привязывается непосредственно к нативной (с точки зрения ОС) графической библиотеке, такой как OpenGL или DirectX. Таким образом, предлагается наилучшее решение с точки зрения GPU.
Ядро FireMonkey архитектуры представляет собой мощную библиотеку классов (в том числе визуальных компонентов).
Целевая платформа выбирается в процессе компиляции.
Первая версия FireMonkey поддерживает только Win32, Win64, MacOSX и iOS, в будущем Embarcadero планирует портировать её на несколько других платформ.

Что стоит учитывать?

Несмотря на то, что платформа FireMonkey предоставляет обширный инструментарий для разработки 3D приложений, ее нельзя рассматривать как игровой движок. FireMonkey позиционируется именно как платформа для разработки бизнес-приложений.
Сейчас продукт находится в начальной стадии своей эволюции. И многие функциональные возможности FireMonkey претерпевают изменения, как качественные, так и количественные.

Я надеюсь, что ссылки, приведенные ниже, помогут разобраться с основными возможностями новой платформы.
Официальная страница продукта на сайте Embarcadero (рус.)

Среди англоязычного материала хотелось бы выделить серию (англ.)

Что посмотреть?

Что касается последней версии Delphi, то видеоматериала, посвященного возможностям продукта и приемам работы с ним, как никогда много. Как официального, от Embarcadero, так и от независимых разработчиков. На YouTube очень много видео о FireMonkey, вы просто можете воспользоваться поиском. Среди этого обилия материала выделю серию из трех роликов от Марко Канту - RAD in Action landing page ., таким образом, придав своим изысканиям вектор полезности.

06.03.2013 12:46 пп

Очень я страдал из-за отсутствия компонента-браузера в FireMonkey. Известный проект Delphi Chromium Embedded все-таки включил поддержку FMX в последнем билде. Но не смотря на то, что прошло довольно много времени, поддержку FMX2 автор добавлять не торопится. В итоге пришлось брать ситуацию в свои руки.

Компонент TChromiumFMX из официальной сборки вполне себе работает в FireMonkey (в XE2), но в FMX2 даже не компилируется. Пришлось немного разобраться с тем, как он устроен и исправить. Благо, серьезных изменений не потребовалось.

В FMX2 изменились две нужные компоненту вещи.

Первое — TBitmap больше не имеет свойств ScanLine и StartLine . Прямой доступ к содержимому TBitmap переделали (интересно, зачем?) и теперь оно доступно через класс TBitmapData , который возвращает метод TBitmap.Map .

Ну и второе, более известное — Platform .* больше нет, теперь необходимо получать нужный интерфейс через TPlatformServices.GetPlatformService . Здесь все довольно прямолинейно и проблем нет.

Особо изобретательно я его не тестировал, но для моих целей компонент вполне подходит — сайты через него смотреть можно. Скачать его . Еще, пожалуй, отправлю мои правки автору, может быть сочтет нужным добавить их в официальную версию.

30.07.2012 2:43 дп

Jason Southwell предлагает разработать набор FireMonkey-оберток для нативных контролов Windows/OSX и собирает на это деньги . Планирует для начала собрать 20 тысяч долларов.

Идея ясна. Существующие компоненты FireMonkey отрисовываются средствами Delphi практически с нуля, что с одной стороны во многом и обеспечивает их кроссплатформенность, но с другой — в результате мы получаем компоненты не вполне естественно выглядящие в обеих поддерживаемых на сегодня ОС. И это полбеды — кроме внешнего вида, приходится самостоятельно разрабатывать и логику этих компонентов. Например, RichEdit довольно сложен, самостоятельно повторить его логику в рамках FireMonkey — задача не из тривиальных. И VCL, и CLX не изобретали велосипедов, а пользовались готовым.

А теперь плохая новость. В рантайме все работает, но я не нашел никакого способа добавить свой новый тип вкладки в Items Designer. И похоже, что та же самая проблема есть у всех списковых контролов: TListBox, TGrid и т.п. Сначала мне подход к их реализации очень понравился, а вот теперь даже как-то сомневаюсь. Поиск в интернете показал, что я с этой проблемой не одинок .

Справка молчит, в коде я тоже не нашел ничего. Неужели никак? Это было бы крайне неприятно.

TRippleEffect класс для создания эффекта, который накладывает рябь волн на текстуру визуальных объектов.

Центр ряби указывается в свойстве Center . Другие аспекты ряби можно настроить при помощи свойств Amplitude (Амплитуда), AspectRatio , и Phase (Фаза). Количество волн ряби определяется свойством Frequency (Частота).

В следующей таблице показаны результаты влияния TRippleEffect на PNG фотографию, размещенную на форме (с помощью объекта ). Центр ряби находится в середине изображения. Остальные свойства TRippleEffect используются с их значениями по умолчанию (Amplitude = 0,1, AspectRatio = 1,5, Frequancy = 70, Phase = 0).

В этом уроке вы будете использовать несколько базовых эффектов изображений в приложении FireMonkey.

Шаг 1: Применить эффект к изображению.

В FireMonkey, применение эффекта изображения к изображению является простым процессом. Просто создайте компонент, который может содержать изображение, а затем примените один из эффектов изображения.

Создайте новое приложение FireMonkey (File> New> FireMonkey Desktop Application> HD FireMonkey Application ).

Поместите компонент на форму.

Выделите компонент на панели инструментов.

Расположите TImage на форме в конструкторе.

Вы можете видеть, что компонент не помещается в центр конструктора форм. Как показано на рисунке, необходимо, чтобы размер области изображения был как можно больше. Чтобы сделать это, выберите компонент на форме конструктора, а затем изменить свойства Align в alClient в Object Inspector, чтобы размер компонента стал таким же, как клиентский размер области формы.

Выберите изображение, к которому вы хотите применить эффект. Компонент хранит картину в свйостве Bitmap . Выберите свойство Bitmap в объектном инспекторе, и используя Edit ... для выбора изображения.

1. Теперь вы можете выбрать эффект для изображения. На палитре инструментов выберите TRippleEffect .

Теперь RippleEffect отображается в в окне Structure .

Чтобы применить эффект он должен быть определен как дочерний для другого компонента. В этом случае, RippleEffect1 должны быть определены в качестве дочернего Image1 . Чтобы это сделать, перетащите RippleEffect1 и поместите его на Image1 на панели структуры.

1. Теперь вы можете видеть, что RippleEffect уже работает на Form Designer.

1. Измените свойство Frequency на 20 .

Шаг 2: Применить эффект анимации к эффекту RippleEffect.

Выделите RippleEffect на панели Structure .

Выделите свойство Phase в Object Inspector и выполните команду Create New TFloatAnimation из выпадающего меню.

Убедитесь, что FloatAnimation1 определена как дочерний элемент RippleEffect1 .

Измените свойства FloatAnimation1 как показано ниже:

Ну и напоследок добавим событийную процедуру OnMouseMove к .

FireMonkey — это центральная технология «нового Delphi». Расскажите, пожалуйста, о целях, возможностях и технических аспектах устройства этой принципиально новой библиотеки. По истечении времени, оглядываясь назад, насколько тяжелым и оправданным оказался ваш отказ от дальнейшего развития сверхпопулярной VCL?

Была выбрана в качестве магистрального направления развития технологии Delphi для достижения конкретной цели — мульти-платформенной разработки из одной среды, на основе единой базы исходных кодов, причем без необходимости в кардинальной переподготовки разработчиков. В рамках ставшей классической и сверхпопулярной VCL это было невозможно, её связь с WinAPI была слишком тесной, можно сказать, «на генетическом уровне».

Компоненты VCL не имели «абстрактной» прослойки между функциональным уровнем с точки зрения интерфейса и механизмами их отображения. Функциональный уровень — то, как вёдет себя как элемент управления, на какие события реагирует, какое взаимодействие с пользователем обеспечивает. Отображение — вызов платформенно-ориентированных методов визуализации как некого изображения, сформированного растровыми объектами и векторными примитивами. FireMonkey изначально реализовывала принцип строгого разделения элемента управления на две составляющие: «поведенческую» и «визуальную».

Всеволод Леонов, Embarcadero Technologies

Первая в целом повторят даже не основы VCL, а суть объектно-ориентированного программирования. Компонент есть класс, классы компонентов образуют иерархию, где можно выделить семейства и модули. Класс компонента слабо связан с тем, как он изображается.

Визуальная «картинка» формируется динамически, она не прописана жёстко в классе компонента. Изображение или «стиль» в FireMonkey загружается в компонент при запуске приложения. Мы имеем некий функциональный каркас для компонента, а «обшивка» или «облицовка» может быть изменена, но зачем? Именно затем, чтобы приложения FireMonkey смотрелись аутентично на любой платформе — Windows 7, Windows 8, Mac OS, iOS и, в ближайшем будущем, в Android. Этого традиционная монолитная классовая структура VCL обеспечить не могла.

Здесь особую роль играет технологичность подхода. Принципиально можно взять библиотеку VCL и «нафаршировать» WinAPI и всеми другими возможными платформенными вызовами. На очень ограниченном подмножестве компонентов это ещё можно сделать, но VCL содержит несколько сотен компонентов, поэтому такой подход мог бы просто «убить» VCL. Было принято решение «не трогать» VCL, а новые возможности развивать на новой платформе — FireMonkey. Данная технология даже обладает определённым техническим изяществом — в момент сборки проекта под конкретную платформу среда Delphi IDE подключает нужный компилятор, а компоненты интерфейса получают платформенный стиль.

Для пользователя это — один щелчок мыши и то же исходный код, для Delphi, — многолетний упорный труд разработчиков по созданию подобной мульти-платформенной библиотеки.

Когда стало ясно, что FireMonkey будет введена отдельной новой платформой, нужно было выбрать правильную стратегию сосуществования: Embarcadero не хотела никоим образом оказать негативное влияние на пользователей VCL. Поэтому мы выбрали следующий план: VCL остаётся идеологически и архитектурно стабильной для обеспечения максимально возможной совместимости, облегчая миграцию проектов на современные версии. Развитие FireMonkey будет идти естественным и параллельным путём, без «оглядки» на VCL.

Слабым местом такого решения является достаточно проблематичная миграция с VCL на FireMonkey в рамках одного проекта. Но зато для нового проекта разработчик может выбрать FireMonkey для обеспечения мульти-платформенности своего результирующего приложения. После релиза XE4 с поддержкой iOS мы уже можем говорить о ярких конкурентоспособных преимуществах Delphi для начала мобильной разработки в корпоративной среде, которые буду увеличены после реализации планируемой поддержки Android.

Поэтому как такового явного «отказа» от развития VCL нет. В новых версиях VCL-часть Delphi также развивается. Это и поддержка 64-bit, и введение стилизации для визуальных компонентов, и реализация механизма гибких динамических связей или «байндинга», и включение библиотеки FireDAC для работы с базами данных в VCL-проектах. Просто на фоне гигантского качественного скачка за счёт FireMonkey прогресс в VCL выглядит несколько непроявленным. Но, как бы то ни было, VCL — неотъемлемая часть Delphi и останется таковой ещё на долгие годы. Хотя эволюция платформ и современное положение дел в области ОС для настольных систем и мобильных устройств таковы, что будущее однозначно за FireMonkey.

В интервью мы уже обсудили поддержку iOS, давайте расскажем нашим читателям о поддержке других новейших технологий со стороны последней RAD Studio XE4, например, таких как Windows 8 и WinRT, 64-битных систем, MacOS и так далее. Можно перечислить, что вы ещё можете предложить современному избалованному новшествами программисту?

Скорее всего, современный программист не «избалован» новшествами. Для крупных проектов любое «новшество» зачастую оборачивается гигантским объемом работ.

Например, все долго ждали , многие тут же бросились переводить свои коды на новую платформу. Но выясняется, что даже весьма профессиональные команды к этому не готовы. Компилируемый 64-битный код не означает работоспособный. Стали всплывать «грехи молодости», например, использование инструкций в предположении о 4-байтном размере адреса. Отсутствие культуры проведения тестов, вкупе с технологической неготовностью в сжатые сроки внедрить данный процесс.

И тут — чем больше проект, измеряемый, допустим, количеством строк исходного кода, тем аккуратней и взвешенней относятся программисты к различного рода нововведениям в диапазоне от внешнего вида «кнопки» в интерфейсе до «синтаксического сахара» в компиляторе.

Одним из таких «проблематичных» достижений явился выход Windows 8. Лично у меня, как пользователя ПК, и просто современного IT-специалиста — Windows 8 вызывает восторг. Но для разработчиков, которым прислали партию компьютеров под Windows 8 с ТЗ на разработку под новую ОС в нагрузку, это означает определенные сложности.

Мы постарались максимально комфортно и безболезненно обеспечить поддержку разработки под новый интерфейс этой ОС. Поэтому и для VCL, и для FireMonkey введены специальные стили, а программист может либо перестроить интерфейс приложения, либо создать заново приложение, которое будет неотличимо от «родного» для Windows 8 по внешнему виду. Конечно, есть потребность в «нативной» поддержке Windows 8 за счёт WinRT. Но здесь сказывается приоретизация целей в современных условиях. Mac OS, iOS, Android в ближайших планах не дают пока возможности говорить о полноценной поддержке WinRT в ближайшем будущем.

Стратегической целью Embarcadero, конечно, является мульти-платформенность. Релиз RAD Studio XE4 явился ключевым, прежде всего из-за поддержки iOS. Действующий программист, использующий VCL, может в считанные часы начать разработку под iOS. Даже простое мобильное приложение может быть мгновенно преобразовано в мощный проект, работающий в рамках сложившейся инфраструктуры. Не надо думать, что это просто новый компилятор к FireMonkey и новый стиль для обеспечения соответствия интерфейсу iOS.

Это и новый визуальный дизайнер, и встроенная поддержка различных форм-факторов, и библиотеки доступа к данным, включая новую FireDAC, и технология LiveBindings для гибкого и динамического связывания с корпоративными данными. Все эти нововведения поступают синхронно — и для Windows, и для Mac OS, и для iOS. Операционная система Mac OS развивается не так стремительно, поэтому таких проблем, как переход Windows 7 — Windows 8 там нет. Но появились дисплеи Retina, и это потребовало отдельного внимания. Сейчас любое MacOS-приложение, созданное в Delphi XE4, автоматически включает в себя два стиля — «обычный» и «высокочёткий».

Т.о. одно и то же приложение может иметь одинаково качественный «нативный» интерфейс на любом настольном компьютере от Apple.

Компания Embarcadero своими новыми инновационными релизами не хочет «удивить», «поразить» или даже «развлечь» разработчиков. Скорее, наоборот, IT-сфера и так уже полна различных сюрпризов: новые устройства, новые платформы, новые пользователи, новые их потребности, новые сценарии взаимодействия. Добавьте сюда ещё и новые технологии разработки ПО, и программистам просто не останется времени на создание новых систем и на существующих — они будут только и делать, что проводить миграцию из одной среды в другую, со старой библиотеки на новую, с одного языка на другой.

Но мы и не исповедуем отказ от всего нового. Мы лишь хотим обеспечить преемственность всего — кода, интерфейса, проекта, даже профессиональных навыков при появлении новых платформ и устройств. Можно сказать, что мы боремся с нездоровым консерватизмом в отношении новых платформ за счёт здорового консерватизма в средствах разработки. Не ждите от Embarcadero экзотических продуктов, нестандартных языков программирования и диковинных средств разработки.

У нас вы всегда найдёте — визуальную разработку, классические языки, «нативный» код, и пусть новыми будут целевые платформы для ваших приложений, созданных всё тем же проверенным классическим способом.

В контексте данного блога этот проект прежде всего интересен тем, что реализован на FireMonkey и является потрясающей демонстрацией возможностей данной платформы. И вот, буквально на прошлой неделе, была выпущена публичная бета продукта. Таким образом, читатели блога могут сами “пощупать” действительно сложное FireMonkey приложение.

Пару слов о программе. В первую очередь нужно отметить то, что нынешняя версия Sphere позиционируется немного по-другому. Да, иногда так бывает…

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

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

Естественно, что Сфера использует главное преимущество FireMonkey – кроссплатформенность. Сейчас приложение доступно в Windows и MacOS редакциях. Android версия ожидается со дня на день.

Тем не менее, для меня, SphereLive интересна, прежде всего, как инновационный продукт с целым набором оригинальных решений. Иногда просто на уровне “… ух ты, как ты это сделал?” Кстати, один из разработчиков Сферы активно участвует в обсуждениях на форуме, посвящённом FireMonkey . Само по себе это может послужить поводом скачать приложение и обсудить технические вопросы непосредственно с автором. Поверьте, есть на что посмотреть, есть чему поучится.

TListView является одним из ключевых компонентов для построения интерфейса мобильного приложения в FireMonkey . Компонент этот не самый простой в использовании, зачастую предполагает значительный объем кода, зато предоставляет разработчику значительную свободу действий. Конечно, в приложениях можно использовать и TListBox , где все намного проще. Но TListBox , возможно, хорош для отображения фиксированного количества записей, для вывода данных из источников данных, однозначно нужно использовать TListView .

Главные отличия TListView от TListBox в:

1. TListBoxItem - контрол, TListViewItem - нет
2. В TListBoxItem можно добавлять любые контролы, используя Parent. В TListVIewItem - нет.
3. TListVIewItem хранит только данные для отображения
4. TListVIewItem сам выполняет отрисовку хранимых данных через метод Render
5. За счет собственно ручной отрисовки в TListVIewItem достигается прирост скорости и малое потребление памяти (хранение только актуальных данных)
6. Чтобы создать свой вариант TListViewItem , нужно создать свой класс итема, в нем реализовать требуемые данные (например время) и создать in-place редактор для редактирования времени, зарегистрировать его и т. д.

Сам по себе факт повышения производительности и уменьшения потребления памяти – веский аргумент в пользу использования TListView . Но есть и еще кое что.

Во многих Android приложениях мне приходилось наблюдать следующую реализацию списков. При нажатии на элемент списка (Item, если придерживаться выбранной терминологии), производится определенное действие. Обычно вызывается новая форма для редактирования данных. Но при нажатии с удерживанием (Long Tap) производится совершенно другое действие. И эти события не пересекаются. Иными словами Android приложения умеют четко различать “длинное нажатие” от “обычного”. Более того, ни одно из этих событий не срабатывает при скроллинге списка. Наглядный пример – список писем в Яндекс Почта.

Прежде всего хочу поздравить всех читателей блога с прошедшими праздниками и пожелать всего наилучшего в наступившем году.

В силу понятных обстоятельств я не стал делать традиционный новогодний отчет, как и строить какие-либо планы на год. Тем не менее, жизнь не стоит на месте, работа работается, и определенные события в мире Delphi происходят. Подборку пропущенных “новостей из мира Delphi” за время рождественских каникул обязуюсь опубликовать в ближайшее время. А пока расскажу о новом аппарате, который я приобрел.

С характеристиками вы можете ознакомиться на официальном сайте. А субъективное впечатление весьма приятное. Обращает на себя внимание тот факт, что аппарат буквально напичкан фирменным софтом от производителя. Да и от продавцов достался в подарок внушительный комплект софта. В работе смартфон достаточно шустр и вполне оправдывает свою стоимость (примерно $200). К слову, свой предыдущий телефон GSmart 1362 я покупал примерно за те же деньги 2 года назад. Но, как вы, наверняка, догадались, основной интерес для меня заключался в том, как будут работать FireMonkey приложения.

Прежде чем продолжить рассказ о таймере – две новости.

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

Вторая новость. Действие специальных предложений Embarcadero продлено до конца года:

Ну, а теперь непосредственно к теме поста. В принципе, все, что нам осталось – попытаться запустить уже созданное приложение под Android. Для это используем то, о чем я писал в предыдущих постах. А именно новый . Я отлаживал данное приложение на Nexus 7 , соответственно добавил представление Android 7″ Tablet. Дизайн пришлось “подрихтовать” лишь самую малость.

Наверное свой таймер не писал только ленивый. А в контексте поддержки разработки для мобильных платформ, задачу написания таймера на Delphi вообще можно считать культовой. Вот я и подумал, почему бы в качестве примера разработки FireMonkey приложения не разобрать именно таймер. Под Android, естественно. Конечно же, это будет именно мой взгляд на задачу, которая, хотя и не особо сложная, все же имеет свои нюансы. Возможно, у вас возникнут какие-то замечания, или предложения, было бы замечательно обсудить их в комментариях. Я отнюдь не эксперт в области написания мобильных приложений, поэтому любой ваше замечание будет для меня ценно.

Разрабатывать мы будем именно таймер, в англоязычном понимании этого термина. Т. е. на экране будет отображаться циферблат и четыре кнопки – “Пуск”, “Пауза”, “Стоп” и “Отмена”. Отсчет будет производиться в прямом направлении (т. е. время будет увеличиваться). Вариант, при котором задается время и идет обратный отсчет в англоязычной терминологии называется Stop Watch, возможно я попробую реализовать его позже. То, приложение, которым займемся мы, по функциональности ближе к секундомеру.

Delphi XE7, позволяет значительно упростить процесс разработки, за счет того, что теперь мы можем создать и отладить реальное приложение для Win32, а затем просто добавить представления форм для необходимых мобильных устройств и, немного подкорректировав их, получить рабочее мобильное приложение. Звучит слишком красиво, что бы быть правдой? Возможно. Но проверить данное утверждение я и хочу, реализовав поставленную задачу.

The more frequently I’m asked my colleagues in private conversations if it’s possible to develop mobile applications in FireMonkey or is it a prototype rather than a production solution?

I think, now I can ensure even the out-and-out sceptics.

My bosom friend and colleague Tagir Yumaguzin told me about the project he took part a long time ago. Now, when this project is in pre-release state, we decided that this description will be interesting for the Delphi community. In the essence, this is a really large project implemented in FM. We are talking about Sphere Live project. A little article devoted to that project was recently published in Habrahabr.ru Alexey Glyzin, chief of ‘ ‘ development department agreed to tell more about the project taking into consideration the audience of my blog.

A.B. – Alexey, in general, what your project is?

A. G. : – The idea has not appeared at once and instantly. Before the ‘Sphere’ project our team had been working on the project where stream audio/video technologies were implemented. Later we created our own software that was able to deliver multimedia streams to an unlimited amount of users including the feedback. But we needed to have a billing feature included.
The application had to comply the several requirements. First, the maximally simplified organization of conferences or transmission to the participants which amount we cannot predict. Second, the most important, is to give to our clients an opportunity to earn with our application and to reduce the complexity of the system, amount of instruments needed to use to reach the goal. The ease of organization of courses, webinar or just a consultation.

Небольшая зарубка на память, касающаяся FireDAC в актуальной версии Delphi XE6 . Но прежде, пару слов о том, где искать ответы на вопросы, касающиеся FireMonkey . Русскоязычные пользователи здесь оказались в привилегированном положении.

Еще при подготовке к харьковскому мероприятию в рамках Мирового тура RAD Studio XE5 я столкнулся с небольшой проблемой в работе с SQLite с помощью FireDAC . Если заполненную в Windows приложении базу перенести вместе с приложением на Android , кириллические строки в базе перестают читаться (вместо букв отображаются знаки вопроса). Однако, если заполнять базу непосредственно на мобильном устройстве, русские символы считываются вполне корректно. Данные из базы заполненной в стороннем приложении, или в Delphi приложении, использующем другие компоненты доступа к данным, так же отображались нормально. Слету найти решения не удалось, и мне пришлось процитировать известного украинского футбольного специалиста: “Будем разбираться!”

В отличие от последнего, разобраться с описанной проблемой мне удалось. По умолчанию при подключении к SQLite в FireDAC используется формат строк ANSI.

Если принудительно установить Unicode, то все будет работать как надо. Но есть и неприятный момент. Изменив формат строк придется во всех наборах данных пересоздать список полей, а так же заново подключить компоненты, отвечающие за отображение и ввод данных. Поэтому лучше позаботиться о кодировке сразу.

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

Простой редактор данных в таблице, обычно является частью комплексного приложения. Для редактирования таблиц я обычно использую отдельную форму. Начнем со списка продуктов. Прежде всего, нам необходимо создать DataSet для доступа к данным таблицы. В нашем случае вполне можно воспользоваться компонентом TADTable . Поместим его в DataModule и укажем значение свойства Connection . В редакторе свойства TableName появится список таблиц, из которого выбираем таблицу Products . Если вы все сделали правильно, то сможете присвоить свойству Active значение True. Компонент лучше сразу переименовать (например, ADTProduct). После этого я, обычно, создаю для DataSet’а набор полей. Вызываем редактор полей (двойное нажатие мыши на компоненте) и в контекстном меню выбираем пункт Add All Fields.

Для тех, кто не в курсе поясню суть данной операции. Здесь мы создаем предустановленный набор полей DataSet’a. Если мы этого не сделаем вручную в режиме проектирования, то, в принципе, ничего страшного не произойдет. В RunTime этот набор будет создан автоматически. Но я, все же, предпочитаю создавать его вручную. Причин тому несколько. Во-первых, так удобнее управлять набором полей, ведь мы можем создавать дополнительные (вычисляемые или lookUp) поля самостоятельно в режиме проектирования. Можем так же менять свойства самих полей. А кроме того, мы получаем возможность обращаться в коде к полям по имени компонента TField, что, на мой взгляд, существенно упрощает написание кода.

Как и в случае с VCL приложением, подключим к набору данных компонент TDataSource . Этот компонент обеспечит связь между набором данных и визуальными элементами управления. Свойство DataSet компонента должно ссылаться на наш набор данных (ADTProduct). Ниже я привожу фрагмент DFM файла

object ADTProduct: TADTable IndexFieldNames = "ID" Connection = ADConnection UpdateOptions. UpdateTableName = "Product" TableName = "Product" Left = 64 Top = 192 object ADTProductID: TADAutoIncField FieldName = "ID" Origin = "ID" ProviderFlags = [ pfInWhere, pfInKey] ReadOnly = True end object ADTProductTitle: TStringField FieldName = "Title" Origin = "Title" Size = 50 end object dsProduct: TDataSource DataSet = ADTProduct Left = 120 Top = 192 end

Обратите внимание на одну любопытную особенность, файл формы DataModule сохраняется не в формате FMX, как обычная FireMonkey форма, а в формате DFM, как и в VCL.

Следующим шагом будет создание процедуры открытия набора данных, которую мы должны будем вызывать в RunTime при запуске программы. Создадим ее в том же DataModul’е. Код процедуры предельно прост:

procedure TDM. ConnectToDB ; begin ADConnection. Open () ; ADTProduct. Open () ; end ;

Вызов процедуры разместим в обработчике события OnCreate для DataModule.