kami

Или возьмите TListView, у него есть PullToRefresh... или смотрите, как оно в нем сделано (в TListViewBase)

Даже более того - если с сервера приходит с указанием правильной кодировки (не обязательно UTF-8), то всё работает замечательно без всяких переделок. Ибо перекодирование автоматически производится во внутренностях http-клиента.

Не используйте дельфовые типы (в частности - строки как отдельно так и в составе record-ов) при передаче параметров в / из длл и не надо будет никаких костылей в виде borlndmm.dll и т.п.
Представьте, что ваша длл будет вызываться из приложения на C++ и используйте только совместимые типы для экспортируемых функций.
Я думаю, не надо говорить, что экземпляры классов 100% не стоит передавать между длл и exe.

Решил свой вопрос. 
ListViewItem.Selectable:=false;
Обработку итемов вынес в OnTap  ListViewItem
 
Теперь прокручивается без активации итемов. А на тапе по итему - обработка контролов.
 

Ответ нашелся
https://community.embarcadero.com/forum/programming/9795-ssl3-get-record-wrong-version-number-error?start=6#14547
 
Спасибо за внимание

Что может быть непонятно во фразе non-zero value из первоисточника? Скорее всего, возвращаемый результат интерпретируется как BOOL. У любого булеан-типа есть два значения: 0 = False, не 0 = True.
Что там присваивают конкретные компиляторы для значения True - это их проблемы. Сравнение всегда ведется с нулем.
 
Может да, а может и нет. Откуда вы знаете, какую логику заложили другие разработчики в свои хуки? Это исключительно их дело - считают ли они нужным
 

наверное, действительно никто.
Но вот методом интуитивного тыка это находится на раз. Должно быть так:

 
А у вас, видимо, стоит emacs

наверное, действительно никто.
Но вот методом интуитивного тыка это находится на раз. Должно быть так:

 
А у вас, видимо, стоит emacs

https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms644984(v=vs.85).aspx

по тексту этой ошибки гуглится очень многое.
Основной посыл: для WH_KEYBOARD, если указывать HInstance, то он должен быть инстансом dll. Потому что exe не инжектнется в чужой процесс.
Можно указать вместо HInstance - 0, а последний параметр выставить в TThread.Current.ThreadID, но (повторюсь) я не уверен, что веббраузер работает только в контексте основного потока приложения.

Да куда угодно. Любой модуль, но скорее всего - модуль той формы, на которой лежит веббраузер (его же нужно "обойти"). Там же (например - в конструкторе / деструкторе формы) - регистрация и удаление хука.
Ну вот например: https://ru.stackoverflow.com/a/538552/192901  (просмотрел бегло, но криминала нет, по крайней мере - система не помрет, что, кстати, весьма возможно при использовании глобальных хуков).
вместо SendMessage подставить myForm.OnKeyDown(...);
возможно - придется несколько поменять внутреннюю логику самого хука. Но основа останется без изменений: внутрь хука получается структура, описывающая "что произошло с клавиатурой". Вы ее обрабатываете, вызываете нужные методы и отдаете управление опять системе.
 

Было бы неплохо почитать, чем отличается WH_KEYBOARD от WH_KEYBOARD_LL. Принципы действия абсолютно разные.
Вполне возможно, что окна браузера находятся в другом потоке. Посему для начала экспериментов вам нужен именно WH_KEYBOARD_LL
 
Ну так нужно же понимать причину - почему он равен нулю. Обращаемся к первоисточнику.
Смотрите, что вернется и узнавайте причину. Можно так:
if CurrentHook = 0 then RaiseLastOSError. Нет. Здесь имеется ввиду не разрядность операционной системы, а именно разрядность процессов, запущенных в ней (в 64-битный процесс может быть загружена только 64-битная dll. В 32бита - 32). Кроме того, _LL хуки не зависят от разрядности процесса, поскольку работают в контексте установившего хук потока, им dll не требуется.

Здесь ничего не меняли? (ну, Target, само собой должен быть Android)

