Delphi XE5: впечатления от разработки под Android

Отправил свою программу на конкурс. Саму программу показывать пока не хочу. А хочу поделиться своими впечатлениями от использования Delphi XE5 и Firemonkey.

 

Сразу оговорюсь

• Это мой первый проект на Firemonkey и первый опыт разработки для Android.
• Я использовал Delphi XE5 + Update 1 + все хотфиксы для Update 1.
• Тестировал только на телефоне GSmart Aku A1 (480 x 854 pixels, 4.5 inches (~218 ppi). Эмуляторы не использовал.
• Часто компилировал и запускал на Win32 в режиме Mobile Preview (об этом ниже).
• В этом проекте решил опробовать подход "как-мне-кажется-это-делают-в-java", когда и для каждого класса создавал отдельный .pas файл. В результате получилась куча юнитов и чтобы в них не запутаться пришлось раскидать их по папкам и пространствам имён. Получилось в принципе удобно. Хотя есть у меня подозрение, что сборка проекта под Android из-за этого работал медленнее, чем в случае, если бы весь код был запихан в один .pas файл.

Грабли

Deployment manager и папки

Deployment manager и папки. С этим тоже пришлось повозиться прежде чем удалось понять какие надо указывать пути в Deployment manager и как потом найти эти файлы в программе. Пришлось провести небольшое исследование. О нём напишу позже, в отдельном посте. Вот только так и не понял, как же из приложения определить путь до корня SdCard. Также не понравился UI в Deployment manager-e. Редактирование пары десятков файлов сделано не очень удобно, хотя к слову сказать просто добавить пачку файлов довольно легко.

Сразу уточню, что я хотел недокументированного. Искал легкий способ добавления/редактирования файлов в Deployment manager из консоли. Не получилось, так файлы добавленные через Deployment manager поначалу сохраняются в .dproj файле, хотя в папке проекта и присутствует отдельный файл .deployproj. И я так и не понял в какой момент файлы переносятся из .dproj в .deployproj файл. Вот кстати наткнулся на пост о похожем исследовании от Павла Алхимова “DeployFolder - Развёртывание мобильного подкаталога”.

Читать дальше..

Текучка 13: “шаманский метод Гео” + RegisterClass = EFilerError

Я тут наткнулся на ошибку, появившуюся вследствии использования "Шаманского метода Гео". Уже второй раз натыкаюсь на неё и второй раз удивляюсь тому, откуда она взялась.

Симптомы ошибки

При вызове процедуры RegisterClass для класса появлется исключение EFilerError с текстом ошибки: “A class named XXX already exists”.

Расследование показало что эта ошибка появляется, если RegisterClass был вызван дважды для разных классов с одним и тем же названием.

Казалось бы, причём тут метод Гео?

А вот при том, что именно из-за подмены одного класса другим у меня в коде и возникла ситуация вызвавшая ошибку. В частности, я использую “метод Гео” для подмены стандартного TDbGrid-a своим наследником от TDbGridEh. Для работы моей программы (crm системы) мне необходимо зарегистрировать свой DbGrid. Так что при старте программы я спокойно регистрирую свой класс. А после получаю вышеупомяную ошибку при вызове одного из методов одной из сторонних библиотек, которой также необходимо зарегистрировать класс TDbGrid.

Пример кода вызывающего ошибку:

Читать дальше..

Чего не хватает в Delphi

Публикация для конкурса проводимого агрегатором Delphi новостей DelphiFeeds.ru.

Интеграция с SVN

Я говорю не просто о добавлении комманд Update/Commit в какие либо меню. Всё это возможно и в варианте интеграции SVN в Delphi для бедных. Я говорю о широкой визуальной поддержке. Чтобы на Tab-ах редактора и в дереве проекта отображался значок как в TortoiseSVN.

Чтобы изменённые строки в исходниках подсвечивались другим цветом.

Мне понравилось, как сделана интеграция SVN в NetBeans.

SVN команды доступны в отдельном субменю при правом клике как на файле в дереве так по заголовку таба в редакторе.

Читать дальше..

Текучка 12: Велосипед для езды по минному полю. Или почему не стоит вешать обработчики Application.On...

Это история о том, как один программист, начал изобретать групповой делегат (multicast delegate) для обработки события Application.OnMessage, не зная о том, что подобный класс включён в стандартную поставку Delphi.

Одному программисту понадобилось сделать так, чтобы одна из форм обрабатывала событие Application.OnMessage. Программист не раз встречал подобный код у себя в библиотеках. Обычно это делалось так:

• в секции юнита initialization, запоминался старый обработчик события
• затем вешался свой обработчик события, который после выполнения своих операций вызывал запомненный старый обработчик
• а восстанавливалась цепочка, как правило, в секции finalization

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

Читать дальше..

Текучка 11: Поиск AV в полевых условиях и найденная в результате цепочка ужасного кода.

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

Звонит коллега: я у клиента, поставил обновление, и последний билд не запускается на 3х компах из 10. При старте программы вылетает сообщение об ошибке по адресу 0x0000L0L0. А очень старый билд запускается без проблем. Подключись пожалуйста удалённо, говорит, и посмотри в чём может быть дело.

Читать дальше..

А Вы хорошо знаете календарь в Windows?

Меня по работе несколько раз просили заменить стандартный TDateTimePicker на RxLib-овский, потому в стандартном якобы неудобно менять год. Как оказалось, просившие не знали об одном свойстве стандартного календаря.

Знаете ли вы, что если кликнуть по заголовку календаря, там где год и месяц, то календарь позволит выбрать месяц. А если кликнуть ещё раз, то можно будет выбрать год из текущего десятилетия. А если ещё раз, то можно будет выбрать десятилетие, при этом стрелки сверху будут менять столетия. Проверял в Windows XP и Vista.

То же самое будет если нажать Ctrl + стрелка вверх/вниз.

А ещё, TDateTimePicker не позволяет выбрать дату до 14 сентября 1752 года. А вот компонент TjvDateEdit из бесплатной библиотеки JVCL такого ограничения не имеет.

Читать дальше..

Вирус отакуе Delphi программистов!

 

Вирус, photo by twenty_questions

Gunsmoker сегодня сообщил о вирусе, заражающем установленную Delphi и распространяющим себя через скомпилированные программы. Известно, что в интернете гуляли заражённые версия Qip и Aimp.

Вирус делает 2 вещи: размножается и иногда глючит. Собственно по глюкам его и нашли. Вирус заражает версии Delphi с 4й по 7ю, и при активации перезаписывает собой файл sysconst.dcu, сохраняя оригинальный файл с именем sysconst.dcu.bak.

Подробное описание этого вируса, алгоритма его действия и способа лечения можно найти в блоге GunSmoker-a.

Сама по себе эта разновидность вируса не опасна. Его легко найти и исправить. Однако этот вирус демонстрирует жизнеспособность такого способа заражения, и уязвимость установленной Delphi.

Мне “повезло” обнаружить этот “вирус” в своей инсталляции Delphi 6 и Delphi 7. Причём дата модификации у одного из sysconst.dcu.bak был январь 2008 года.

После этого я задумался, о том, что необходимо как-то защитить Delphi и исходники. Большое везение, что этот вирус оказался довольно безобидным. Однако, возможно появятся (или уже есть) и другие, которые не столь явно себя проявляют.

Читать дальше..

TortoiseSVN работает на порядок медленнее чем консольный клиент

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

Надо сказать, в качестве клиента svn я использую TortoiseSVN (версию 1.6.2).

При добавлении файлов, TortoiseSVN подвис минут на 10, после чего наконец выдал диалог со списком файлов. При попытке сделать коммит, он тяжело работал минут 50, ощутимо загружая процессор, после чего выдал сообщение об ошибке и вылетел.

Иконок не то, чтобы мало – 30 тысяч файлов. И коммитил я их, частями. Но, так или иначе, выглядела эта идея удручающе. И решил я попробовать сделать тоже самое через консольный клиент (svn.exe). Я скачал и установил сборку SlikSVN,  и запустил коммит. К несказанному удивлению, консольная версия сделала всю работу минут за 10.

Вывод: иногда гуёвые программы и работают соответствующе.

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

Читать дальше..

Итоги недели: первый шаг к созданию команды

Вопрос о том, работают ли Delphi программисты в команде волнует меня давно. И если работают то как? Причина в том, что во всех местах где мне доводилось работать, Delphi программисты работали поодиночке. Каждый над своим проектом. Максимум – один из программистов заведовал общей библиотекой компонентов.

На текущей моей работе точно такая же ситуация. Все программисты находятся в одной комнате, но каждый работает над своим проектом и даже не в курсе того, какие проблемы решает его сосед. Более того, все проекты когда-то были основаны на одном и том же базовом коде, но этот код просто копировался между проектами. В результате сейчас мы пришли к тому, что в каждом проекте этот код немного (иногда даже сильно) отличается. Типичная ситуация в духе worse than failure.

Читать дальше..

О переходе крупного проекта на Delphi 2009(перевод)

Перевод статьи: “Upgrading a major project to Delphi 2009”,  Lars B. Dybdahl.

Вот и закончен перевод на Delphi 2009 крупного проекта, который в течении нескольких лет разрабатывался довольно большой командой программистов. Теперь я готов поделиться опытом.

Если Вы хотите оценить объём работ, которые потребуется для конвертации проекта, примите во внимание, что объём строк в проекте не является таким уж и значимым показателем. Более важно, какой код у Вас есть, насколько он сегментирован, и насколько согласованно написаны сегменты. Вещи относящиеся к пользовательскому интерфейсу, бизнес логике и т.п. очень легко конвертировать. Я бы даже сказал, что достаточно просто перекомпилировать и запустить. А вот с другими частями, всё будет не так просто.

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

Читать дальше..

Текучка 10: Что может случиться если сначала обнулять переменную, а потом вызывать деструктор.

Прочитал на днях пост GunSmoker-a о том, что всегда нужно использовать FreeAndNil вместо Free. Прочитал, подивился, взял на заметку попробовать завести такую привычку, хотя так и не смог придумать объяснения, кроме как: а почему бы и нет?

И вот бывает же! Как раз сегодня наткнулся на ситуацию, когда из деструктора объекта происходило обращение к самому объекту по имени переменной. Конечно обращение происходило не из самого объекта, а из одного из вложенных. Кстати, дело было в коде Lazy Delphi Builder.=) Из-за частых изменений в иерархии классов, и постоянной работе над проектом в режиме “скорей бы уже релиз выпустить” у меня там развёлся довольно милый бардачок, с большим количеством глобальных переменных.

