xenon54

http://docwiki.embarcadero.com/Libraries/XE6/en/FMX.Types.TInteractiveGestureFlag первая ссылка в гугле

1. В исходниках найти где отрисовка селектбл итема ну и не отрисовывать выделение. 2. Изменить стиль выделенного итема

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

Под IOS такого нет. Просто так приложение никогда не вываливается. Все вылеты всегда связаны с ошибками пограммиста. Каждый раз когда натыкаюсь на вылет или что-то подобное, после разбора полетов становится понятно, что это не какое-то мистическое поведение, а банальные ошибки или не знание каких-то нюансов.

Item.StylesData['mybtn.OnClick'] := TValue.From<TNotifyEvent>(Domybtnclick);

Создаешь TStringList, сделал дело, добавил строку с сообщением что сделал, записал в файл, сделал еще 1 действие записал в файл TStringList.SaveToFile. Потом когда приложение завалится смотри на чем остановилось последний раз.

Вводите логирование в файл и отслеживайте на чем зависает приложение.

Мб утечки? На пустом приложении с листвью тоже самое?

Ну естественно они все в памяти висят. Ты создаешь считай объекты типа TBitmap методом LoadFromFile выделяешь память под размеры этой картинки. И пока этот битмап не уничтожен(а пока твой список существует, все битмапы живут), выделенная память под него будет занята. Этот момент уже не единожды обсуждался. Лично мое решение это при скроле листвью тебе нужно определять какие итемы сейчас находятся в области видимости и только для них держать картинки в памяти, т.е. ты должен при скроле динамически подгружать/выгружать картинки. Если размеры картинок небольшие, то думаю что проблем возникнуть не должно. Так же, если у тебя там картинки больших размеров чем реальные битмапы, то лучше используй не LoadFromFile, а LoadThumbnailFromFile.

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

Тупо деплою нужные файлы в проект и проблем таких нет.

Да, приложение перестало вылетать.

Загружая картинку в TBitmap она хранится там именно как PMB и занимают {censored} сколько места. Сам не понимал почему у меня приложение на IOS без конца вылетало, потом глянул сколько памяти уходит при загрузке изображений и {censored}. Много гуглил, но так и не нашел нормального решения этого вопроса. Приходится хранить в памяти только те картинки которые реально нужны здесь и сейчас.

http://fire-monkey.ru/topic/950-xe7-ios-vazhno-vladeltcam-xe7-ne-obnovliat-ios-do-versii-813/ В версии 8.1.3 изменился запуск приложения.

бета

procedure TForm1.Button1Click(Sender: TObject); var http: TIdHTTP; formData: TIdMultipartFormDataStream; begin http := TidHttp.Create(nil); try formData := TIdMultipartFormDataStream.Create; try formData.AddFile('SendFile', 'C:\test.txt', 'text/plain'); formData.AddFormField('action','upload_file'); http.Request.ContentType := 'multipart/form-data'; http.Post('http://test.ru/test.php',formData); finally formData.Free; end; finally http.Free; end; end; PHP: <? $files_uploaded = 1; foreach ($_FILES as $key => $value) if (move_uploaded_file($_FILES[$key]['tmp_name'], "./uploads/{$files_uploaded}.jpg")) $files_uploaded++; Папка "uploads" должна быть создана заранее или программно.

Там же есть четкая инструкция по установке: Вы все действия выполнили?

Я сейчас попробовал, симуляторы реально не меняются, но поменяв SDK на 7.1 и указав симулятор например iphone5 он запускается на симуляторе 7.1, а не 8.1.

Если нажать сюда, то произойдет обновление устройств(симуляторов) такое же как если бы нажать в контекстном меню, в это время даже на папочке таргет загорается картиночка "рефреш"

Ну в общем-то стало понятно что мы до сих пор о разном. Судя по вашему сообщению,вы думаете, что у меня все итемы это какие-то мифические картинки. У меня точно такие же итемы как и в ListView. Точно также в них есть текст и картинка слева. И "список клиентов, и информацию о клиентах и список товара, и информацию о товаре, и документы и информацию о документах" - это все текст. Картинкой в итеме является только картинка, которая слева. К примеру список людей: слева маленькая фотка сотрудника, а справа (ФИО, возраст, цвет трусов) это текст, а не картинка.

