brunnengi

Заходим в меню "Run -> Parameters:Parameters", прописываем "-cleaninstall"(без кавычек).

Полноценная поддержка SplashScreen для андроида реализована в RAD Studio XE7. Задать экран заставки можно через настройки проекта.

В XE7 появилась функция задания заставки приложения для андроид устройств. Если раньше пользователям приходилось создавать свои решения этой задачи (Как создать заставку для андроид приложения?), то теперь заставку можно легко указать в настройках проекта:

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

Для начала Вам необходимо получить Application.Handle Стандартными средствами это не возможно. Как это осуществить описано здесь
 
После выполнения действий, перечисленных выше:
ShowWindow(ApplicationHWND, SW_SHOW); // Показать ShowWindow(ApplicationHWND, SW_HIDE); // Скрыть

Добрый день,
 
Два варианта:
Как я могу скрыть / показать клавиатуру под "Android"? Сбросить фокус
Edit.ResetFocus

Все контролы, которые вы кидаете в TScrollBox находятся в дополнительном промежуточном контроле TScrollContent. Когда вы удаляете все дочерние узлы TScrollBox, то вы удаляете все сами, стиль и контент, что делать нельзя.
Похожее поведение есть и в TTreeView: При попытке создать дочерние итемы при разворачивании узла дерева, у меня возникает ошибка. В чем может быть проблема?
Поэтому, удалять объекты нужно непосредственно у контента. Это можно сделать так:
type TOpenScrollBox = class(TScrollBox); procedure ClearChildren(AScrollBox: TScrollBox); begin Assert(AScrollBox <> nil); TOpenScrollBox(AScrollBox).Content.DeleteChildren; AScrollBox.Repaint; end;

А почему бы и нет?
Есть какое то личное не доверие к программам на FMX?
Выбирал FMX потому что уже давно работал на компонентах DanJetX. Но он был только под D7. И сами проект был заброшен разработчиком.
Я давно делаю приложения с 3D моделями и 2D эффектами. Но возможности DanJetX не безграничны. И тут FMX появилась. Я лично только рад был их расширению.
А с помощью анимаций, layout'ов и т.д. разрабатывается удобный и понятный интерфейс. Переход с VCL версии на FMX позволило значительно ускорит работу кассиров. А так же убрать (не снизить, а убрать) количество ошибок при работе, что избавило кассиров от необходимости докладывать свои деньги. Удобный, понятный интерфейс, с приятной анимацией, с боковыми панельками, адаптивными меню позволяет делать работу с программой более понятной, прозрачной.
 
А что касается выбора FMX для терминалов, я просто привык к FMX. Разрабатывать в нем удобнее и приятнее чем в VCL. То что я делал в VCL по несколько недель, теперь в FMX делается за одну-две недели (я про визуальную часть). Да и не вести же мне одну версию в FMX, а другую в VCL. А сейчас вот АппТетринг прикручивать буду с терминальной версии. Ибо удобно не открывая сам терминал управлять им, получать информацию о ленте и т.д., т.е. небольшая помощь при инкассациях и обслуживании.

Может быть, вам попробовать использовать компонент TClearingEdit?
Стиль, который вы пытаетесь использовать предназначен именно для этого компонента.

Yaroslav, извините, забыл сказать "спасибо". 
Спасибо за помощь! )

procedure TForm1.FormCreate(Sender: TObject); begin   ScrollBox.AniCalculations.Animation := True;   ScrollBox.AniCalculations.BoundsAnimation := True;   ScrollBox.AniCalculations.TouchTracking := [ttVertical, ttHorizontal]; end;

