kami

Вы точно выполнили все необходимые мероприятия из 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? Есть разница между созданием потока вами и созданием потока ядром операционной системы. Совсем такое небольшое отличие в плане стабильности, оптимальности кода и ресурсов, скорости, покрытии кода тестами и так далее. Не передергивайте. Я сказал "даже если". Будучи абсолютно не уверенным, что где-то во внутренностях все-таки создаются доп.потоки.

собственно, совет уже был дан: весь код запихать в 1 поток. Перед выполнением каждого следующего действия - проверять, а не прервали ли поток (if Terminated then exit). Не забывая высвобождать задействованные ресурсы. Если же действия все-таки можно распараллелить (к примеру: есть огромный массив данных, над которым нужно выполнить x действий. Тогда делаем в одном потоке 1-е действие над y записями - отдаем второму потоку, а сами продолжаем обрабатывать дальше. Второй поток обработал часть данных - передал дальше. Минимизируется непроизводительный простой) - тогда есть смысл посмотреть в сторону пайпов в OmniThreadLibrary

Принудительно вызвать KillFocus?

все правильно попадают. Вы же сами делаете TTask.Run, который создает доп. поток. То есть, последовательность выполнения каждого XXXThread получается следующая: 1. вывести Begin 2. запустить Task, который выполнится когда-нибудь. 3. вывести end. когда все 3 пункта выполнились - стартуют внутренности TTask, которые выводят надпись Thread. Выполнение этого требования сводит на нет все преимущество, которое можно получить от потоков. Вы сознательно хотите последовательного выполнения операций. И несколько потоков становятся избыточными и даже вредными. Вполне хватит весь код запихнуть в один поток, что и позволит выполнить его (код) последовательно.

Где я говорил за создание нового потока? Может, Вы посмотрите код, приведенный Виталием, прежде чем пытаться ловить меня на противоречии? Даже если на какой-либо платформе асинхронный вызов все-таки приводит к созданию потока - это не ваши проблемы, а проблемы операционной системы. С которыми она справится лучше, чем вы или я. Пруф в студию. Мне лень лезть в исходники THTTPClient, посему - жду от Вас. В случае уничтожения создатель запросов должен обеспечить их завершение. Например - дождаться окончания выполнения через EndAsyncHTTP . Если не высвобождать ресурсы, не дожидаться завершения выполнения всяких Synchronize или Queue, и так далее - ну... это всплывет очень быстро. Вот с этим согласен. С одним уточнением: пул запросов - это не пул потоков. Да, тут нужно включить собственные знания базовых конструкций языка.

куда-то вы все полезли... Давайте не забывать, что создание потока - затратная операция с точки зрения ОС. И бесконтрольное создание кучи потоков - это плохо. Я уже не говорю про то, что фиг вы корректно прервете доп.поток, если он висит внутри синхронного Post или Get. Самый правильный вариант в данном случае предложил Кривяков Виталий. Минимальные затраты с точки зрения ресурсов и ожидаемый результат на выходе, вызванный в правильном потоке. И никаких проблем с различением "данные от сервера" vs "данные запрошенные мной". Вообще, на мой взгляд - сама постановка вопроса некорректна. Структура ответа должна говорить сама за себя. Т.е. начало обработки ответа сервера - единое для всего обмена. И на основе 1-2 полей из полученного (к примеру) JSON определяется - какой именно объект к нам пришел и куда направить его дальнейшую обработку.

Да это-то понятно Ладно, предлагаю закончить с этим. Можете привести пример, когда у панели задач выставлена настройка "группировать", а приложение игнорирует ее и отображается рядом? Я такого не знаю, поскольку на положение кнопки на панели задач приложение, емнип, не может повлиять. Показать или не показать иконку - да. Показать несколько иконок (по одной на каждое окно) - да. Но группировать или нет - afaik - нет.

Представьте себе - знаю. И странно, что Вы зацепились за это, я ж специально поставил там смайлик. Разделанными - от слова разделывать, что относится к мясным продуктам (разделать мясную тушу). Разделенными - от слова разделять, делить, отделять. Именно этот термин уместно применять к приложениям в панели задач. Но это все буквоедство, не есть важное.

препарированными что ли ? Это настройка ОС, а не приложения.