Maximus

Не вопрос.
SQLITE.zip

Не подойдёт? http://docwiki.embarcadero.com/Libraries/Berlin/en/FMX.Graphics.TBitmap.FlipHorizontal

Не подойдёт? http://docwiki.embarcadero.com/Libraries/Berlin/en/FMX.Graphics.TBitmap.FlipHorizontal

Не подойдёт? http://docwiki.embarcadero.com/Libraries/Berlin/en/FMX.Graphics.TBitmap.FlipHorizontal

Принцип работы такой:
На форму кладете стандартный TImage Создаете экземпляр TGifPlayer Задаете свойство FGifPlayer.Image:=Image; где Image это лежащая на форме TImage Загружаете гифку FGifPlayer.LoadFromFile('D:\Embarcadero\Projects\ShareCode\FMX.GifUtils\GIF_Example.gif'); Запускаем проигрывание гифки FGifPlayer.Play; Вот код:
unit UnitFormMain; interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.GifUtils, FMX.Objects; type TFormMain = class(TForm) Image: TImage; procedure FormCreate(Sender: TObject); private { Private declarations } public { Public declarations } FGifPlayer : TGifPlayer; end; var FormMain: TFormMain; implementation {$R *.fmx} procedure TFormMain.FormCreate(Sender: TObject); begin FGifPlayer:=TGifPlayer.Create(Self); FGifPlayer.Image:=Image; FGifPlayer.LoadFromFile('D:\Embarcadero\Projects\ShareCode\FMX.GifUtils\GIF_Example.gif'); FGifPlayer.Play; end; end. Вот демо проект во вложении:
 
FMX.GifUtils.Demo.zip

Сделал то что надо на основе progressbar, получилось еще красивее.
Основа – rectangle, на ней progressbar у него HitTest = false и выравнивание по горизонтали. На rectangle повесил три события OnMouseDown, OnMouseMove и OnMouseLeave. У первых двух код устанавливает Value прогресбара в соответствии координатой пальца по оси X.  OnMouseLeave это основное действие которое выполняется после того как палец ушел за пределы или отрыв в любом месте. В моем случае это перемотка по файлу. Rectangle полезен когда progressbar узкий, для удобства использования. Цвет ему прозрачный, закруглить углы и получается довольно симпатичный контрЛ.
 

трудно придумать что-то, что может успеть выполниться менее чем за 1 мсек на десктопе, а на мобильном и подавно
так что вы немного остудите жар-то ))

Пожалуйста, внимательней прочтите тему, здесь идет речь про асинхронный THTTPClient, а не про Indy компоненты. Если в вашем приложении до сих пор используется Indy, то советую от него избавляться.
Пожалуйста, будьте более культырными в своем общении, этот форум нацелен повысить уровень делфи программистов, а не унизить кого-то и пустить по плохому пути.
THTTPClient успешно делает асинхронные запросы и синхронизирует callback для обработки, поэтому использовать его в синхронном режиме и добавлять свою реализацию асинхронности считаю лишними затаратами ресурсов.

@Akad, У Вас есть опыт работы с TNetHTTPClient компонентом или классом THTTPClient? Как и где вы это использовали? Что не понравилось? Какие трудности были?
... можете не отвечать, я уже глянул ваши предыдущие сообщения и смысла в продолжении беседы не вижу
@kiz35196 Наиболее простой вариант Вы можете глянуть в этом посте.

Вы их готовить не умеете. Стабильности XMLDoc на мобильной платформе можно только позавидовать, т.к. там используется OmniXML. А на Win - парсер Microsoft, который используется чуть меньше, чем везде на Windows.
И - да, я знаю что говорю. В боевом проекте на мобильной платформе стандартный XMLDocument использую (емнип) с 2016 года, начиная с XE7 и по 10.2 включительно. Ни разу не было проблем, связанных с ним.