На ipad не пробовал. Картинки не сделаны под какойто телефон, изначально они на телефоне лежат с разрешением 1024х768, просто загружаются в битмап он ине loadfromfile, а loatThumbnail, соответственно и памяти кушает в 10 раз меньше. Далее. Есть по-моему огромная разница замостить картинками целый ДБгрид на всем экране или по одной картинке в каждый элемент списка, как минимум разница во столько раз, сколько колонок в ДБГриде. Насчет поедаемой памяти вообще вас не понял. Контрол держит в памяти только столько картинок, сколько итемов видно, а это всегда величина постоянная и небольшая с учетом загрузки миниатюр, а не гигантов реальных размеров. ДБГрид и список - огромная разница в этой реализации ибо у списка в момент скрола если появляется новый элемент в области видимости, то загрузить нужно всего 1 картинку и выгрузить 1, а в гриде много картинок одновременно надо подгружать удалять. Ну и критиковать проще всего. У вас есть решение которое бы позволило иметь огромные списки в тысячу и более элементов с картинками и не вызывало out of memory? Проверю это решение на IPad2, если уж на этом говне будет нормально, то о чем еще говорить... А цели сделать этот список чтобы он хорошо работал у всех бомжей у меня нет, спасибо, хватил уже истории когда всем нужна была поддержка идиотского IE6. Думаю не стоит разработчикам 2 раза на 1 грабли наступать.

Картинки изначально уже лежат на устройстве. У каждого итема есть поле в котором хранится путь к файлу картинки. При скроле этого контрола каждый раз высчитывается какие итемы сейчас должны быть в области видимости. Дальше идет проверка, загружена ли в память уже картинка для каждого видимого итема ну и соответственно загружается или ничего не делается. Дальше вызывается Paint и в нем начинается рисование итемов контрола. Так что да картинки для итемов подгружаются и выгружаются на лету во время скрола. На андроидах не пробовал, пробовал на своем Iphone 5s. Ни малейшего лага нет, загружаются картинки моментально. Насчет размеров картинок. Не знаю как вы используете списки, но у меня задача отображать итемы с несколькими строками и слева картинка у каждого, в общем как и у стандартного ListViewItem'а. Высота итема у меня 60. Загружаются в итемы не какие-нибудь гиганты непонятных разрешений, а миниатюры картинок размером чуть большим чем высота итемов (90) для того чтобы было приемлимое качество картинки. Можете не верить, ваше право, но при скроле нет ни малейших дерганий или тем более зависаний (1000 итемов), скролится все плавно, в общем также как и ListView без картинок. По сути многое я подсмотрел у ListView, принципиальная разница лишь в том что если у контрола 1к итемов, то они не загружаются все в память. Да и шансов на то что приложение не вылетит при 1000 итемах и загруженных к ним картинках практически нет.

Я использую TControl.

То ли я вас не понял то ли вы меня. Я сделал так, что в памяти загружены только несколько картинок одновременно, а точнее ровно столько сколько видно итемов. Допустим высота контрола 1000, Высота итема 100. Так вот в памяти всегда загружено именно 11 картинок как бы вы не скролили вниз или вверх количество кушаемой памяти практически не меняется. Если итем не виден то картинка для него выгружается из памяти вообще. Ограничение такого подхода только в том что картинки для этого контрола должны храниться локально в файлах на устройстве.

Я делал для мобилок (ФМ). Скорость работы идеальная, ни единого притормаживания. На лету определяет какие итемы сейчас должны быть видны в контроле и подгружает картинки только для этих итемов. Пробовал запилить 1000 итемов с картинками внутри каждого итема, 0 лагов. Ну собственно и лагать не от чего, картинок загружено в память минимум, отрисовка всегда идет только видимых итемов. Хотя конечно и в ListView можно сделать тоже самое, просто устал постоянно ворошить исходники этого монстра (TListView) для того чтобы добавлять/менять свой функционал.