Итак..

Читать дальше..

Кое-что о dcc32

Началось всё с того, что ctapmex сообщил об ошибке, найденной в последней альфе билд-машины Lazy Delphi Builder. Суть ошибки сводилась к тому, что после компиляции, в папках с исходниками оставались dcu. Причём, некоторые dcu-файлы всё-таки попадали в нужную папку. Почти неделю я проковырялся с этой ошибкой пытаясь понять причину и найти способ их исправить. В результате узнал кое-что новое о работе компилятора командной строки dcc32.exe.

Условия возникновения ошибки в Lazy Delphi Builder.

Есть следующие файлы:

D:\Dummy\Test1.dpk
D:\Dummy\Test1.RES
D:\Dummy\TestUnit1.pas
D:\Dummy\TestUnit2.pas
D:\Dummy\Source\TestUnit3.pas

Если скомпилировать package Test1.dpk, указав в качестве папки для dcu, папку D:\Dummy\Build\dcu, то все файлы.dcu остаются рядом с соответствующими файлами.pas.

Но, при этом, если вместо D:\Dummy\Build\dcu указать папку D:\Dummy\dcu, то все файлы.dcu оказываются там где нужно.

При этом, если вместо D:\Dummy\ использовать папку с более длинным именем, например D:\DummyTest\Build\dcu то всё работает как надо.

