Delphi плюс Android? Есть идея! Tap#5

Эта заметка является продолжением предыдущих: Tap#1, Tap#2, Tap#3, Tap#4. И в ней я хочу завершить.

Итак, игра на логическое мышление.  Я решил сделать аналог игры Flip-Flop компании Gamos. На всякий случай, оговорюсь – я не ставлю перед собой цель создать коммерческий продукт. Цель другая –  попробовать, покрутить, поучаствовать.

Ну и поскольку, у меня нет опыта в написании игр, не думаю, что мой аналог будет таким атмосферным, как оригинал. Однако я поэкспериментирую с размером игрового поля (не только 4 на 4), “поиграю” с векторной анимацией и масштабированием, порадую близких и коллег мобильным аналогом уже подзабытой игры.

Delphi плюс Android? Есть идея! Tap#4

Эта заметка является продолжением предыдущих: Tap#1, Tap#2, Tap#3. И в ней я поговорю об анимации.

В моей будущей игре у персонажа будет два основных состояния. Назовём их “Открытый” и “Закрытый”. В первом состоянии внешний вид персонажа соответствует тому, который разработан в дизайнере и сохранён в переменной DesignPositions. Во втором, вид персонажа будет другой. Для робота я решил так: меняем цвет на серый, чуть-чуть уменьшаем общий размер, втягиваем ноги, руки и антенны, закрываем глаза.

Соответственно переход из состояния в состояние будет анимированным.

Delphi плюс Android? Есть идея! Tap#3

Эта заметка является продолжением предыдущих. Tap#1, Tap#2.

И прежде чем приступить к анимации, стоит определиться с масштабированием персонажа. То есть необходимо настроить фрейм таким образом, чтобы, задавая его размеры “сверху”, все объекты персонажа автоматически подгоняли свой размер, и персонаж (по своим внешним размерам) оказался вписанным во фрейм.

Сделать это можно очень просто. Для самой фреймы устанавливаем свойство Align = alFit (чтобы сохранить пропорцию у соотношения сторон фреймы), а всем контролам на фрейме –  Align = alScale.  Тогда, при изменении размеров фреймы, контролы будут масштабироваться автоматически. Оговорюсь, что размеры и положения контролов в FM задаются вещественными числами, поэтому масштабирование будет плавным.

Однако есть такой нюанс: платформа FM масштабирует контролы относительно их текущих размеров. Что это значит? А это значит, что при задании маленьких размеров фреймы, наш персонаж может оказаться очень маленьким. Настолько маленьким, что при последующем увеличении фреймы персонаж перестанет масштабироваться.

Delphi плюс Android? Есть идея! Tap#2

Эта заметка является продолжением предыдущей. Сегодня я расскажу, как я рисовал персонаж для будущей игры.

Delphi плюс Android? Есть идея! Tap#1

В рамках обозначенного конкурса решил я что-нибудь смастерить на FM под Андроид.

Забегая чуточку вперёд обозначу, что буду делать незаурядное приложение – игру на логическое мышление, обязательно с анимацией. В игре будет персонаж (или несколько персонажей?), в зависимости от своего состояния персонаж будет выглядеть по-разному. Соответственно переходы из состояния в состояние будут анимированными. Приложение будет в 2D, т.к. игровое поле само по себе плоское. А пока, буду описывать сам процесс…

Шаблоны в Delphi (но не дженерики)

Об этом уже писали: http://edn.embarcadero.com/article/27603 или вот http://18delphi.blogspot.ru/2013/09/templates-in-object-pascal.html.

Напишу своими словами, надеюсь в доступной для массового читателя форме.

Итак, допустим у нас есть пара классов: TSomeType1 и TSomeType2, которые объявлены в SomeUnit.pas. И допустим, что эти классы имеют одинаковый набор некоторых свойств и методов, но при этом эти свойства и методы не объявлены у их общего предка. К примеру, пусть будет так:

Полезняшки. Ограничение ввода пользователя в UTF8

У контролов типа TEdit, TMemo и других наследников от TCustomEdit есть свойство – MaxLength. Свойство ограничивает ввод пользователя до указанного количества символов. Это свойство особенно полезно при работе с базами данных – как правило, размер текстовых полей имеет ограничение.

Ну например, при работе с Oracle, если попытаться сохранить строку, которая не помещается в поле в БД, получим ошибку вида:

ORA-12899: value too large for column "OWNER"."TABLE"."COLUMN" (actual: 20, maximum: 15)

Чтобы этого избежать, достаточно у полей ввода выставить MaxLength равным размеру поля в БД, и тогда пользователь просто не сможет ввести строку большего размера.

Однако есть такой нюанс: размер поля в БД может задаваться не в символах, а в байтах. При этом, в зависимости от кодировки со стороны БД, размер символа в байтах может занимать N-е число байт.

Полезняшки. С чего мы начинаем приложение в Delphi

Суть заметки в двух словах: организация dpr-файла и вынос мозга инициализации приложения в DataModule.