Такое ощущение что программисты всегда оторваны от реальных пользователей!
На всех предприятиях нашего города стоит именно ВинХР. В кафе, в ресторанах, в терминалах, в аптеках, больницах, в школах, в администрации, на рабочих ноутбуках, в библиотеках, и даже в офисах ростелекома. И этому есть много причин. 
Во-первых ВинХР для многих задач более чем достаточна. И переходить на новые оси смысла нет. 
Не забывайте что ВинХР вышел уже как 13 лет назад. А значит и компы на которых она стоит не такие уж и новые. А значит переход на новые ОСи связан с затратами на замену оборудования. И вы должны понимать что поменять что то одно в системном блоке даже 5-ти летней давности не вариант. Почти всегда приходится брать все железо новое, т.е. новый комп. Да, Вин8 не такая дорогая. Но компаниям и тем более гос учреждением заменить все железо и поставит новую ОС почти не вариант, ведь в отчетах нужны мотивации,  а их нет, ибо и так "всё работает".
Мало этих причин?
Поехали дальше.
Кассовые аппараты. Многие из них не имеет драйверов под новые ОСи. Есть кассы которые пашут на USB через эмулятор COM порта. Но нет драйверов на Вин8 для эмуляции COM порта! 
Мало? Держите еще.
Великая и могучая 1С. Она стоит почти в любом УГ предприятии, и у многих (внимание ща вы будете шокированы) стоит все еще версия 7,7! Ибо переход на 8 версию сопряжен как с затратами на программистов которые берут ой как не мало денег за это, та еще и простоями на предприятии, что тоже влечет финансовые потери. А значит никто не будет сносить 1С 7,7 которая стоит на ВинХР, ради мнимой выгода перехода на Вин8.
Мало? Вот еще.
Банковские программы (ДБО которые) у многих банков идет только на ВинХР! Более того, даже те кто использует Java сталкиваются с тем что Java машину нельзя обновить. Ибо в новых версиях исправлены баги с безопасностью. И как следствие старые версии ДБО не запускаются! Сами разработчики ДБО (есть компании которые разрабатывают ДБО, и банки покупают у них) выпускают новые версии, но банки не покупают обновки ибо "и так все работает", и клиенты и так проживут.
И конечно же не сметное количество терминалов оп всей стране. Многие думают что платежные терминалы приносят кучу денег (так и было на заре расцвета бизнеса), но в реалях это не так. Часть дохода съедает плата за аренду, ремонт железа, замена сенсорных стекол, мониторов, купурников (хороший купюрник стоит от 25.000 руб), бензин (инкассировать надо, менять чековую ленту надо), ЭКЛЗ от 7000 в год + ежемесячное обслуживание. Так что и для терминальщиков переход на новые оси с заменой железа не выход.
Так что писать о том что всем надо переходить на Вин8, а затем на Вин9 не стоит.
Да они хороши. Да мне и самому очень нравится Вин8, но всетаки для большинства задач типа "офис" windows xp более чем достаточен.
 
Что касается сглаживания.
Как я понял, это зависит от железа и дров. Во первых SP3 должен быть это точно (на ниже чем sp3 вроде даже и не запускается), во-вторых все драва на видюху. Ну и конечно же сама видюха должна быть не самым УГ. 
Может я конечно и не прав и ты имеешь ввиду совсем другое сглаживание. Но похожая проблема была и у меня.
Я накидал круглый прогрессбар. Делал на Вин8. Все идеально. Потом перекинул exeшник на WinXP и - О! Кошмар! Круги были все с квадратиками. Вид ужасный. На компе стоял СП3, все дрова. Но видюха встроенная и не самая адекватная. Но потом запускал и на рабочем компе на ВинХР, и кассах нескольких и там все сглаженно (не так конечно как в Вин8, но вполне смотрибельно, а не так что аж глаза хочется выкинуть)

Первая версия AppMethod вышла между XE5 и XE6 и представляла собой XE5. Новая версия AppMethod, которая вышла в июне основывается на ХЕ6. В дальнейшем я думаю такая же практика будет продолжаться. Вначале релиз RAD Studio, а потом уже обновленная версия AppMethod.