Отладка осложнялась тем, что Lazy Delphi Builder при запуске dcc32 пытается всеми правдами сократить длину полной команды, преобразуя все используемые пути в относительные и укороченные. Причина такого поведение – баг в dcc32.exe, когда в случае, когда длина командной строки превышает критическую, dcc32 начинает выбрасывать невразумительные сообщения типа System.pas not found, или даже AV. Мне не удалось сейчас найти упоминания об этом в интернете, хотя я точно его видел раньше(и даже сталкивался с ним сам) поэтому я просто приведу комментарий из JclBorlandTools.pas:

Читать дальше..

История в духе worse than failure. О “пирамиде” по продаже GPL-кода.

Как-то Ник написал программу для записи видео с экрана. Не то, чтобы с нуля написал, но вот уже как 6 лет Ник поддерживает программу, добавляя новый функционал, исправляя баги, обновляя сайт и выкладывая свежие билды. Подробности того как начиналась история этой программы понят только старики(ходят слухи, что изначально разработкой программы занималась компания RoboScreen, которую поглотила Macromedia). А сейчас поддержкой и развитием программы официально занимается Ник.

И программа у него получилась удобной, с понятным интерфейсом, стабильной и бесплатной. И вполне себе конкурирует с коммерческими аналогами. Ну что ещё для счастья гику надо? Разве чтобы исходный код был открытым и был написан хорошо. Код у Ника просто отличный и распространялись по лицензии GNU General Public License,

