RoschinSpb

Зря только начал с упоминания TImageList. Подозреваю, что начнут его чинить и в результате испортят.

03.06 и 10.06 у меня назначены пьянкиответственные мероприятия в других местах. Кстати напомню, что в прошлый раз кроме упомянутых личностей пришел только один человек.

Я так понимаю нужно реализовать Ад перфекциониста.

1,2 - нет 3-4. зависит от реализации. Графика за границами видимой области рисуется быстрее, но там выполняется и другая работа не связанная с рисованием. TScrollContent это составная часть TCustomScrollBox тут нельзя выбрать одно, или другое. Ну ... рекомендации, если уже решили писать свой собственный компонент, конечно, не используйте ни то не другое. Наследуйтесь от TControl, поскольку Вам не нужна совместимость ... но Вы об этом пожалеете. Вообще же графика рисуется очень медленно на мобильных платформах, радикально быстрее будут рисоваться нативные контролы. Для IOS была сделана нативная реализация TGrid, и там выигрыш в скорости значительный, хотя не все возможности стилевой реализации были поддержаны. В Berlin`е можно посмотреть. Если интересно посмотрите мои наброски... Grid.zip

Про свою, я вообще молчу. Да технически всё понятно, при записи в поток и обратно получаются не идентичные результаты. Проявляется это в редакторе имажелиста потому, что там это происходит чаще чем везде. Там постоянно устанавливается свойство Dormant.

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

Не может, а точно. А баг не заметили потому, что проявляется далеко не на всех картинках. Как я понял только на одном, или нескольких оттенках серого (Ц). Это на сколько я понял из-за того, что при записи TBitmap в поток и последующем восстановлении данные получаются не совсем идентичными. Вот например если эту процедуру запускать несколько раз, то картинка становится клетчатой procedure TForm2.UpdateBitmap(var Bitmap: TBitmap); var Stream: TMemoryStream; begin if Bitmap <> nil then begin Stream := TMemoryStream.Create; try Bitmap.SaveToStream(Stream); FreeAndNil(Bitmap); Stream.Position := 0; Bitmap := TBitmap.Create; Bitmap.LoadFromStream(Stream); finally FreeAndNil(Stream); end; end; end; Вот, что у меня получилось. Вторая картинка (для сравнения) преобразуется точно также, но как видно не портится. Так что проблема не в TImageList и не в TImage, а где-то на более глубоком уровне. Добавляю также небольшой демо проектик. Проверял на Windows 10. Интересно что будет на других платформах. Proj.zip

А, вот! На сиэтле. Да, странная картина, еще более странно, что ни кто не замечал такого поведения.

Если нажать Export, то в полученном файле тоже сетка будет? Если сделать двойной клик по Selected Image, появится Multires Bitmap Editor, на нем тоже будет видна сетка?

Да, всё гораздо веселее чем я описал в первом приближении.

Не, это геморрой старый. Наличие подсчета ссылок ни как его не уменьшает. Решается он путем TComponent.FreeNotification. Вся "прелесть" решения в том, что Free работает не так как раньше работал Free, а DisposeOf теперь работает так же как раньше работал Free. На десктопных платформах всё как раньше, а вот на мобильных, надо помнить, что за каждым углом тебя поджидает ARC с дубиной. FreeNotification и ARC по сути два разных механизма для решения одной проблемы, которые частично дублируют друг друга, частично конфликтуют, как два антивируса на одном компе. кактотак

Согласно учениям великого кормчего Allen Bauer, использование счетчика ссылок это великое достижение мировой цивилизации и гигантский шах человечества на пути ко всеобщему счастью. По этому всегда и везде надо использовать Free или FreeAndNil. Но при этом не забывать про сильные и слабые ссылки. Чаще всего, если какое-то поле класса — экземпляр объекта который создается и разрушается строго внутри этого класса, то это сильная ссылка (по умолчанию), если поле нужно только для хранения ссылки на некоторый внешний экземпляр объекта, то эта слабая ссылка (должна быть директива [weak]). Это нормально работает когда, например объект A хранит ссылку на объект B, но при этом B ни чего не знает про A. type TA = class private [weak] FB: TB; public constructor Create(B: TB); Если не поставите [weak], Вы не сможете удалить объект B до тех пор пока не удалите объект A, либо не обнулите поле FB (а вы его не обнулите, поскольку это приватное поле). Разумеется контроль weak`ов остается на совести программиста. Т.к. формально утечек памяти нет, ссылка-то есть а объекте A, и в момент завершения работы приложения, объект А, и объект B обязательно "честно" удаляться. Просто объект B будет тихохонько сидеть в памяти и ни кого не беспокоить (правда удобно :o) Проблема наступает, если вдруг вам посчастливилось и в объекте B сделать ссылку на объект A. Тогда конечно вы не сможете удалить объект A пока не удалите объект B (см. предыдущий абзац). Обычно всё можно списать всё на "кривость" архитектуры и необходимость исключить перекрестные ссылки. Но вот беда, таких мест, где A ссылается на B, а B ссылается на A очень много, на этом основана вся компонентная архитектура Delphi, на которую ни кто особо не жаловался предыдущие 20 лет. Каждый компонент содержит ссылку на Owner, а Owner содержит список ссылок на все компоненты, которыми владеет. Вот чтобы как-то можно было удалить какой-то компонент придуман метод DisposeOf, он разрушает объект игнорируя все "прелести" счетчика ссылок. Это конечно не эстетично, зато надежно, дешево, практично. Так что вывод такой, что везде, где возможно делаем Free и [weak], а где невозможно DisposeOf.

