haword

Думаю логично было бы присвоить TLabel.Font значение параметра TLabel.ResultingTextSettings.Font в рантайме что бы TLabel.Font всегда указывал на актуальный шрифт и его размеры используемые для показа текста. И не очень логично оставлять там не актуальные значения заданные в дезайнтайме которые изменились стилем после запуска программы, потому что это приводит к ошибкам если человек не в курсе таких хитросплетений.

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

ну да я так и думал

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

а пробовал на ipad который ретина запускать? или на 6 огрызке у которого разрешение побольше? я так понимаю картинки сделаны под один телефон с одним разрешением? я не к тому что ты типа что то там не правильно сделал. просто интересно. я тоже хотел пойти таким путем. но на гриде с кучей ячеек и строк. там каждая ячейка которая должна была прорисоваться преобразовывалась в картинку а потом показывались только картинки. стало на компе очень плавно скролиться даже когда грид разворачивал на весь экран. НО памяти стала программа отъедать под 400 - 500 метров. на андроиде с начало показывало нормально, первый экран но как память при скроле забилась, стали на картинках артефакты появляться всякие в виде цветных полос и точек. А так как грид был не статический то просто картинками с диска там не обойдешься ибо в него нужно было вбивать пользователям свои данные. как то так. посему данную задумку закопал

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

размер экрана 2048х1536, сколько памяти уйдет на хранение картинок для базы в 2-3000 записей по 20-30 полей в каждой? пробовал я это делать на дбгриде. но как увидел что памяти жрет сие решение не меряно и при большой количестве записей может вообще выкинуть из-за недостатка оной, особенно на устройствах с 512 памятью, то отказался от этого. слегка подлагивает да и хрен с ним за то памяти не жрет.

я имел ввиду что скорость не сравнить с VCL гридом. а если скорость не выше то зачем городить огород? я VCLный DBGrid переделал под FMX. очень я бы сказал печальное зрелище было листать туда сюда страницы с текстом по сравнению в VCL. VCL использует WinAPI и там все летает. FMX использует DirectX и все тормозит. Если бы сделали обертку к WinAPI как к DirectX тогда бы FMX летать начал под виндой.

то же сам писал но не устроило скорость работы а листвью пока устраивает

как опция за дополнительную плату

все просто. у тебя на винде шрифт 12 вот все и красиво рисуется ибо ты подобрал высоту итемов. под андроидом шрифт идет 16 если не задаешь по умолчанию по моему, вот текст у тебя и не влезает и переносится, а где переносится рисует вершки от новой строчки. тут или обработку вешаешь и увеличиваешь высоту итемов сам руками, либо задаешь шрифту размер руками.

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

в примерах есть пример как делать в listview свои поля

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

XE7 upd1. Под андроидом в рантайме эти параметры разливаются. Это фича или баг? Просто уперся в вычисление высоты метки. Долго не мог понять почему не правильно вычисляется. Поковырявшись в параметре AutoSize понял что там данные о шрифте берутся из ResultingTextSettings.Font а не из Font. Если контрол загрузил стиль в котором размер шрифта отличается от стандартного по умолчанию то Font остается по умолчанию хотя размер шрифта выводимый контролом соответствует загруженному из стиля как я понял. Если это так то это не удобно. Так как по правильному параметры шрифта загруженные из стиля должны отображаться в Font когда стиль загружен или те которые были установлены на самом контроле вручную. Короче реальный размер и название шрифта. Или я что то не понимаю и ошибся где то?

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

во во изменений на уровень сервиспака зато покупать как новую версию будут люди

в xe8 вроде как нет такого функционала. в 9 что выйдет осенью может быть появится а может быть и нет.

не знаю как в сях но на паскале все было бы проще try showmessage(StrToFloat(t)) Caloryy[i][u] := StrToFloat(t); except on e: exception begin showmessage(e.message) end; end; и все

правильно. код на пскале собирается в библиотеку а ява клас только для запуска и выполнения некоторых фукнций запрашиваемых из этой библиотеки и все.

скорее всего в функцию передается вся строка вместе с двоеточиячми и точками вот и вылет. оберни эксцепшеном и посмотри что там выдаст.

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

ну вот, прыгая с бубном вокруг программы и напевая хэя хэя хэя достучался то решения проблемы. вернее даже не решения а костыля для моих нужд. Нафига так делать не понятно но программисты обезьяны сделали. При активации любого сенсора, в менеджере сенсоров происходит активация и создание классов для ВСЕХ имеющихся сенсоров. И некоторые сенсоры уводят процессор в 100%. так вот на моем телефоне + эмуляторе достаточно отключить создание сенсоров TAndroidNativeLightSensor TAndroidNativeMagneticSensor TAndroidNativeProximitySensor в процедуре Activate класса TAndroidSensorManager в файле System.Android.Sensors.pas и закинуть к себе в проект и вуаля, нагрузки на процессоре нет.

TLocationSensor а не TLocationServer Андроид. При при запуске все хорошо, при активации сенсора для отображения координат загрузка процессора уходит на 100% на одно ядро, на эмуляторе так же. Пример из самой студии Location Demo. Можно что то сделать с этим? При этом при деактивации нагрузка на процессор не падает. Для просмотра нагрузки включал в параметрах разработчика показывать нагрузку на cpu.

у меня телефон на mtk с осью 4.1.1 - все работает. попробуй обновки с офсайта скачать если есть и проверить.