Быстро решаемых проблем почти не бывает. Все проблемы приходится решать хоть какое то время.
Но ты либо начнешь писать на FMX проект либо вообще не сможешь действительно с ней работать.
Я тоже не раз хотел подступиться к FMX именно в плане перевести на него свои проекты с VCL.
И до версии ХЕ3 (ищи ХЕ4 не помню точно) откладывал это. А потом взял и перевел.
В первую очередь сыграло роль удобство разработки, которое стало комфортнее благодаря TLayout, DisignVisible, Lock.
За эти вещи разрабам прям большое спасибо!
Я думаю что если они это на VCL поставят, с VCL опять десять лет никто не пересядет))
Конечно есть лаги. Причем они бывают двух типов, лаги которые появляются из-за не знания как это делать именно в FMX, и второе, лаги самой FMX. Сверх критичных лагов с которым нельзя было ужиться почти нет. Просто иногда приходится из-за них отказаться от реализации какой то идеи именно "вот так".
Свой проект один я перевел с VCL на FMX. Второй пишу сразу на FMX. Потихоньку осваиваю мобильный вариант. 
По-сути в VCL за последние два года я делал только легкий сервер для работы с принтером. И то потому что поленился разбираться (и даже пытаться сделать на FMX), так как на VCL уже были наброски. Позже, когда времени будет побольше, тоже переведу.
И конечно выход AppMethod с чистым FMX и при его ценовой политике это конечно подарок для меня.
 
Словом, нельзя сказать что фреймфорк на все 100% стабилен. Это не так. Это факт, и не надо его смущаться и боятся. С чем то приходится мириться, что то обходить, а что то просто учиться делать как надо. Мой проект работает полностью стабильно. 
Стоит ли писать и поднимать проект на FMX? Как по мне, так да на 100%
 
P.S. Со sqlite я раньше работал через штатные средства, без FireDAC. Ибо первые варианты, работы FireDAC с SQLite были медленее чем тревиальный подход.  К тому же подключение FireDAC сразу занимало в оперативке от 45 до 200 МБ (на WinXp почти 200мб, на Win8 >45мб). Но в ХЕ5 и ХЕ6 работа с SQLite через FireDAC если не быстрее обычного варианта, то уж точно не медленее. Память больше не жрет.  Работа стабильнее. Кол-во ошибок при записи/чтение в базу через FireDAC на 1000,000 позиций 0, в то время как обычный от 2-30 (тесты делались на двух разных жестких дисках IDE, оба после неоднократного ремонта, одному 6 лет, другому >7, оба диска, все эти года жестко и активно эксплуатировались). 

Быстро решаемых проблем почти не бывает. Все проблемы приходится решать хоть какое то время.
Но ты либо начнешь писать на FMX проект либо вообще не сможешь действительно с ней работать.
Я тоже не раз хотел подступиться к FMX именно в плане перевести на него свои проекты с VCL.
И до версии ХЕ3 (ищи ХЕ4 не помню точно) откладывал это. А потом взял и перевел.
В первую очередь сыграло роль удобство разработки, которое стало комфортнее благодаря TLayout, DisignVisible, Lock.
За эти вещи разрабам прям большое спасибо!
Я думаю что если они это на VCL поставят, с VCL опять десять лет никто не пересядет))
Конечно есть лаги. Причем они бывают двух типов, лаги которые появляются из-за не знания как это делать именно в FMX, и второе, лаги самой FMX. Сверх критичных лагов с которым нельзя было ужиться почти нет. Просто иногда приходится из-за них отказаться от реализации какой то идеи именно "вот так".
Свой проект один я перевел с VCL на FMX. Второй пишу сразу на FMX. Потихоньку осваиваю мобильный вариант. 
По-сути в VCL за последние два года я делал только легкий сервер для работы с принтером. И то потому что поленился разбираться (и даже пытаться сделать на FMX), так как на VCL уже были наброски. Позже, когда времени будет побольше, тоже переведу.
И конечно выход AppMethod с чистым FMX и при его ценовой политике это конечно подарок для меня.
 
Словом, нельзя сказать что фреймфорк на все 100% стабилен. Это не так. Это факт, и не надо его смущаться и боятся. С чем то приходится мириться, что то обходить, а что то просто учиться делать как надо. Мой проект работает полностью стабильно. 
Стоит ли писать и поднимать проект на FMX? Как по мне, так да на 100%
 