Аналогично FREEFAR, пытаемся публиковать приложение.
Отказов пока еще не получили, но при подготовке к публикации столкнулись со страшным для нас вопросом о шифровании данных (текст переведен с немецкого):
Проблема в том что мы шифруем БД приложения с помощью AES256 (приложение для школ, хранит личные данные учеников, без шифрования данных в нашем случае нельзя).
Шифрование в нашем случае не главное предназначение приложения, главное - обработка данных, выставление оценок и т.п.
 
Вопрос: кто-нибудь еще шифрует данные приложения? Как вы отвечали на такой вопрос Эппла? Были ли какие вопросы от Эппла/последствия?
Всем заранее спасибо и хорошего дня!
 
PS. возможно стоит завести новую ветку форума для такого рода вопросов: юридических вопросов или про подготовку к публикации.

Если честно, тут задача на мой взгляд в неправильном подходе. Который порождает странную задачу. Это как плыть против течения, вместо того, чтобы плыть по течению.
Если требуется выполнить данную задачу, то  лучше не побояться написать один дополнительный класс "Менеджер объектов", которому вы будите делегировать данную задачу.
Чтобы поиск был быстрый, нужно использовать словарь. Время поиска будет O(1) против поиска в списке. Один из вариантов реализации может быть таким:
В менеджере есть набор ваших списков (логические группы объектов) - список списков В менеджере есть словарь соответствия контрол -> индекс списка из (1) при добавлении контрола добавляете его в список и заносите контрол в словарь Поиск за О(1) Вариант, который предложил Kami хороший для вариантов, когда объекты ваши. А вот если вы хотите для штатных контролов это сделать, то чтобы подмешать такой интерфейс, вам потребуется сделать наследников для каждого UI контрола. А если эти контролы еще и на форме лежат, то там придется изрядно попотеть, чтобы добавить в IDE ваши версии штатных контролов с этим интерфейсом.
P.S. Избегайте паттерна один контрол "владеется" несколькими списками. Это к "При создании каждого из них  AOwnsObjects задано как True.". Такой подход рано или поздно при усложнии логики закончится AV и сложным дебаггингом, кто кого удалил и когда и почему. Используйте золотое правило: "Один объект может иметь только одного владельца, один объект может использовать во многих других местах. Только владелец отвечает удаление объекта и в хорошем случае и за его создание. Клиенты объекта только пользуются им и не удаляют его."

В рантайме нет никаких дженериков. Компилятор преобразует все дженерики в реальные списки с необходимой типизацией. Поэтому - действительно никак. Вполне возможно, что даже is TObjectList<TMyClass> не сработает - компилятор вполне вправе посчитать исходный класс TObjectList<TMyClass> не тем, с которым производится is.
Это неправильно. Потому что есть еще Insert, есть Update (в том числе - и InsertRange). Правильно - перекрыть метод Notify или реализовать обработчик события OnNotify (последнее даже создания наследников не требует).
Вообще, если по каким-то причинам необходимо знать "владельца", было бы совсем хорошо сделать наследника от TRectangle, который будет реализовывать интерфейс наподобие такого:
 
IOwneredIntf = interface ['{ADF563F3-B4CE-4E96-9559-F0FFC2936D5Z}'] function GetOwner: TObject; procedure SetOwner(const Value: TObject); property Owner: TObject read GetOwner write SetOwner; end; Список, который хочет установить владельческие отношения с этим TRectangle, в своем методе Notify приводит его к интерфейсу и устанавливает intf.Owner:=Self
Ну и в обратном порядке - тоже.
При этом появляется возможность работать со списком не только TRectangle, а вообще чем угодно, что поддерживает указанный интерфейс.
И если список сделать тоже с поддержкой интерфейса (не знаю, какие методы в нем необходимы), то и сам объект может работать со своим владельцем абсолютно не интересуясь его типом.

