haword

шрифт в листвью может попробовать другой поставить?

не скажи. на 7 делфи можно было писать код для CLX и он работал. этот же код просто перекомпилируешь под Kylix и он работал. мне нравилось. а внутрь реализации FMX не смотрел? там тоже много чего реализовано на сообщениях - TMessage используется очень часто. Все проблемы решаемы. И костыли так же. За то проблем с переходом бы не было, а это огромный плюс к развитию платформы. А это новые компоненты и так далее. Да и херн с этими TMessage, можно же было реализовать СОВМЕСТИМЫЕ параметры и методы? МОЖНО! Сделали? НЕТ! да и что дал подход нового фреймворка? НИЧЕГО!! Под FMX за все время его существования написано столько компонентов что их можно просто по пальцам пересчитать!!! за 5 лет существования!!! А если бы людям не пришлось с нуля переписывать свои программы тогда как бы это все обернулось? Тогда бы новая платформа получила свою путевку в жизнь. Все зависит от популярности продукта. Когда продукт малопопулярен он долго не живет. Да и этот подход использован в Лазаре, да они правят косяки НО один и тот же код работает везде и при этом по максимуму совместим с Делфи. При этом интерфейсы были реализованы и для QT и для GTK1 и GTK2 и Cocoa и были попытки под Android сделать. При этом все это делалось на голом энтузиазме.

Изначально мне не понравилось в fmx то что он не был совместим с vcl никак. То есть разработка ПО на fmx это равносильна разработке нового ПО на новой оболочке. Зачем сделали новые компоненты не совместимые со старыми добрыми датасетами и датасоурсами и перешли на ливбилдинг? То есть хотели хорошо а сделали как обычно через жопу. Что трудно было оставить и то и добавить новое а так же большинство параметров сделать совместимыми не обзывая одно и то же разными названиями? Главный упор надо было делать на tcanvas и его совместимость с vcl. Как в свое время делали на clx. Вот там перенос компонентов занимало минимум времени и работало на линуксе. Вот и выход же. Многие свои компоненты перенесли бы на fmx тогда если бы база была совместимой. То есть если бы был гибрид clx fmx совместимый с vcl тогда бы все намного лучше взлетело бы! Это же простые истины программиста - работает НЕ ТРОГАЙ!!! Работают все на vcl так сделай совместимым с ним прокладку под другие платформы и будет счастье, так нет же, на те вам не совместимый продукт, пользуйтесь, радуйтесь. Не перешли на него и не стали переписывать все свое по заново? Ишь какие плохие программисты. Не хотят с нуля все переписывать. А вообще линукс для делфей несчастливая платформа. В 7 сделали, работало!!! Борланд накрылась. В сиетле сделали вроде все работает под андроидом замечательно, анонсировали переход под линукс и писец, контора начала разваливаться, всех поувольняли.

а вот если не грохать в потоке то будут глюки. на другом моем аппарате с 6 андроидом такого нет. показывает все отлично без глюков и без потока.

да. освобождаю память. и создается он только тогда когда он не был создан. то есть один раз всего при показе когда поток не грохает его.

хз. если запущен поток очищающий картинки то никаких глюков нет сколько бы картинок не грузил. если поток не запущен то примерно после 100 начинаются глюки. а загрузка из БД обычная. procedureUpdateItemImage(AItem: TListViewItem); .... bmp:= TBitmap.Create; q:= TFDQuery.Create(nil); q.Connection:= dm.DBCon; q.SQL.Text:= 'select im.Image ' + ' from imagestorecipe itr ' + ' left join images im on' + ' im.imageId = itr.imageId' + ' where' + ' itr.recipeId = ' + IntToStr(AItem.Data['r_id'].AsInteger); try q.open; except end; if not q.Eof then begin BlobStream := q.CreateBlobStream(q.FieldByName('Image'),TBlobStreamMode.bmRead); try bmp.LoadFromStream(BlobStream); if bmp.Height > bmp.Width then bmp.Rotate(90); FitRect := TRectF.Create(0, 0, bmp.Width, bmp.Height); FitRect := FitRect.FitInto(TRectF.Create(0, 0, 80, 40)); AItem.Bitmap:=TBitmap.Create; AItem.Bitmap.Width:=80; AItem.Bitmap.Height:=40; AItem.Bitmap.Clear(TAlphaColors.Null); if not bmp.IsEmpty and AItem.Bitmap.Canvas.BeginScene then try AItem.Bitmap.Canvas.DrawBitmap(bmp, TRectF.Create(0, 0, bmp.Width, bmp.Height), FitRect, 1); finally AItem.Bitmap.Canvas.EndScene; end; finally BlobStream.free; end; end; bmp.free; q.Free;