P.S. Со sqlite я раньше работал через штатные средства, без FireDAC. Ибо первые варианты, работы FireDAC с SQLite были медленее чем тревиальный подход.  К тому же подключение FireDAC сразу занимало в оперативке от 45 до 200 МБ (на WinXp почти 200мб, на Win8 >45мб). Но в ХЕ5 и ХЕ6 работа с SQLite через FireDAC если не быстрее обычного варианта, то уж точно не медленее. Память больше не жрет.  Работа стабильнее. Кол-во ошибок при записи/чтение в базу через FireDAC на 1000,000 позиций 0, в то время как обычный от 2-30 (тесты делались на двух разных жестких дисках IDE, оба после неоднократного ремонта, одному 6 лет, другому >7, оба диска, все эти года жестко и активно эксплуатировались). 

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

Не за что.
Если что спрашивай. 
XML формат мне всегда был противен, хоть и понятен, но все равно внутренне я был против него и как следствие принципиально не использовал в своих программах.
Но вот формат JSON мне очень понравился. Его легко написать от руки, легко читать, даже через регулярки парситься легко, если приспичило. И он не избыточен как XML, а значит по канала связи передается меньше трафика.
 
Так что не бросай этот формат
 
И кстати, что касается утечек. Я когда сам только начинал разбираться в формате JSON и с тем как работать с ним в Delphi, у меня тоже были утечки, ибо я использовал JSON для парсинга ответа с сервера, в потоке. Я тогда начал склоняться к всеобщему мнению что просто сама реализация работы с этим форматом в делфи кривая. 
Но поколебавшись все таки принял во внимание ту мысль, что разработчики Embacadero на девять жизней умнее меня, и вряд ли они выпустили модуль с таким явным глюком. И решил все таки углубиться дальше.
Как оказалось просто поставить JS.Free в конце не достаточно.
Т.е. вот так вот делать не стоит:
var JS: TJSONObject; begin s := '{"jsonString":"ok"}; JS := TJSONObject.ParseJSONValue(s) as TJSONObject; ShowMessage(JS.GetValue('jsonString').Value); JS.Free; end; В процессе работы потока с ним может случиться все что угодно - обрыв связи, тайоут сработает, или некорректные данные, или еще что нибудь. И JS объект может не освободиться. Т.е. поток может уже и не существует, но в оперативке созданный объект лежит.
 
К тому же при таком подходе могут быть и ошибки, например параметра 'jsonString' может и не быть, и все вывалиться в ошибку (но в потоке этого можно и не увидеть) и до JS.Free код никогда не дойдет. А значит будет опять утечка памяти.
 
Так что правильней всего делать через Assigned:
var JS: TJSONObject; begin s := '{"jsonString":"ok"}'; JS := TJSONObject.ParseJSONValue(s) as TJSONObject; if Assigned(JS) then begin ShowMessage(JS.GetValue('jsonString').Value); JS.Free; end; end; Тогда утечек не будет. Это я теперь точно знаю!)))

Не за что.
Если что спрашивай. 
XML формат мне всегда был противен, хоть и понятен, но все равно внутренне я был против него и как следствие принципиально не использовал в своих программах.
Но вот формат JSON мне очень понравился. Его легко написать от руки, легко читать, даже через регулярки парситься легко, если приспичило. И он не избыточен как XML, а значит по канала связи передается меньше трафика.
 
Так что не бросай этот формат
 
