kami

В рантайме нет никаких дженериков. Компилятор преобразует все дженерики в реальные списки с необходимой типизацией. Поэтому - действительно никак. Вполне возможно, что даже 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, а вообще чем угодно, что поддерживает указанный интерфейс. И если список сделать тоже с поддержкой интерфейса (не знаю, какие методы в нем необходимы), то и сам объект может работать со своим владельцем абсолютно не интересуясь его типом.

Можно это обойти (и довольно неплохо, не костыльно)... но это нужно кодить. Готового механизма нет.

нет. Потому что элемент не принадлежит никакому листу. Это список знает, что при удалении элемента нужно сделать ему Free / заNil-ить ссылку на элемент. Только список. Сам объект (элемент списка) не подозревает о том, что он кому-то там "принадлежит".

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

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

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

Платформа-то хоть какая? WB использует штатный (нативный) браузер, там многое зависит от качества связки с ним.

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

Вы точно выполнили все необходимые мероприятия из Readme.txt в патче?

возможно, помимо master-view вы создали view под Андроид? А удалять пытаетесь с главного.

вот тут полностью не соглашусь, и вот по какой причине. Здесь и сейчас, разрабатывая приложение и будучи полностью погруженным в этот процесс, разработчик помнит о том, что где-то там ради своего удобства и большей простоты кода он использовал ProcessMessages. Соответственно - он отключит таймеры, заблокирует возможность нажатия и прочая и прочая. Через пару месяцев после релиза поступает задача "добавить новый функционал". И я на 100% уверен, что никто, даже находясь в здравом уме и твердой памяти, не вспомнит об этом нюансе - что надо что-то там дисаблить и блокировать. И потом - вы же сами говорите, что делая легче себе в одном месте - вам приходится следить (делать себе сложнее) в нескольких других. Так не лучше ли сразу делать так, чтобы не пришлось воспитывать в себе некую склонность к мазохизму?

В общем случае обратная связь "браузер - приложение" не предусмотрена. Разве что вы будете сразу из веббраузера отправлять запрос на сервер. Но тогда - зачем вообще приложение, если можно всё сделать в веб ? К примеру, в браузере - форма с кучей полей, отправляющая POST-запрос на сервер и редиректящая на какую-нибудь страницу. Приложение через OnBeforeNavigate (или_как_там_оно) видит это и запрашивает данные с сервера для своих "внутренностей".

Возможно (лень смотреть) - не до конца отрабатывает RealignContent. Возможно - у него во внутренностях используются отложенные операции, дождаться завершения которых необходимо. На текущий момент - имхо (опять-таки, лень смотреть) лучше всё, что после ProcessMessages заключить в TThread.ForceQueue, а сам ProcessMessages убрать.

Да-да, эта знаменитая фраза "у меня всё работает" Видите ли, "простые ситуации" - это Вы скорее всего непосредственно про участок кода, в котором используется этот ProcessMessages. Теперь представьте, что этот ProcessMessages вызывается в коде, который (первое, что пришло в голову) меняет цвет ListBoxItem. Чтобы сразу отобразились изменения. Просто? Да. А на другом конце вселенной приложения запущен таймер, который запрашивает данные с сервера и меняет ListBox. И как раз в одном из ProcessMessages срабатывает этот таймер, уничтожая тот ListBoxItem, который мигает... Всё, приехали.

Нет понятия "встроенных возможностей навигации". Вам надо - вы в своем приложении и: - отслеживайте положение, - меняйте маркер (положение /поворот), - смотрите - ушел с маршрута или нет, - озвучивайте "телку" - и так далее. Совокупность всех этих действий и будет тем, что вы подразумеваете под "навигацией". Только учтите, что пользоваться для прокладки маршрута вы будете чьим-то API. А лицензионные соглашения по их использованию имеют ограничения. Печально будет, если на очередном запуске вашего приложения гугл / яндекс / ситигид / другой провайдер скажут "до свидания".