Программа называется CamStudio. И на данный момент, это самая простая и удобная из бесплатных программ умеющих записывать происходящее на экране вместе со звуком и сохранять в avi-файлы.

Читать дальше..

The procedure entry point @UnitName@initialization$ProcName could not be located in the dynamic link library Package.bpl.

Экспериментируя с разными версиями JCL и JVCL столкнулся с ошибкой:

CodeGear RAD Studio for Microsoft Windows [Loading JclVersionControlExpert120.bpl]: bds.exe - Entry Point Not Found
---------------------------
The procedure entry point @Jclversioncontrol@initialization$qqrv could not be located in the dynamic link library JclVcl120.bpl.

Причина появления этой ошибки банальна и трудноуловима. В моём случае, проблема была в том, что пакеты Jcl дублировались. Когда–то я установил JCL с настройками по умолчанию, и установщик скинул все bpl-ки в папку:
C:\Users\Public\Documents\RAD Studio\6.0\Bpl\

Потом не деинсталлировав старую версию, я переустановил JCL, указав папкой для Bpl
D:\Work\D2009\!Build\Bpl\

В результате получилось, что пакеты Jcl*.bpl дублировались. При этом в папке C:\Users\Public\Documents\RAD Studio\6.0\Bpl\ была установлена сентябрьская версия, а в D:\Work\D2009\!Build\Bpl\ – последняя нестабильная версия из trunka. И всё работало без видимых проблем. Работало до тех пор, пока в JCL не изменили список юнитов пакета JclVcl, перенеся пару юнитов из пакета JclVersionControlExpert.dpk в JclVcl.dpk. И после того как я установил обновлённую версию, Delphi начали выдавать при старте эту ошибку.

Я настолько был уверен в том, что все bpl-ки у меня лежат только в папке D:\Work\D2009\!Build\Bpl\ что мне даже в голову не пришла мысль проверить это. В результате потратил кучу времени на поиск ревизии в которой появилась “проблема”, и убрал эти изменения. И уверенный в том, что проверил всё, зарегистрировал ошибку в баг-трекере Jedi. Там ответили, что повторить эту ошибку не удалось. Так что я решил ещё раз всё тщательно перепроверить, и, вуаля, нашёл дубликаты.

