
kami
Пользователи-
Публикаций
573 -
Зарегистрирован
-
Посещение
-
Победитель дней
38
Тип контента
Профили
Форумы
Статьи
Весь контент 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 использует штатный (нативный) браузер, там многое зависит от качества связки с ним.
- 2 ответа
-
- webbrowser
- влажность воздуха
-
(и ещё 1 )
C тегом:
-
Вы их готовить не умеете. Стабильности XMLDoc на мобильной платформе можно только позавидовать, т.к. там используется OmniXML. А на Win - парсер Microsoft, который используется чуть меньше, чем везде на Windows. И - да, я знаю что говорю. В боевом проекте на мобильной платформе стандартный XMLDocument использую (емнип) с 2016 года, начиная с XE7 и по 10.2 включительно. Ни разу не было проблем, связанных с ним.
-
Вы точно выполнили все необходимые мероприятия из Readme.txt в патче?
- 11 ответов
-
- печаль
- влажность воздуха
-
(и ещё 2 )
C тегом:
-
возможно, помимо 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 бита - устройство становится жизненно необходимым. Некоторые вещи вылезают только на устройстве. Имеется реальный опыт, когда вполне конкретная последовательность действий на симуляторе отрабатывала хорошо, а на устройстве приложение сваливалось.
-
Кто хорошо знает внутреннюю структуру FMX?
kami ответил Akad в теме Вопросы по языку Object Pascal и RTL
Есть дикое ощущение, что могли поломать синхронизацию через TMonitor.Wait. В Телеграме обсуждали подобный глюк, по stacktrace было похоже на это. -
В данном случае это всё избыточно и непроизводительно. Увеличивает сложность приложения без получения профита. Наоборот, производительность будет хуже. Особенно - на нагруженной системе. С учетом условия это всё надо делать в одном потоке.
-
Пруфов про потоки в асинхронных вызовах не будет, если я правильно понял... Я тоже могу повторить, что завершение всех инициированных собой операций - это проблема создателя этих операций, которую он обязан решить. Если прервать никак - значит дождаться завершения. Более того, возможно (но пока не могу утверждать), что с уничтожением экземпляра THTTPClient его асинхронная операция должна уйти в небытие. А вот здесь ткните меня носом, пожалуйста. Что за HTTPServer - в справке в классах System,Net я такого не нашел. И в исходниках (правда, у меня Берлин) тоже. Возможно - плохо искал. THTTPClient. Причем - без необходимости таскания с собой всяких OpenSSL Library в разных ипостасях. Обратите внимание - я говорил именно за отказ от Indy в http(s) обмене. А не про "полный отказ".
-
MSDN??? В Windows сокеты в асинхронном режиме используют не потоки, а механизм сообщений windows. Гораздо менее затратную технологию, в которой дополнительными потоками (по крайней мере в ring 3) даже не пахнет. С чего это вдруг Инди, которые испокон веков работают в блокирующем режиме (создавая на каждый чих потоки, да еще и оправдываясь, что "это нормально"), стали обеспечивать асинхронность? И с каких пор они стали лучше, чем THTTPClient, если Embarcadero призвала отказываться от Indy в http(s)-обмене и использовать именно THTTPClient? Есть разница между созданием потока вами и созданием потока ядром операционной системы. Совсем такое небольшое отличие в плане стабильности, оптимальности кода и ресурсов, скорости, покрытии кода тестами и так далее. Не передергивайте. Я сказал "даже если". Будучи абсолютно не уверенным, что где-то во внутренностях все-таки создаются доп.потоки.