haword

о все понеслось, тупое упирание рогом и с пеной у рта доказыванием своей правоты. да мне пофигу что вы там думаете и как вы доказываете свою правоту. и вижу одно - fmx не взлетела так как от нее ожидали. для меня она проблемна тем что я не могу перенести на нее свои проекты с vcl. а раз так значит и популярность у нее будет минимальна, что и наблюдаем. можно усираться доказывать что новая платформа не совместимая с прежней это свет в окне и радость, но результат на лицо - не взлетело. почему я должен кого то там слушать и верить непогрешимо в то что кто то там сказал? я вижу одно - мне нужен был список товара, с его характеристиками, с фильтрами и сортировками по параметрам, и использоваться это будет в основном в ланшафтном режиме на планшетах. реализовать это не на гриде, это танцы с бубном и извращения. что бы там не говорили гуглевцы. не заливай, в том же офисе используются вкладки, выпадающие меню и тулбары. это все так же будет хорошо смотреться и на мобильных приложениях. от кучи немодальных окон уже давно избавляются все кому не лень. тот же делфи последний раз был таким в 7 версии а потом все в одно окно загнали.

То есть мелкософтцы смогли реализовать что ембаркадеровцы не могут? Это так сложно создать очередь сообщений? В FMX есть механизм рассылки и получения сообщений. И он работает под мобильными платформами. Так что все это решаемо, если есть желание. пример рассылки сообщения всем компонентам. работает кроссплатформенно. так что реализация есть. нужно только сделать. а почему нет? чем грид плох на мобильной платформе? мне его там серьезно не хватает. вместо того что бы реализовывать работу с сеткой на листвью через жопу все можно было бы сделать в гриде и не было никаких проблем!! Да и много ли программ показывают несколько окон рядом? я никогда такие интерфейсы не создавал да и не встречал что бы была куча не модальных окон и в них все смотрели. это очень малый процент ПО. так что не надо было бы ничего писать заново. большинство программ пошли бы с полпинка с минимальными переделками. вот ты упираешься типа все хорошо сделали. а результат твоей упертости? много кто перешел на fmx? практически никто. писать заново ПО под новую платформу которая и так на ладан дышит мало у кого желание есть. и как закономерный результат - 5 лет и 10 компонентов. конечно можешь и дальше упираться и доказывать что такой подход самый лучший и правильный, только вот исход этого виден - платформа FMX НЕ ПОПУЛЯРНА у разработчиков. За то 5 лет ее пытались развивать и двигать. Делфи за 5 лет с 1 версии доросла до 5 версии и дала очень хороший скачек в программирования и стала в то время очень популярной. Что сделал FMX? 20-30 человек на форуме которые используют это плюс примерно 10 компонентов которые более менее приличные. И то даже меньше. Вот тебе и результат такого подхода.

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

не скажи. на 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 потоков очень сильно затормаживет основную систему. именно создание. никакой плавности нет при прокрутке. так что лучше это делать внутри потока а не снаружи. хотя если потоков один или два то как выход.

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