kami
-
Постов
643 -
Зарегистрирован
-
Посещение
-
Победитель дней
41
Сообщения, опубликованные kami
-
-
7 часов назад, Edward Tarasov сказал:
причем тут удаление компонентов
возможно, помимо master-view вы создали view под Андроид? А удалять пытаетесь с главного.
-
2 часа назад, Akad сказал:
Таймеры отключать, за нажатиями на закрытие форм и пр. следить
вот тут полностью не соглашусь, и вот по какой причине.
Здесь и сейчас, разрабатывая приложение и будучи полностью погруженным в этот процесс, разработчик помнит о том, что где-то там ради своего удобства и большей простоты кода он использовал ProcessMessages. Соответственно - он отключит таймеры, заблокирует возможность нажатия и прочая и прочая.Через пару месяцев после релиза поступает задача "добавить новый функционал". И я на 100% уверен, что никто, даже находясь в здравом уме и твердой памяти, не вспомнит об этом нюансе - что надо что-то там дисаблить и блокировать.
И потом - вы же сами говорите, что делая легче себе в одном месте - вам приходится следить (делать себе сложнее) в нескольких других. Так не лучше ли сразу делать так, чтобы не пришлось воспитывать в себе некую склонность к мазохизму?
-
25 минут назад, DMS сказал:
Как потом извлечь значения?
В общем случае обратная связь "браузер - приложение" не предусмотрена. Разве что вы будете сразу из веббраузера отправлять запрос на сервер. Но тогда - зачем вообще приложение, если можно всё сделать в веб ?
К примеру, в браузере - форма с кучей полей, отправляющая POST-запрос на сервер и редиректящая на какую-нибудь страницу. Приложение через OnBeforeNavigate (или_как_там_оно) видит это и запрашивает данные с сервера для своих "внутренностей".
-
2 часа назад, DMS сказал:
для чего в том коде Application.ProcessMessages? Какую задачу там выполняет? (не случайно же вставлен)
Возможно (лень смотреть) - не до конца отрабатывает RealignContent. Возможно - у него во внутренностях используются отложенные операции, дождаться завершения которых необходимо.
На текущий момент - имхо (опять-таки, лень смотреть) лучше всё, что после ProcessMessages заключить в TThread.ForceQueue, а сам ProcessMessages убрать.
-
10 часов назад, Alex7wrt сказал:
Но лично у меня ProcessMessages никогда не приводил к сбоям. Возможно потому, что использовал ее всегда в простых ситуациях вроде тех, о которых писал в посте выше.
Да-да, эта знаменитая фраза "у меня всё работает"
Видите ли, "простые ситуации" - это Вы скорее всего непосредственно про участок кода, в котором используется этот ProcessMessages.
Теперь представьте, что этот ProcessMessages вызывается в коде, который (первое, что пришло в голову) меняет цвет ListBoxItem. Чтобы сразу отобразились изменения. Просто? Да.
А на другом концевселеннойприложения запущен таймер, который запрашивает данные с сервера и меняет ListBox.И как раз в одном из ProcessMessages срабатывает этот таймер, уничтожая тот ListBoxItem, который мигает... Всё, приехали.
-
9 часов назад, Edward Tarasov сказал:
может есть возможность использовать встроенные возможности навигации
Нет понятия "встроенных возможностей навигации".
Вам надо - вы в своем приложении и:
- отслеживайте положение,
- меняйте маркер (положение /поворот),
- смотрите - ушел с маршрута или нет,
- озвучивайте "телку"
- и так далее.Совокупность всех этих действий и будет тем, что вы подразумеваете под "навигацией".
Только учтите, что пользоваться для прокладки маршрута вы будете чьим-то API. А лицензионные соглашения по их использованию имеют ограничения. Печально будет, если на очередном запуске вашего приложения гугл / яндекс / ситигид / другой провайдер скажут "до свидания". -
Это бага, которая появилась в Токио. В какой из подверсий - не помню.
Описание бага: всё, что расположено на скроллбоксах и их наследниках (например - листбокс) может произвольно поменять стиль.
-
1 час назад, DMS сказал:
а для iOS - три с половиной человека.
Собственно, так оно и есть. Порог вхождения (в плане финансовых вложений) достаточно высок.
-
45 минут назад, OnePeople сказал:
FMX приложение не хочет ловить сообщения
Самые очевидные ошибки и недочеты:
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. Через файловые потоки или данные в файле подкачки. Одно приложение пишет, второе периодически смотрит "а не появилось ли для меня чего нового". Как-то делал даже двусторонний обмен данными по этому механизму.Это навскидку. Выбирайте, потом можно говорить дальше.
-
-
Без реального устройства - никуда.
Емнип, Apple теперь принимает только 64битные приложения. Delphi пока не умеет работать с симулятором в 64 бита. А с учетом того, что SDK 11 именно 64 бита - устройство становится жизненно необходимым.Некоторые вещи вылезают только на устройстве. Имеется реальный опыт, когда вполне конкретная последовательность действий на симуляторе отрабатывала хорошо, а на устройстве приложение сваливалось.
-
-
12 часа назад, GASCHE сказал:
но я имел ввиду WaitForAny
В данном случае это всё избыточно и непроизводительно. Увеличивает сложность приложения без получения профита. Наоборот, производительность будет хуже. Особенно - на нагруженной системе.
С учетом условияВ 17.02.2018 в 13:20, DMS сказал:вызвать друг за другом три процедуры
это всё надо делать в одном потоке.
-
Пруфов про потоки в асинхронных вызовах не будет, если я правильно понял...
2 часа назад, Akad сказал:Т.е. когда ответ на запрос станет доступен заказчик может быть уже давно мёртв. Я с самого начала это повторяю
Я тоже могу повторить, что завершение всех инициированных собой операций - это проблема создателя этих операций, которую он обязан решить. Если прервать никак - значит дождаться завершения. Более того, возможно (но пока не могу утверждать), что с уничтожением экземпляра THTTPClient его асинхронная операция должна уйти в небытие.
2 часа назад, Akad сказал:По крайней мере HTTPServer это вообще не рабочая вещь.
А вот здесь ткните меня носом, пожалуйста. Что за HTTPServer - в справке в классах System,Net я такого не нашел. И в исходниках (правда, у меня Берлин) тоже. Возможно - плохо искал.
2 часа назад, Akad сказал:Кто ещё умеет https
THTTPClient. Причем - без необходимости таскания с собой всяких OpenSSL Library в разных ипостасях. Обратите внимание - я говорил именно за отказ от Indy в http(s) обмене. А не про "полный отказ".
-
6 минут назад, Akad сказал:
ссылки на мсдн как работают сокеты в асинхронном режиме?
MSDN??? В Windows сокеты в асинхронном режиме используют не потоки, а механизм сообщений windows. Гораздо менее затратную технологию, в которой дополнительными потоками (по крайней мере в ring 3) даже не пахнет.
7 минут назад, Akad сказал:И опять-же развивая мысль нужно использовать не THTTPClient, а TIdHTTP и так далее.
С чего это вдруг Инди, которые испокон веков работают в блокирующем режиме (создавая на каждый чих потоки, да еще и оправдываясь, что "это нормально"), стали обеспечивать асинхронность? И с каких пор они стали лучше, чем THTTPClient, если Embarcadero призвала отказываться от Indy в http(s)-обмене и использовать именно THTTPClient?
10 минут назад, Akad сказал:Нам пофиг что реально происходит, главное, что мы это не видим. Значит этого нет.
Есть разница между созданием потока вами и созданием потока ядром операционной системы. Совсем такое небольшое отличие в плане стабильности, оптимальности кода и ресурсов, скорости, покрытии кода тестами и так далее. Не передергивайте. Я сказал "даже если". Будучи абсолютно не уверенным, что где-то во внутренностях все-таки создаются доп.потоки.
-
1 час назад, DMS сказал:
ак сделать так, чтобы и потоки были (против зависания), и можно было управлять их запуском.
собственно, совет уже был дан: весь код запихать в 1 поток. Перед выполнением каждого следующего действия - проверять, а не прервали ли поток (if Terminated then exit). Не забывая высвобождать задействованные ресурсы.
Если же действия все-таки можно распараллелить (к примеру: есть огромный массив данных, над которым нужно выполнить x действий. Тогда делаем в одном потоке 1-е действие над y записями - отдаем второму потоку, а сами продолжаем обрабатывать дальше. Второй поток обработал часть данных - передал дальше. Минимизируется непроизводительный простой) - тогда есть смысл посмотреть в сторону пайпов в OmniThreadLibrary -
Принудительно вызвать KillFocus?
-
2 часа назад, DMS сказал:
В Memo попадают сначала "Begin End" и только потом - First Thread, Second Thread, Third Thread.
все правильно попадают. Вы же сами делаете TTask.Run, который создает доп. поток. То есть, последовательность выполнения каждого XXXThread получается следующая:
1. вывести Begin
2. запустить Task, который выполнится когда-нибудь.
3. вывести end.когда все 3 пункта выполнились - стартуют внутренности TTask, которые выводят надпись Thread.
2 часа назад, DMS сказал:чтобы вызов каждой процедуры (начиная со второй) зависел от результатов предыдущей процедуры?
Выполнение этого требования сводит на нет все преимущество, которое можно получить от потоков. Вы сознательно хотите последовательного выполнения операций. И несколько потоков становятся избыточными и даже вредными. Вполне хватит весь код запихнуть в один поток, что и позволит выполнить его (код) последовательно.
-
20 часов назад, Akad сказал:
и в следующем же абзаце говорите, что это лучшее из возможного,
Где я говорил за создание нового потока? Может, Вы посмотрите код, приведенный Виталием, прежде чем пытаться ловить меня на противоречии? Даже если на какой-либо платформе асинхронный вызов все-таки приводит к созданию потока - это не ваши проблемы, а проблемы операционной системы. С которыми она справится лучше, чем вы или я.
20 часов назад, Akad сказал:А во-вторых это такой-же не контролируемый поток.
Пруф в студию. Мне лень лезть в исходники THTTPClient, посему - жду от Вас.
20 часов назад, Akad сказал:Слушатель может быть давно уже мёртв, когда придёт ответ от сервера.
В случае уничтожения создатель запросов должен обеспечить их завершение. Например - дождаться окончания выполнения через EndAsyncHTTP . Если не высвобождать ресурсы, не дожидаться завершения выполнения всяких Synchronize или Queue, и так далее - ну... это всплывет очень быстро.
20 часов назад, Akad сказал:ни куда от пула запросов не деться.
Вот с этим согласен. С одним уточнением: пул запросов - это не пул потоков.
21 час назад, DMS сказал:вообще не нагуглил ни одного примера, что как бы намекает.
Да, тут нужно включить собственные знания базовых конструкций языка.
-
куда-то вы все полезли...
Давайте не забывать, что создание потока - затратная операция с точки зрения ОС.
И бесконтрольное создание кучи потоков - это плохо. Я уже не говорю про то, что фиг вы корректно прервете доп.поток, если он висит внутри синхронного Post или Get.Самый правильный вариант в данном случае предложил Кривяков Виталий. Минимальные затраты с точки зрения ресурсов и ожидаемый результат на выходе, вызванный в правильном потоке. И никаких проблем с различением "данные от сервера" vs "данные запрошенные мной".
Вообще, на мой взгляд - сама постановка вопроса некорректна. Структура ответа должна говорить сама за себя. Т.е. начало обработки ответа сервера - единое для всего обмена. И на основе 1-2 полей из полученного (к примеру) JSON определяется - какой именно объект к нам пришел и куда направить его дальнейшую обработку.
-
Только что, Menkos1 сказал:
мне не нужно разделывать тушку
Да это-то понятно
Ладно, предлагаю закончить с этим.
Можете привести пример, когда у панели задач выставлена настройка "группировать", а приложение игнорирует ее и отображается рядом?
Я такого не знаю, поскольку на положение кнопки на панели задач приложение, емнип, не может повлиять. Показать или не показать иконку - да. Показать несколько иконок (по одной на каждое окно) - да. Но группировать или нет - afaik - нет. -
2 минуты назад, Menkos1 сказал:
Если бы Вы знали - что такое группировка запущенных приложений на панели задач, то не задавали бы таких вопросов
Представьте себе - знаю. И странно, что Вы зацепились за это, я ж специально поставил там смайлик.
Разделанными - от слова разделывать, что относится к мясным продуктам (разделать мясную тушу).
Разделенными - от слова разделять, делить, отделять. Именно этот термин уместно применять к приложениям в панели задач.Но это все буквоедство, не есть важное.
-
1 час назад, Menkos1 сказал:
а были разделанными.
препарированными что ли ?
Это настройка ОС, а не приложения.
Компиляция под IOS
в Вопросы
Опубликовано
Вы точно выполнили все необходимые мероприятия из Readme.txt в патче?