Надеюсь, этот пост послужит напоминанием тому, что при появлении ошибки Entry Point Not Found, первым делом необходимо проверить компьютер на дублирующиеся bpl в папках входящих в %path%. Потому что я встречаюсь с этой ошибкой уже не первый раз, и каждый раз забываю об этом.

Читать дальше..

Мысли навеянные Delphi-кодингом 2. JCL+JVCL.

Недавно мне нужно было написать по учёбе пару программок.

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

Кстати, тот же Lazy Delphi Builder не состоялся бы без JCL. 

А у TJvDbGrid есть вкусное свойство, позволяющее назначать каждой колонке свой редактор.

Это о плюсах свободных библиотек.

А теперь о минусах.

Читать дальше..

Текучка 7: dcc32 и dpk c полным путём

Экспериментировал с относительными путями в LazyDelphiBuilder и столкнулся с тем, что dcc32 умеет компилировать только package-и, которые находятся в текущей папке.

К примеру, попытка выполнить команду из d:\

d:\> "C:\Program Files\CodeGear\RAD Studio\6.0\bin\dcc32.exe" "D:\Work\D2009\VCL\TB2K\Packages\tb2k_d12.dpk" -U"c:\PROGRA~1\codegear\RADSTU~1\6.0\lib";"d:\Work\D2009\VCL\TB2K\Source" -LN"d:\test\dcp" -LE"d:\test\bpl" -N"d:\test\dcu" -DRELEASE -N0"d:\test\dcu"

приводит к появлению сообщения об ошибке “Fatal: file not found первый файл в dpk”. Такая же ерунда происходит при компиляции VirtualTreeView.

А если перед выполнением команды сменить текущую папку на D:\Work\D2009\VCL\TB2K\Packages\ – то всё отработает как надо.

Столкнулся с этим почти месяц назад, но только сейчас, начав писать  пост до меня наконец дошло, что причина не в dcc32 а в том, что в tb2k_d12.dpk указаны относительные пути до исходников.

contains
TB2Version in '..\Source\TB2Version.pas',
TB2Toolbar in '..\Source\TB2Toolbar.pas',
…

В VirtualTreeView тоже самое.

p.s. Давно заметил, что хорошие идеи приходят при обсуждении. Даже если собеседник не успел вставить ни слова. =)

Читать дальше..

on E:EDatabaseError do not raise E! Ключ - просто raise

Только что пытался реализовать в Delphi 6 конструкцию:

procedure _ExecuteQuery(aQuery:TpFIBQuery; aExceptionText:string='');
begin
  try
    aQuery.ExecQuery;
  except
    on E:EDatabaseError do
    begin
      E.Message := aExceptionText + E.Message;
      raise E;
    end;
  end; // я так понимаю, E.destroy происходит здесь?
end;

И ничего хорошего не получилось. Общий обработчик Application.OnException начал получать пустое исключение с E.Message = ‘’. Начал писать вопрос на Vingrad Forum. Пока писал, вспомнил, что для перевозбуждения последнего исключения не обязательно явно указывать это исключение. Попробовал вместо “raise E;” вызвать просто “raise;” - всё заработало.

Я так понимаю что деструктор исключения вызывается в конце блока except .. end.

Ссылка по теме:

• Handling exceptions in Delphi
  
• Александр Алексеев - Обработка ошибок
  

Читать дальше..

Текучка 6. Delphi 2009 + FastMM4.9 + я = странный баг.

Я использую в своих проектах FastMM. При этом я не хочу добавлять путь до FastMM4.pas в Library Path, чтобы не мучиться при отладке. Для этого я создал фиктивный package FastMM.dpk(runonly), который включает в себя тольк Fastmm4.dpk и компилирую FastMM со всеми остальными package-ами. А проекты подключают к себе уже fastmm4.dcu. Но в Delphi 2009 эта схема перестала работать. При включении FastMM4.dcu в проект, Delphi начинает ругаться и обзывать меня обидным заморским прозвищем "[DCC Fatal Error] F2051 Unit FastMM4 was compiled with a different version of System.TObject.InstanceSize". Причём, ругается он только если я собираю проект с Debug Build Configuration. С Release всё собирается нормально. К слову сказать, ошибка “Unit бла-бла was compiled with a different version of бла-бла-бла” – одна из моих самых нелюбимых ошибок.

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