Это бага, которая появилась в Токио. В какой из подверсий - не помню. Описание бага: всё, что расположено на скроллбоксах и их наследниках (например - листбокс) может произвольно поменять стиль. Видео: https://www.youtube.com/watch?v=HSQI2qDghRQ Issue: https://quality.embarcadero.com/browse/RSP-19297

Собственно, так оно и есть. Порог вхождения (в плане финансовых вложений) достаточно высок.

Самые очевидные ошибки и недочеты: 1. Почему FindWindowA? Зачем явное указание Ansi-версии этой функции? 2. cbData - это размер данных в байтах. 1 символ <> 1 байт. 3. SendMessage - это функция. И она возвращает результат. Его необходимо анализировать. 4. StrLCopy... вы уверены, что ParamStr(1) влезет в 100 символов? Ощущение, что этот код вы скопировали из какого-то VCL примера времен Delphi5

Есть волшебная аббревиатура - IPC. Inter process communication. Считайте, что у вас два разных приложения.Абсолютно разных. Которым нужно взаимодействовать друг с другом. Одно - источник, второе - приемник. Среди вариантов для Windows: 1. Через сообщения, например - WM_COPYDATA (емнип, так обзывается). Нужно знать хендл окна, которому отправится сообщение (не уверен, что с WM_COPYDATA пройдет фокус с функцией BroadcastMessage) и нужно чтобы целевое приложение было на том же уровне изоляции (UIPI, кажется). Т.е. если приемник запущен от админа, а источник - как обычное приложение - этим способом их не состыковать. 2. Через NamedPipes. Способ хорош для организации постоянного обмена между двумя любыми приложениями на одном компьютере (не только, но чаще всего - на одном). Для однократной передачи информации держать слушающий пайп в отдельном потоке, наверное, избыточно. Хотя я бы взял именно этот способ. 3. TCP/IP и надстройки над ним: http, ftp и другое tp. Чаще всего используются для организации обмена между приложениями на разных компьютерах. Для локального - избыточно, да и проблемы с файрволлом могут быть. 4. Через файловые потоки или данные в файле подкачки. Одно приложение пишет, второе периодически смотрит "а не появилось ли для меня чего нового". Как-то делал даже двусторонний обмен данными по этому механизму. Это навскидку. Выбирайте, потом можно говорить дальше.

Достаточно много посетителей форума говорило, что работает с XCode на виртуалке. Получается - не нужен.

Без реального устройства - никуда. Емнип, Apple теперь принимает только 64битные приложения. Delphi пока не умеет работать с симулятором в 64 бита. А с учетом того, что SDK 11 именно 64 бита - устройство становится жизненно необходимым. Некоторые вещи вылезают только на устройстве. Имеется реальный опыт, когда вполне конкретная последовательность действий на симуляторе отрабатывала хорошо, а на устройстве приложение сваливалось.

Есть дикое ощущение, что могли поломать синхронизацию через TMonitor.Wait. В Телеграме обсуждали подобный глюк, по stacktrace было похоже на это.

В данном случае это всё избыточно и непроизводительно. Увеличивает сложность приложения без получения профита. Наоборот, производительность будет хуже. Особенно - на нагруженной системе. С учетом условия это всё надо делать в одном потоке.

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

MSDN??? В Windows сокеты в асинхронном режиме используют не потоки, а механизм сообщений windows. Гораздо менее затратную технологию, в которой дополнительными потоками (по крайней мере в ring 3) даже не пахнет. С чего это вдруг Инди, которые испокон веков работают в блокирующем режиме (создавая на каждый чих потоки, да еще и оправдываясь, что "это нормально"), стали обеспечивать асинхронность? И с каких пор они стали лучше, чем THTTPClient, если Embarcadero призвала отказываться от Indy в http(s)-обмене и использовать именно THTTPClient? Есть разница между созданием потока вами и созданием потока ядром операционной системы. Совсем такое небольшое отличие в плане стабильности, оптимальности кода и ресурсов, скорости, покрытии кода тестами и так далее. Не передергивайте. Я сказал "даже если". Будучи абсолютно не уверенным, что где-то во внутренностях все-таки создаются доп.потоки.