kami

Пользователи
  • Публикаций

    575
  • Зарегистрирован

  • Посещение

  • Победитель дней

    38

kami стал победителем дня 31 марта

kami имел наиболее популярный контент!

4 Подписчика

Информация о kami

  • Звание
    Продвинутый пользователь
  • День рождения 16.06.1981

Контакты

  • StackOverflow
    http://ru.stackoverflow.com/users/192901/kami

Информация

  • Пол
    Не определился
  • Город
    Санкт-Петербург

Посетители профиля

873 просмотра профиля
  1. kami

    PNG работа с чанками

    А что мешает использовать этот класс? Это не визуальный компонент, на форму его класть не надо.
  2. kami

    Поток на клиенте

    Так не вызывайте отрисовку на каждый принятый пакет. Пусть принятые данные кладутся в очередь (например - TQueue). Когда назревает необходимость отрисовки (допустим, по таймеру) - из очереди выгребаются все пакеты и данные рисуются сразу, всем скопом. По потоку: в соответствии с общими правилами - некорректно создавать объект в одном потоке и начинать его использовать в одном потоке, а основное использование вести в другом. Это я про TIDTCPClient. Перенесите его создание и уничтожение (кстати - а где деструктор?) в Execute вашего потока. На основании чего такой вывод? Я про первую часть - "поток отрабатывает сообщения с сервера"?
  3. В рантайме нет никаких дженериков. Компилятор преобразует все дженерики в реальные списки с необходимой типизацией. Поэтому - действительно никак. Вполне возможно, что даже 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, а вообще чем угодно, что поддерживает указанный интерфейс. И если список сделать тоже с поддержкой интерфейса (не знаю, какие методы в нем необходимы), то и сам объект может работать со своим владельцем абсолютно не интересуясь его типом.
  4. Можно это обойти (и довольно неплохо, не костыльно)... но это нужно кодить. Готового механизма нет.
  5. нет. Потому что элемент не принадлежит никакому листу. Это список знает, что при удалении элемента нужно сделать ему Free / заNil-ить ссылку на элемент. Только список. Сам объект (элемент списка) не подозревает о том, что он кому-то там "принадлежит".
  6. Не, оказывается я ошибся еще больше. Чтобы окончательно выяснить - залез на https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms644906(v=vs.85).aspx USER_TIMER_MINIMUM (0x0000000A), - минимально возможный интервал = 10мс. Но это недостижимый идеал :)))
  7. Графические движки не пользуются таймерами, это чревато гигантскими лагами. QueryPerfomanceCounter и т.п.
  8. Ни одна операционная система (за исключением систем реального времени) не обеспечит вам такую точность. Среда разработки здесь ни при чем. Совсем. К примеру, на Windows минимально возможный интервал таймера, емнип, 55мс. При этом нужно понимать, что событие таймера сработает только тогда, когда главный поток не будет ничем занят. А это, поверьте, случается достаточно редко. Грубо говоря - событие отработает "по остаточному принципу". Т.е. в реальности даже 55мс на Windows будет обеспечено далеко не всегда. Что уж говорить про мобильные платформы. Вам нужно пересмотреть алгоритм работы.
  9. kami

    webbrowser

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

    Парсинг XML файла

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

    Компиляция под IOS

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

    ancestor "object" not found

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

    TWebBrowser вместо кучи TEdit

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