Выяснилось, что проблема возникает, когда проект использует $(BDS)\Lib\Debug\ вместо $(BDS)\Lib\

А LazyDelphiBuilder, с помощью которого я и пересобираю все проекты, самой первой папкой для поиска исходников файлов всегда указывает $(BDS)\Lib\

С другими package-ами эту проблему повторить не получилось.

Получается, что System.TObject.InstanceSize в $(BDS)\Lib\ и $(BDS)\Lib\Debug разные.

Версия Дельфи: CodeGear™ Delphi® 2009  Version 12.0.3170.16989
Версия FastMM: Fast Memory Manager 4.90

Думаю, то ли разработчику FastMM написать, то ли в Quality Central, то ли вообще не заморачиваться и вписать путь до Fastmm4.pas в Library Path. А может не лениться и выяснить, откуда берётся $(BDS)\Lib\ в LazyDelphiBuilder-е?.. ;)

Update: Решил проблему созданием отдельных dcu файлов с отладочной информацией..

---

• А вы знаете, сколько стоит отдать на аутсорсинг сопровождение 20 офисных компьютеров, 5 серверов и двух рабочих мест 1C? А я знаю. Тем более что цену ИТ аутсорсинга можно легко рассчитать на калькуляторе цен прямо на сайте аутсорсера.

Читать дальше..

Текучка 4

Сначала о первой бете Lazy Delphi Builder. Там есть несколько недоработок и багов.

1. Неверно определяется папка по умолчанию для Binary Output Folder. В качестве папки по умолчанию берётся папка Bin текущей инсталляции Delphi. Это в корне неверное значение, и эту папку надо обязательно изменить на какую-нибудь другую.
2. Для того чтобы всё работало, необходимо указать выходные папки для всех типов файлов.

Появилась надобность разобраться с технологиями доступа к Oracle-у из Delphi. Вот бы почитать какие-нибудь сравнения-тесты.

Предыдущую проблему с автоматизацией выявления пишущих select-ов в программе решил примерно так:

1. Извлёк из базы скрипт создания всех хранимых процедур.
2. Добавил в начало каждой процедуры вызов insert в тестовую таблицу(поиск по регулярным выражениям рулит:] ).
3. Пересоздал эти процедуры в базе(команда Create or Alter рулит:]). И получил в результате базу в которой все процедуры стали пишущими.
4. Потом пришлось помучится пару часиков, чтобы приложение вообще начало запускаться. Зато потом, легко выявил все места, где Select из процедур происходит в read-only транзакции.

Читать дальше..

текучка 2. Бывают Select-ы, которые нужно выполнять в рамках пишущей транзакции.

Обнаружилась проблема в “успешно переведённым” с BDE на FIBPlus проекте. Переводил я тогда так:

1. На главном Datamodule я создал 2 транзакции, trMainRead(read-only) и trMainWrite(read/write).
2. У всех FIBDataset-ов выставил читающей транзакцией trMainRead, а пишущей trMainWrite, а также свойства AutoStartTransaction и AutoCommit.

Не было печали, пока не выяснилось, что для отображения некоторых отчётов используются Select-ы из хранимых процедур, а процедуры эти, в свою очередь, могут сохранять промежуточные расчёты в других таблицах. И эти отчёты начинают ругаться, когда их пытаются открыть в read-only транзакции. Теперь надо как-то искать места где происходит select из процедур, и добавлять туда отдельную пишущую транзакцию.

500 хранимых процедур, 71 форма, 37 тыщ строк кода. Проект старый и чужой и большая часть кода мне незнакома.

Вот бы как-нибудь, этот процесс автоматизировать.

p.s. Решение проблемы с Select-ами.

Читать дальше..