Что конкретно печально в асинхронности клиента? На какой платформе? Если с примером - то вообще замечательно.
п.с. Еще раз повторю, что нареканий со стороны работы асинхронности не было замечено в течении года в нагруженном мобильном приложении на обоих осях, Delphi Berlin Update 2.
 

в любом контексте это плохой стиль.
то что он в оф примерах это еще хуже

C методом TThread.Synchronize нет никаких проблем и VCL я их также не замечал. Проблемы с этим только у вас. Это вы не разобрались с "потокобезопасностью", и скорее всего одновременно пытаетесь обращаться к данным из двух потоков - в результате случайные AV.  В том топике вас просили дать конкретный пример глючного кода, его так и не было.

Вот интересный вы человек! 
Вам показали пример, вы не посмотрев начпли говорить про какие то левые фантики.
Потом все же скачали, и просто нажали зеленую кнопку, а оно не вот ошбками плюется, да за такие деньги! Ужас, как таким ...ном пользоваться можо!!! Не работает!!!!
А можно было просто посмотреть на том же доквики, там расписан порядок работы с срвисами. Вы билд делали сервису перед запуском то? Угадаю- нет конечно! А если бы сделали все как надо, а не бубны искали для танцев, заработало бы.
Когда вот в AS gradle начнет ошибками кидать, кто виноват будет? Майкрософт наверное, что в свою ОС дал эту поделку ставить?

вот сделал, кое как. вот так я и хотел
 

В модуле FMX.Helpers.Win есть две чудные функции:
function GetDCScale(const DC: HDC): Single; function GetWndScale(const Wnd: HWnd): Single; причём вторая из них учитывает особенности, начиная с восьмерки.

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

http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.Classes.TThread.Synchronize
Судя по документации, если передать первым параметром поток, то в дальнейшем в основном потоке можно будет определить какой из дополнительных потоков вызвал метод. Если это не требуется, то можно ничего не передавать.

Разница есть. И она не только в вызове Synchronize, но и Queue.
Указание потока в качестве источника метода синхронизации позволяет вам впоследствии сделать TThread.RemoveQueuedEvents(myThread) перед его удалением.
Вызов RemoveQueuedEvents необходим, если в синхронизируемых методах может идти обращение к полям и методам уничтожаемого потока. Потому что с удалением потока то, что подлежало синхронизации, никуда не пропадет, а раз поток уже не существует - у вас вылезет AV на ровном месте. Или же ваш код испортит чью-то память, что еще труднее отловить.

http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.Classes.TThread.Synchronize
Судя по документации, если передать первым параметром поток, то в дальнейшем в основном потоке можно будет определить какой из дополнительных потоков вызвал метод. Если это не требуется, то можно ничего не передавать.

http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.Classes.TThread.Synchronize
Судя по документации, если передать первым параметром поток, то в дальнейшем в основном потоке можно будет определить какой из дополнительных потоков вызвал метод. Если это не требуется, то можно ничего не передавать.

Прям немедленно остановить нельзя, но можно вызвать метод Cancel
var Task : ITask; ... Task := TTask.Run(...); ... Task.Cancel; //когда нужно остановить А внутри таска сделать проверки, что если выполняется
Task.Status = TTaskStatus.Canceled то не нужно обновлять данные, там где вы их обновляете и досрочно закончить работу кода таска.

Прям немедленно остановить нельзя, но можно вызвать метод Cancel
var Task : ITask; ... Task := TTask.Run(...); ... Task.Cancel; //когда нужно остановить А внутри таска сделать проверки, что если выполняется
Task.Status = TTaskStatus.Canceled то не нужно обновлять данные, там где вы их обновляете и досрочно закончить работу кода таска.

На самом деле это поведение можно достаточно просто отключить
var Connect : TFDConnection; Query : TFDQuery; ... Connect.ResourceOptions.SilentMode := true; Query.ResourceOptions.SilentMode := true; ...  

На самом деле это поведение можно достаточно просто отключить
var Connect : TFDConnection; Query : TFDQuery; ... Connect.ResourceOptions.SilentMode := true; Query.ResourceOptions.SilentMode := true; ...