Эту заметку не стоит рассматривать как единственно верный вариант. Просто я хочу поделиться опытом. Я расскажу, как делаю я и как это делается у нас. Ничего особенного. Но самостоятельно к этому приходят не все и не сразу. А делаю я так, потому что описанный ниже подход облегчает сопровождение проектов (особенно, когда их несколько, и все они потихоньку разрастаются).

Полезняшки. Ссылки на модули, “помогающие” нашему приложению, выносим в отдельный модуль

Не секрет, что друзья не растут в о.. что для корректного функционирования некоторых модулей, их упоминание в uses должно быть как можно раньше. Такие как: менеджер памяти, логгер исключений и другие полезности. Обычно их помещают в uses файла проекта (в dpr-файл). И (ну у меня – как правило) необходимость использования той, или иной фичи может регулироваться дефайнами {$ifdef}.

Но есть одна особенность: dpr-файл генерируется и обновляется средой Delphi. И если разместить {$ifdef} в uses dpr-файла, то такой {$ifdef} может пропасть.

Визард для Delphi? Вопросик читателям…

Есть такой замечательный редактор – Notepad++. Я его использую почти каждый день для редактирования всяких файлов, связанных с нашими проектами, но не используемые непосредственно в IDE. Ну там sql, xml, txt, cmd, bat, makefile и прочие. Конечно эти файлы можно открывать и в Delphi, но там подсветка синтаксиса для xml-файлов более скудная, а остальные и не подсвечивает вовсе.

И захотелось мне вдруг внедрить в делфи такой редактор. Для начала – хотя бы просто в отдельный проект. В будущем, возможно, как некий визард для IDE. (Да, про SynEdit и TSynMemo я знаю.)

FM: Camera Test v2

Вот и у меня получилось установить Delphi XE5 и запустить из Delphi-приложение на планшете с Android’ом. Погоняв тестовые проекты, решил пересобрать свои старые из Delphi XE2…

Полезняшки. Переход к FocusControl при клике на TLabel

У TLabel есть такая полезная особенность. Если в Caption добавить символ амперсанда (&), то следующая за этим символом буква становится ускорителем. При этом, при прорисовке заголовка, сам символ скрывается, а буква-ускоритель – подчёркивается. Это означает, что если нажать Alt + <буква>, то произойдёт установка фокуса ввода в контрол, на который ссылается свойство TLabel.FocusControl. Произойдёт автоматически – это нормальное поведение для GUI в Windows.

"Халявы не будет!”

Навеяно Что бы сделали мы с Delphi XE5/XE6... - подводим итоги и забавными комментариями к посту Комната 3D, Delphi, Платформа приложений FM.

Размышляя о “халяве” в обучении, мне вспомнились школьные и студенческие годы. Вот по порядку. В школе нас учат писать буквы и цифры. Сначала рисуем палочки, потом кружочки/квадратики. А дома мы это повторяем-закрепляем. Бесплатно. Но тетради, карандаши, ручки – это нам покупали родители. Т.е. на самом деле и не бесплатно вовсе.

Вспоминаю уроки музыки – дома можно было бесплатно петь :). Но пластинки (ну такие, виниловые, ещё был проигрыватель специальный) нам не давали. Их можно было купить отдельно. Или не покупать и не заниматься дома.

Вспоминаю уроки ИЗО и труда. Дома тоже можно было бесплатно рисовать/лепить/вырезать/выпиливать... Но бумага, краски, пластилин, фанера – это всё покупалось. И пилки к лобзику бесплатно никто не давал.

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

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

В ВУЗе примерно тоже самое. Только иногда вместо учебников были методички. И касательно программирования – тоже. Компьютеры были далеко не у всех, поэтому преподаватели разрешали практиковаться в компьютерных классах после занятий. И это было нормально. Не думаю, что сейчас сильно всё поменялось (хотя учебники всё чаще нужно покупать).

Это я всё к тому, что Delphi – инструмент платный, но в этом нет ничего такого… ни плохого, ни хорошего. Это нормально. Хочешь владеть инструментом – покупай и практикуйся. Не хочешь – хватит и занятий в ВУЗе.

Другой вопрос о ценовой политике… Ну и о учебных материалах к новым технологиям…

 

P.S.: да простят меня читатели за пустой трёп…

Мысли по поводу локализации строк и кодогенерации

Кратенько, в стиле Александра Люлина. Два момента:

а) мне понравилась идея Александра с локализацией, типа

type TLocString = record Key, Value: string; end;

и далее:

var SAskDelete = (Key: 'AskDelete'; Value: 'Удалить?');

и далее:

  if Ask(SAskDelete.Value) then

С одной стороны это удобно, я прям в коде вижу:
  - и переменную
  - и Key
  - и Value по-умолчанию
Но:
  - не очень удобно объявлять такие переменные
  - не очень удобно (и не наглядно) писать ".Value"
Ссылка на идею: (18-ть лет с Delphi - Что ещё умеет наш фреймворк?)