проблема не в том что битмапы не очищаются при очистке ListView, проблема при добавлении картинок в уже готовый список. Может конечно и дело в коде но код такой, при добавлении картинки если она не была загружена считываю картинку с БД, уменьшаю до маленького размера, делаю ListViewItem.Bitmap:=TBitmap.Create далее в него загружаю эту картинку и так далее. и при пролистывании около 100 картинок лезли глюки, даже если я не изменял количество итемов в ListView. Просто скролил вниз список. Было ощущение что где то лез out of memory и это вызывало глюки отображения. Пришлось ваять поток отдельный который будет бегать по списку добавленных ListViewItem и проверять видим ли он на экране, если нет то его Bitmap очищаю и из списка удаляю ListViewItem. Читал как это делается в андроиде, там классно сделали. При событии скрола есть параметры первый видимый итем, количество видимых, и общее количество итемов, а при изменении статуса скрола параметр указывающий на то что это, идет скролинг, начался или закончился. и от сюда куда удобнее получать видимость итемов и пихать в него картинки и удалять без бубнов .

в той демке удаления нет картинок при потере видимости. а это надо ибо на моем другом тестовом аппарате на 4.1 андроиде при загрузке около 100 картинок все начинает дико глючить, картинки не прорисовываются или рисуются вообще поверх всего.

у меня загрузка картинок идет из БД, поэтому приходится самому добавлять при отрисовке или с базы или с кеша если есть на диске, и удалять в отдельном потоке картинки если итем не в области видимости.

а вот обычный ListView в моей проге, с программой записи подлагивает без нее все летает плавно. ибо картинки кешируются на диск и как item пропадает из видимости картинка зачищается. как item становится видимым подргужается с диска.

ну хотя бы вот письками мериться не буду, телефон не топовый, средний, проц Snapdragon 410

использовать плавающие панели с html текстом вместо прорисовки колонок это извращение. при этом хз как это все себя поведет при 500 панелей. ну и стоимость сего добра то же не малая.

чем FMX будет в случае работы с API OpenGL отличаться от делфи? да ни чем. Я думаю можно сделать таку штуку и на FMX. надеюсь не последует следующий стандартный вопрос в таких случаях - а есть исходный код похожей готовой программы

не включается это программно из-за безопасности.

без сервиса никак. но проблема в том что не все включают блютуз что бы батарею не жрал. у меня он вообще всегда выключен.

если на бильдере нет сервисов может проще сделать было бы все на делфи и не парится? а вообще такие вещи лучше писать на андроидстудио.

в год

хе а я успел на халяву скачать только смысл в этой пустышке? все что нужно надо приобретать отдельно. апгрейд до профи 1300$. при этом мобильное дополнение покупается отдельно, работа с базами отдельно.

ну словесное описание каждый может сделать, кто бы куском кода помог )))

ну где ссылка на тему где можно насчет картинок потрындеть? понравилось. на чем ты сделал список в два три ряда картинок с вертикальным скролом? новый компонент на листвью или на скролбоксе с панелями замутил? колись я то ж хочу такое сделать. у меня картинки из базы данных грузятся и лагают.

ссылка на обсуждения? если про тот хелпер к битмапу то я не о том как загрузить, я о том что код запущенный под тасками валится и программа выгружается. а без тасков выполняется нормально хотя все обернуто анонимными вызовами как и в хелпере. да и кстати в том же примере с хелпером к битмапу если картинок много скролинг тормазит у листвью даже на винде.

я про таски а не про потоки. в тасках нет этой функци. и насчет OnTerminate - я так же заметил не здоровую фигню - создание 10-20 потоков очень сильно затормаживет основную систему. именно создание. никакой плавности нет при прокрутке. так что лучше это делать внутри потока а не снаружи. хотя если потоков один или два то как выход.

я пробовал таски запускать на андроиде, у меня программа веля себя как то не корректно. я пытался в тасках запускать заполнение картинками итемы листвью. прога запускалась, что то там начинала делать и вываливалась. если я убирал таски и использовал вызов процедуры без потока то все работало замечательно и без глюков. я так понял работа на андроиде с таками глючит.

еще бы хорошо было бы увидеть небольшой стек вызовов от куда произошел сбой было бы вообще замечательно.

установить макось 10.10 и туда икскод 7.2. если конечно получится