Есть еще стандартные окна диалога InputQuery и т.п.

Вы уверены, что это хорошая идея? Когда много уровней вложенности есть хороший шанс вообще не увидеть веток дерева. В какой-то версии TTreeView исправлялся так, чтобы текст не обрезался. А Вы хотите вернуть такое поведение назад? Item1 SubItem1 SubItem2 SubIte SubI Su ...

При первой загрузке фотографии уменьшайте её до адекватных размеров допустим 64x64. Полученную миниатюру добавляйте в ImageList. Для сокращения использования памяти присвойте свойству Dormant значение True. Увеличте значение CacheSize, так, чтобы оно было немного больше количества одновременно видимых картинок.

Всё правильно, только тут речь идет о политике IDERA. От Embarcadero осталось одно название (в прямом и переносном смысле). Арфы нет, возьмите бубенпопробуйте нативный грид под IOS, должон перемещаться плавнее

Ломать не строить, здесь нет ни каких сложностей. TImageList содержит две коллекции Source и Destination. Удаляете из них Item`ы как из обычных коллекций TCollection с помощью методов Delete и Clear. В Source находятся сами изображения, в Destination ссылки на Source. Если удалите только из Source, то в нумерация изображений не поменяется и останутся пустые элементы, хотя расход памяти уменьшится. Если удалите только из Destination, то нумерация картинок съедет, и расход памяти почти не изменится. Каждый элемент Destination может содержать несколько ссылок на Source это коллекция Layers, из которой точно также можно удалять элементы.

Я уже писал о том, что так оно и есть, и дважды приводил примеры которые это демонстрируют. Если бы это было не так, новый элемент просто не смог бы добавиться. procedure TForm2.Button1Click(Sender: TObject); begin // Добавляем новый элемент в колекцию ImageList1.Source // И присваиваем тексту кнопки имя свежесозданного элемента Button1.Text := ImageList1.Source.Add.Name; end; vSource := Self.Source.Add; // Здесь безо всякого Tag имеем уникальное имя vSource.Name if AName <> '' then // Если задали какоето своё имя AName то, присваиваем его, если такое имя уже есть, получаем исключение vSource.Name := AName; // Если не задали своё имя оставляем как есть // В любом случае дальше используем vSource.Name Но, как я понял, мои ответы отправляются в пустоту без попыток осмысления...

Еще раз обращаю внимание: обязательный идентификатор инициализируется значением по умолчанию. Если не видите в нем смысла (это вовсе не значит что его нет), ни кто Вас не заставляет его использовать, по сути он и является опциональным. function TImageListHelper.Add(aBitmap: TBitmap; const AName: string = ''): integer; ... begin ... vSource := Self.Source.Add; if AName <> '' then vSource.Name := AName; Использование Tag мало того, что просто дурной тон, оно еще и лишнее и снижает базовую функциональность. С тем же успехом спрошу, а при чем здесь StringList, здесь больше уместна аналогия с TComponent.Name. Я Вам привел конкретные примеры зачем оно может использоваться (а может и не использоваться). Вы приводите гипотетические версии, что можно было бы сделать, конечно можно всё, можно даже заполнять список рандомными данными, но какой в этом практический смысл. И вообще мне странно, что Вы сначала жалуетесь, на излишнюю сложность и уже на следующей строке перекладываете на программиста куда более сложную задачу (формировать отдельные списки/структуры). В подавляющем большинстве случаев пользователь формирует коллекцию в DesignTime и не углубляется в дебри. Если же речь идет о динамической загрузке, это почти всегда что-то нестандартное, тут уже возможны всякие варианты (заменять, поднимать исключение, делать еще что-нибудь, не делать ни чего), но почти всегда важно застраховаться от повторной загрузки, или случайного перетирания одного изображения другим. И здесь могут помочь "человеческие" названия. В сложном приложении порядок загрузки может легко и непринужденно поменяться.

Përdorni specializuar përbërës, për të shfaqur të bazave të të dhënave. Nëse Ju provoni për të ngarkesës të gjitha foto, atëherë ju nuk keni të mjaftueshme burimet e sistemit. TGrid komponent i mban në kujtesë vetëm ato imazhe të cilat janë të dukshme në ekran. Shikoni një shembull që ju lejon për të shfaqur imazhe nga dataset. http://docwiki.embarcadero.com/CodeExamples/Berlin/en/FMX.GridDemo_Sample TDataSet duhet të përmbajë një fushë TGraphicField. Prona BlobType duhet të jetë vendosur për të ftGraphic. Ju duhet të lidhin atë me tabela, duke përdorur LiveBinding

Это смотря какая идея. В некоторых случаях уместно заменить, в некоторых это неуместно, или недопустимо. Например у Вас процедура инициализации (которая загружает сотню картинок) в процессе долгой разработки она перемещалась из OnShow в OnCreate потом в OnActivate где-то забыли удалить вызов и теперь эта процедура вызывается два раза. Допустим в приложении появилась вторая, третья, N+1 форма. Я не знаю отнаследовалась она, или просто скопипастилась, или Вы что-то добавили в Design-Time, так или иначе есть ненулевая вероятность получить неоднократное добавление одного и того же. Ситуация ошибочная и хорошо бы как-то об этом узнать, такая вот идея у меня была. В Вашем случае и не заменит и не предупредит об ошибке, т.е. потенциально имеем утечку ресурсов. Вы бы смогли догадаться, что изображено на этих картинках без доп. описания? Картинки конечно неважные, но в коде-то Вы их вообще не видите. В итоговой коллекции обращение идет всё равно по номеру, потому, что соображения совместимости важнее удобства, но во всяком случае есть возможность найти картинку по человекопонятному описанию например: ImageList1.Source.IndexOf('я'); ImageList1.Destination[0].Layers[0].Name; Надеюсь, я внес некоторое понимание. Кстати, при добавлении новой картинки по умолчанию у неё и так имеется уникальное имя вида "Item 0", "Item 1" и т. д. procedure TForm2.Button1Click(Sender: TObject); begin Button1.Text := ImageList1.Source.Add.Name; end;

Использование Tag, как бы намекает Не стоит скрывать свойство TCustomSourceItem.Name от пользователя, пусть сам заботится об уникальности (не такая уж это большая проблема). Это свойство может быть использовано для предотвращения случайной повторной загрузки, допустим если есть картинка с указанным названием поднимать исключение. На случай, если нужно заменить имеющуюся картинку, можно добавить метод AddOrReplace. Успехов

Может это онa?

Во-первых RoschinSpb попросит передать горячий и пламенный привет в QC. Во-вторых, если Вы создаете свой собственный стиль, то лучше бы соблюдать стандартную структуру стилевых объектов FGlyphObject это, как не сложно догадаться, стилевой элемент 'glyph'. Он содержит галочку и картинку. Возможно также что картинка будет располагаться не поверх галочки (как в Windows), а рядом с галочкой как в Mac. В этом случае glyphstyle будет расположена не внутри glyph, а рядом. В-третьих, если Вам просто требуется использовать ImageList, то нет смысла создавать свой стиль. Если Вы тренируетесь в создании стилей, то надо изучать соответствующий раздел и, скорее всего, исходники тоже.