В рантайме нет никаких дженериков. Компилятор преобразует все дженерики в реальные списки с необходимой типизацией. Поэтому - действительно никак. Вполне возможно, что даже is TObjectList<TMyClass> не сработает - компилятор вполне вправе посчитать исходный класс TObjectList<TMyClass> не тем, с которым производится is.
Это неправильно. Потому что есть еще Insert, есть Update (в том числе - и InsertRange). Правильно - перекрыть метод Notify или реализовать обработчик события OnNotify (последнее даже создания наследников не требует).
Вообще, если по каким-то причинам необходимо знать "владельца", было бы совсем хорошо сделать наследника от TRectangle, который будет реализовывать интерфейс наподобие такого:
 
IOwneredIntf = interface ['{ADF563F3-B4CE-4E96-9559-F0FFC2936D5Z}'] function GetOwner: TObject; procedure SetOwner(const Value: TObject); property Owner: TObject read GetOwner write SetOwner; end; Список, который хочет установить владельческие отношения с этим TRectangle, в своем методе Notify приводит его к интерфейсу и устанавливает intf.Owner:=Self
Ну и в обратном порядке - тоже.
При этом появляется возможность работать со списком не только TRectangle, а вообще чем угодно, что поддерживает указанный интерфейс.
И если список сделать тоже с поддержкой интерфейса (не знаю, какие методы в нем необходимы), то и сам объект может работать со своим владельцем абсолютно не интересуясь его типом.

где может быть в другом месте инициализирована CartList  если в конкретном примере она объявлена в процедуре

Не, оказывается я ошибся еще больше. Чтобы окончательно выяснить - залез на https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms644906(v=vs.85).aspx
USER_TIMER_MINIMUM (0x0000000A), -  минимально возможный интервал = 10мс. Но это недостижимый идеал :)))

Графические движки не пользуются таймерами, это чревато гигантскими лагами.
QueryPerfomanceCounter и т.п.

Ни одна операционная система (за исключением систем реального времени) не обеспечит вам такую точность. Среда разработки здесь ни при чем. Совсем.
К примеру, на Windows минимально возможный интервал таймера, емнип, 55мс.
При этом нужно понимать, что событие таймера сработает только тогда, когда главный поток не будет ничем занят. А это, поверьте, случается достаточно редко. Грубо говоря - событие отработает "по остаточному принципу".  Т.е. в реальности даже 55мс на Windows будет обеспечено далеко не всегда. Что уж говорить про мобильные платформы.
Вам нужно пересмотреть алгоритм работы.

Пруфов про потоки в асинхронных вызовах не будет, если я правильно понял...
Я тоже могу повторить, что завершение всех инициированных собой операций - это проблема создателя этих операций, которую он обязан решить. Если прервать никак - значит дождаться завершения. Более того, возможно (но пока не могу утверждать), что с уничтожением экземпляра THTTPClient его асинхронная операция должна уйти в небытие.
А вот здесь ткните меня носом, пожалуйста. Что за HTTPServer - в справке в классах System,Net я такого не нашел. И в исходниках (правда, у меня Берлин) тоже. Возможно - плохо искал.
THTTPClient. Причем - без необходимости таскания с собой всяких OpenSSL Library в разных ипостасях. Обратите внимание - я говорил именно за отказ от Indy в http(s) обмене. А не про "полный отказ".

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

Это примерно как забыть о том, как работает функция, что где править. Естественно забудет, а потом вспомнит, когда менять что-то будет в этом месте. Вдеть в начале процедуры прямо сразу cooltimer.Enabled := false; наведёт на мысли.
Всегда много путей. Какой-то определённо проще. Но я не пишу приложения, которые лагают, которые нажал на кнопку рутинного действия и сидишь, ждёшь результат. Более того моё текущее приложение (клиент-серверное, с огромными объёмами данных от БД) ввобще не лагает, даже на 3G модеме, на котором параллельно ещё качается торрент. То есть для меня важно, что бы пользователь мог работать нормально.
Единственное о чём я сожалею, что всё завязано на FMX. От него "прилетает" безумное количество мелких и не очень глюков, отсутствие работающих скинов и так далее. Но это уже к теме не относится... Я в текущий момент из интерфейса по скорости и удобству выжал уже почти максимум в том числе и из-за Application.ProcessMessages.