б) у нас используется такой вариант: все строковые переменные объявлены как обычно:

var SAskDelete: string;

инициализируются они (и реагируют на смену языка) в спец. примерно так:

procedure InitResStrings;
begin
  SAskDelete := ResGet('AskDelete', 'Удалить?');
end;

и конечно эта процедура подписывается на обновления

initialization
  ResReg(@InitResStrings);

Вот и мы перешли на Юникод

Однажды, наверное как и у многих, у меня возникло дикое желание перевести проекты в нашей компании на юникодную версию Delphi. Перевести с Delphi 7. Конечно же можно было оставить всё как есть, “оно же работает!”. Тем более у нас повсеместно использовались Tnt-компоненты, и Юникод в приложении уже был. Но как человек, который любит свою работу, мне было просто дико осознавать, что мы до сих пор используем то, что есть под рукой и не обновляем свой инструментарий.

Сложность вопроса ещё состояла в том, что проект у нас довольно большой – несколько приложений с общей кодовой базой более 1000 pas-файлов (сейчас это 332 pas-модуля + 812 экранных форм и фрейм, т.е. пар pas + dfm файлов). Это не считая сторонних библиотек и компонентов. Но время потихоньку бежит, часть компонентов перестаёт поддерживать старые версии Delphi, а в новых версиях Delphi появляются всякие полезняшки… одни дженерики чего стоят. И инлайны мне по душе. И много прочих мелочей.

Я уже плохо помню весь процесс перевода. И он оказался совсем не простым. Более того, он был у меня в два захода – сначала это была Delphi 2009 – я добился успешной компиляции приложений и местами даже их нормальной работы. Но это было внепланово, по выходным и в своё свободное время. На том первый этап и заглох.

И вот в прошлом году наконец-то дали добро плановому переходу. Здесь я уже выбрал Delphi 2010, как проверенный и не слишком навороченный нововведениями инструмент… но, постараюсь, по порядку.

VCL Form and Frame Scale Fix

В продолжение развитии темы базовой формы и фреймы. Хорошая новость: я решил добавить поддержку Delphi 7, которая оказалась довольно живучей. Ещё я сделал разделение пакета на два: DesignTime only (пакет с визардами) и RunTime only (пакет с модулем BaseForms). Плюс я хочу поделиться решением одной насущной проблемы…

Многие Delphi-программисты знают, что в VCL происходит некорректное масштабирование форм. Само масштабирование применяется в случае, когда текущее логическое разрешение экрана (значение Screen.PixelsPerInch) не совпадает с тем, при котором разрабатывалась форма в дизайнере (значение PixelsPerInch, сохранённое в DFM-файле). Некорректность заключается в том, что в некоторых случаях масштабирование не применяется к размеру самой формы, но применяется ко всем дочерним контролам. Также не масштабируются констрейнты формы, что приводит к ещё более некрасивым результатам – сначала форма масштабируется, а потом её размер ограничивается старыми констрейнтами.

А ещё VCL не масштабирует фреймы. Т.е. если фрейму создать в Run-Time вручную, а после этого встроить в форму, то фрейма останется неотмасштабированной.

Form Events, события формы для работы с пользовательскими данными

Маленькие дети – это прекрасно. Но очень хлопотно… Эта заметка планировалась очень короткой, и без неё я пока не хочу продолжать развивать идею базовых формы и фреймы.

Итак, сделаем довольно простую вещь. Создадим приложение, которое наглядно проиллюстрирует, как правильно работать с формой в VCL. В частности, как правильно использовать обработчики событий OnCreate, OnShow, OnHide, OnClose и OnDestroy. Тут мысль простая – чтобы понять, какой обработчик использовать OnHide или OnClose (или какой-то другой) – нужно знать, в каком порядке и в каких случаях эти события происходят.

Как я стал программистом

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

Наполняем базовую форму полезным кодом

Предыдущие заметки по теме: номер раз, номер два.

Для начала я наполню базовую форму довольно простыми, но полезными вещами. Это будут обработчики сообщений, а потому нам не нужно будет переустанавливать пакет с визардом. Затем добавлю пару published-свойств, и, переустановив пакет, мы эти свойства увидим в инспекторе объектов.

Создание базовой формы

Данная заметка является продолжением предыдущей.

Вступительное слово

Я решил не писать отдельную статью. Вместо этого я буду проделывать задуманную работу по маленьким этапам, каждый из которых выкладывать в репозиторий на github.

А Вы ещё не используете базовую форму и базовую фрейму в своих Delphi-проектах?

В этой заметке я хочу рассказать о базовой форме и базовой фрейме. Что это такое, и зачем это нужно. Под словом “базовая” я подразумеваю, что любая форма/фрейма в проекте является наследником TMyBaseForm/TMyBaseFrame, а не стандартных TForm/TFrame. Т.е. слово “базовая” никакого отношения к базам данных не имеет; в своих проектах, при создании новых форм и фрейм, я всегда наследуюсь от базовых.