И кстати, что касается утечек. Я когда сам только начинал разбираться в формате JSON и с тем как работать с ним в Delphi, у меня тоже были утечки, ибо я использовал JSON для парсинга ответа с сервера, в потоке. Я тогда начал склоняться к всеобщему мнению что просто сама реализация работы с этим форматом в делфи кривая. 
Но поколебавшись все таки принял во внимание ту мысль, что разработчики Embacadero на девять жизней умнее меня, и вряд ли они выпустили модуль с таким явным глюком. И решил все таки углубиться дальше.
Как оказалось просто поставить JS.Free в конце не достаточно.
Т.е. вот так вот делать не стоит:
var JS: TJSONObject; begin s := '{"jsonString":"ok"}; JS := TJSONObject.ParseJSONValue(s) as TJSONObject; ShowMessage(JS.GetValue('jsonString').Value); JS.Free; end; В процессе работы потока с ним может случиться все что угодно - обрыв связи, тайоут сработает, или некорректные данные, или еще что нибудь. И JS объект может не освободиться. Т.е. поток может уже и не существует, но в оперативке созданный объект лежит.
 
К тому же при таком подходе могут быть и ошибки, например параметра 'jsonString' может и не быть, и все вывалиться в ошибку (но в потоке этого можно и не увидеть) и до JS.Free код никогда не дойдет. А значит будет опять утечка памяти.
 
Так что правильней всего делать через Assigned:
var JS: TJSONObject; begin s := '{"jsonString":"ok"}'; JS := TJSONObject.ParseJSONValue(s) as TJSONObject; if Assigned(JS) then begin ShowMessage(JS.GetValue('jsonString').Value); JS.Free; end; end; Тогда утечек не будет. Это я теперь точно знаю!)))

Спасибо.

TJSONObject был перемещен в другое место из Data.DBXJSON в System.JSON. Подробнее тут: What's New in Delphi and C++Builder XE6 Работать так же, как и раньше. Просто изменить название подключаемого модуля на System.JSON.

Текст будет меняться, в течении всего времени использования программы.
Вариант с общим Layout и выравниванием по какому либо краю, это то что я тоже пытался сделать, как только понял что символам нельзя задать цвет по отдельности.
Но вы, наверное, так же как и я, заметили, что между буквами не одинаковое расстояние, что конечно сильно бросается в глаза.
 
Вариант номер два звучит отлично. Я бы хотел использовать его.
Но работа демо по TTextLayout оказалась крайне не стабильна.
Я запускаю из под Windows 8. 
Что бы само приложение не "покрывалось" артефактами (из-за optimus'а), я ставлю FMX.Types.GlobalUseDirect2D := false;
Но при добавление атрибутов ничего не меняется (да и в чистом виде в демо ничего не происходит).
Если же не много поиграться с Global, то можно добиться того, что шрифт будет менять на жирный. Цвет категорически менять не хочет.
 
Как добиться чтобы Демо работала, на Windows 8?
Может надо еще какие нибудь глобальные переменные изменить?

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

Назначение свойства Stored
Stored - нужно, чтобы указать нужно ли сохранять созданный объект в ресурсы формы или нет. Например, стилевые объекты не должны сериализоваться и сохраняться в ресурсы формы поскольку стиль загружается динамически в рантайме. И если он сериализуется в дизайн тайме, то в рантайме будет двойная загрузка стиля. Первый раз из ресурсов, второй раз уже динамически механизмом стилизации. Что как вы понимаете не верно. Поэтому у таких объектов, создаваемых в рантайме Stored устанавливается в False.
 
Это свойство никак не влияет на работу обработки событий мыши. Без stored все должно работать корректно. 
 
В чем ошибка?
Однако у вас есть ошибка, которая к этому поведению и привела и связана с неиспользованием свойства Stored.
Первый раз, когда вы бросаете компонент на форму, он создает в дизайн тайме прямоугольник и привязывает его к вашему контролу. Все бы ничего, но когда вы сохраняете форму, ваш прямоугольник сериализуется в ресурсы формы. Затем идет запуск программы. Вначале отрабатывает конструктор вашего компонента и он, естественно, создает прямоугольник в рантайме. Но затем идет чтение еще одного прямоугольника, который читается и располагается поверх созданного контролом прямоугольника. Но в отличии от первого он уже не имеет заданного обработчика. В итоге в рантайме, созданный прямоугольник располагается внизу. А затем он перекрывается аналогичными прямоугольниками, созданными из ресурсов формы. Вот и весь секрет