RoschinSpb

Загрузка картинки будет выглядеть примерно так.
procedure TForm11.Button2Click(Sender: TObject); const SourceName = 'Картинка'; procedure LoadPicture(const Source: TCustomSourceItem; const Scale: Single; const FileName: string); var BitmapItem: TCustomBitmapItem; TmpBitmap: TBitmap; begin BitmapItem := Source.MultiResBitmap.ItemByScale(Scale, True, True); if BitmapItem = nil then begin BitmapItem := Source.MultiResBitmap.Add; BitmapItem.Scale := Scale; end; BitmapItem.FileName := FileName; TmpBitmap := BitmapItem.CreateBitmap; try if TmpBitmap <> nil then BitmapItem.Bitmap.Assign(TmpBitmap); finally TmpBitmap.Free; end; end; var NewSource: TCustomSourceItem; NewDestination: TCustomDestinationItem; NewLayer: TLayer; begin if ImageList1.Source.IndexOf(SourceName) = -1 then begin NewSource := ImageList1.Source.Add; NewSource.Name := SourceName; NewSource.MultiResBitmap.TransparentColor := TColorRec.Fuchsia; NewSource.MultiResBitmap.SizeKind := TSizeKind.Custom; NewSource.MultiResBitmap.Width := 16; NewSource.MultiResBitmap.Height := 16; LoadPicture(NewSource, 1, 'D:\Мои веселые картинки\Icons\16x16\alarm16.bmp'); LoadPicture(NewSource, 1.5, 'D:\Мои веселые картинки\Icons\24x24\alarm24.bmp'); NewDestination := ImageList1.Destination.Add; NewLayer := NewDestination.Layers.Add; NewLayer.SourceRect.Rect := TRectF.Create(TPoint.Zero, NewSource.MultiResBitmap.Width, NewSource.MultiResBitmap.Height); NewLayer.Name := SourceName; ControlAction1.ImageIndex := NewDestination.Index; end; end; Здесь как видно грузится деве картинки 16х16 и 24х24, при этом используются масштабы 1 и 1,5. После загрузки меняется свойство ImageIndex у действия ControlAction1. Загруженная картинка должна автоматом появится на всех кнопках, которые используют ControlAction1.
 
 

Не ссоритесь девочки пож.
Возвращаясь к сути вопроса. Основная сложность тут в том, что в Delphi нельзя разрушать экземпляр класса внутри метода этого класса за исключением тех случаев, когда метод использует только для разрушения Free, DisposeOf. Почему так, а не иначе, какие есть исключения и почему "уменяфсёработает" объяснять долго, поэтому в первом приближении предлагаю принять это за аксиому.
Обработчики событий OnClick и пр. вызываются из методов классов, так что разрушать контрол внутри события нельзя от слова совсем. Кроме очевидных случаев типа Self.DisposeOf существуют более запутанные варианты, когда к примеру закрывает и разрушается форма, что приводит к разрушению всех дочерних контролов.
Образно говоря, самоубийства строго запрещены, но не запрещено нанимать киллера и в качестве жертвы указывать себя. Т.е. должен быть некий другой (глобальный) объект который будет разрушать объекты, которые хотели бы самоубицо. Реализацию такого объекта можете придумать сами, или использовать TPurgatory (чистилище, в католическом учении — промежуточное место между раем и адом). Но чтобы убедиться в правильности работы можно создать своего наследника TButton в котором перекрыть деструктор и поставить в нем точку останова. При запуске в режиме отладки посмотрите стек вызова деструктора (надо быть внимательным, он может быть длиннющим), ни где в этом стеке не должно быть метода разрушаемого экземпляра. Если в Вы нашли метод разрушаемого объекта (за исключением вышеуказанных), то Ваш способ удаления работает не правильно и с некоторой долей вероятности будет приводить к AV и другим "неприятностям" которые почти невозможно отловить в режиме отладки.

Не ссоритесь девочки пож.
Возвращаясь к сути вопроса. Основная сложность тут в том, что в Delphi нельзя разрушать экземпляр класса внутри метода этого класса за исключением тех случаев, когда метод использует только для разрушения Free, DisposeOf. Почему так, а не иначе, какие есть исключения и почему "уменяфсёработает" объяснять долго, поэтому в первом приближении предлагаю принять это за аксиому.
Обработчики событий OnClick и пр. вызываются из методов классов, так что разрушать контрол внутри события нельзя от слова совсем. Кроме очевидных случаев типа Self.DisposeOf существуют более запутанные варианты, когда к примеру закрывает и разрушается форма, что приводит к разрушению всех дочерних контролов.
Образно говоря, самоубийства строго запрещены, но не запрещено нанимать киллера и в качестве жертвы указывать себя. Т.е. должен быть некий другой (глобальный) объект который будет разрушать объекты, которые хотели бы самоубицо. Реализацию такого объекта можете придумать сами, или использовать TPurgatory (чистилище, в католическом учении — промежуточное место между раем и адом). Но чтобы убедиться в правильности работы можно создать своего наследника TButton в котором перекрыть деструктор и поставить в нем точку останова. При запуске в режиме отладки посмотрите стек вызова деструктора (надо быть внимательным, он может быть длиннющим), ни где в этом стеке не должно быть метода разрушаемого экземпляра. Если в Вы нашли метод разрушаемого объекта (за исключением вышеуказанных), то Ваш способ удаления работает не правильно и с некоторой долей вероятности будет приводить к AV и другим "неприятностям" которые почти невозможно отловить в режиме отладки.

Не ссоритесь девочки пож.
Возвращаясь к сути вопроса. Основная сложность тут в том, что в Delphi нельзя разрушать экземпляр класса внутри метода этого класса за исключением тех случаев, когда метод использует только для разрушения Free, DisposeOf. Почему так, а не иначе, какие есть исключения и почему "уменяфсёработает" объяснять долго, поэтому в первом приближении предлагаю принять это за аксиому.
Обработчики событий OnClick и пр. вызываются из методов классов, так что разрушать контрол внутри события нельзя от слова совсем. Кроме очевидных случаев типа Self.DisposeOf существуют более запутанные варианты, когда к примеру закрывает и разрушается форма, что приводит к разрушению всех дочерних контролов.
Образно говоря, самоубийства строго запрещены, но не запрещено нанимать киллера и в качестве жертвы указывать себя. Т.е. должен быть некий другой (глобальный) объект который будет разрушать объекты, которые хотели бы самоубицо. Реализацию такого объекта можете придумать сами, или использовать TPurgatory (чистилище, в католическом учении — промежуточное место между раем и адом). Но чтобы убедиться в правильности работы можно создать своего наследника TButton в котором перекрыть деструктор и поставить в нем точку останова. При запуске в режиме отладки посмотрите стек вызова деструктора (надо быть внимательным, он может быть длиннющим), ни где в этом стеке не должно быть метода разрушаемого экземпляра. Если в Вы нашли метод разрушаемого объекта (за исключением вышеуказанных), то Ваш способ удаления работает не правильно и с некоторой долей вероятности будет приводить к AV и другим "неприятностям" которые почти невозможно отловить в режиме отладки.

Не ссоритесь девочки пож.
Возвращаясь к сути вопроса. Основная сложность тут в том, что в Delphi нельзя разрушать экземпляр класса внутри метода этого класса за исключением тех случаев, когда метод использует только для разрушения Free, DisposeOf. Почему так, а не иначе, какие есть исключения и почему "уменяфсёработает" объяснять долго, поэтому в первом приближении предлагаю принять это за аксиому.
Обработчики событий OnClick и пр. вызываются из методов классов, так что разрушать контрол внутри события нельзя от слова совсем. Кроме очевидных случаев типа Self.DisposeOf существуют более запутанные варианты, когда к примеру закрывает и разрушается форма, что приводит к разрушению всех дочерних контролов.
Образно говоря, самоубийства строго запрещены, но не запрещено нанимать киллера и в качестве жертвы указывать себя. Т.е. должен быть некий другой (глобальный) объект который будет разрушать объекты, которые хотели бы самоубицо. Реализацию такого объекта можете придумать сами, или использовать TPurgatory (чистилище, в католическом учении — промежуточное место между раем и адом). Но чтобы убедиться в правильности работы можно создать своего наследника TButton в котором перекрыть деструктор и поставить в нем точку останова. При запуске в режиме отладки посмотрите стек вызова деструктора (надо быть внимательным, он может быть длиннющим), ни где в этом стеке не должно быть метода разрушаемого экземпляра. Если в Вы нашли метод разрушаемого объекта (за исключением вышеуказанных), то Ваш способ удаления работает не правильно и с некоторой долей вероятности будет приводить к AV и другим "неприятностям" которые почти невозможно отловить в режиме отладки.

Не ссоритесь девочки пож.
Возвращаясь к сути вопроса. Основная сложность тут в том, что в Delphi нельзя разрушать экземпляр класса внутри метода этого класса за исключением тех случаев, когда метод использует только для разрушения Free, DisposeOf. Почему так, а не иначе, какие есть исключения и почему "уменяфсёработает" объяснять долго, поэтому в первом приближении предлагаю принять это за аксиому.
Обработчики событий OnClick и пр. вызываются из методов классов, так что разрушать контрол внутри события нельзя от слова совсем. Кроме очевидных случаев типа Self.DisposeOf существуют более запутанные варианты, когда к примеру закрывает и разрушается форма, что приводит к разрушению всех дочерних контролов.
Образно говоря, самоубийства строго запрещены, но не запрещено нанимать киллера и в качестве жертвы указывать себя. Т.е. должен быть некий другой (глобальный) объект который будет разрушать объекты, которые хотели бы самоубицо. Реализацию такого объекта можете придумать сами, или использовать TPurgatory (чистилище, в католическом учении — промежуточное место между раем и адом). Но чтобы убедиться в правильности работы можно создать своего наследника TButton в котором перекрыть деструктор и поставить в нем точку останова. При запуске в режиме отладки посмотрите стек вызова деструктора (надо быть внимательным, он может быть длиннющим), ни где в этом стеке не должно быть метода разрушаемого экземпляра. Если в Вы нашли метод разрушаемого объекта (за исключением вышеуказанных), то Ваш способ удаления работает не правильно и с некоторой долей вероятности будет приводить к AV и другим "неприятностям" которые почти невозможно отловить в режиме отладки.

Я уже понял  Я просто курсовую дописываю и там чуть-чуть осталось. А так, я только на новых версиях теперь буду.

Используйте сразу Berlin, там есть пример как использовать DB Grid c набором данных.

XE3 + Fire Monkey -> даже не мучайтесь, во-первых мало что получится, во-вторых всё равно надо буде переделывать при переходе на следующие версии.

Индусы в основном из незалежной... :o)

Как я понимаю здесь не применим и GetSystemMetrics(SM_TABLETPC)<>0, т.к. в общем случае можно курсор двигать и с помощью мыши и с помощью пальца. Существуют обычные настольные мониторы с сенсорной поверхностью. Тут наверно нужно учесть, что пользователь обычно не водит пальцем по сенсорному экрану, а просто тыкает пальцем на контролы, исходя их этого допущения можно что-то придумать с подсказками.
Мой совет: лучше исхитряться в сторону использования стандартных высокоуровневых возможностей остаётся в силе 

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

Ну не стали они доводить до совершенства )
Гриды есть классные сторонние. Я от tms триаловские использую. Там по событиям без стилей меняется всё-всё.

Примерно так:
interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics; type TMyLabel = class(TControl) private FFontTextSettingInfo: TTextSettingsInfo; function GetTextSettings: TTextSettings; procedure SetTextSettings(const Value: TTextSettings); public constructor Create(AOwner: TComponent); override; destructor Destroy; override; published property LabelFont: TTextSettings read GetTextSettings write SetTextSettings; end; implementation type TMyTextSettings = class (TTextSettingsInfo.TCustomTextSettings) public constructor Create(const AOwner: TPersistent); override; published property Font; property FontColor; property HorzAlign; property VertAlign; // можно убрать ненужные свойства // property WordWrap default True; // property Trimming default TTextTrimming.Character; end; constructor TMyTextSettings.Create(const AOwner: TPersistent); begin inherited; WordWrap := False; Trimming := TTextTrimming.Character; end; constructor TMyLabel.Create(AOwner: TComponent); begin inherited Create(AOwner); FFontTextSettingInfo := TTextSettingsInfo.Create(Self,TMyTextSettings); // FFontTextSettingInfo.TextSettings.FontColor := TAlphaColors.Black; // FFontTextSettingInfo.TextSettings.OnChanged := FontChanged; end; destructor TMyLabel.Destroy; begin FFontTextSettingInfo.Free; inherited Destroy; end; function TMyLabel.GetTextSettings: TTextSettings; begin Result := FFontTextSettingInfo.TextSettings; end; procedure TMyLabel.SetTextSettings(const Value: TTextSettings); begin FFontTextSettingInfo.TextSettings.Assign(Value); end; end.  

Обрабатывать OnDblClick - это и есть изобретение своего велосипеда и выполнение того, что должен выполнять сам компонент. Все просто в простейших контролах типа кнопки, когда не предусмотрено ни какой другой логики кроме выполнения события. А вот для TSwitch не всё так однозначно, там поведение уже более сложное (можно его переключить сдвинув пальцем и это не будет кликом). В Grid совсем все сложно. Логика поведения навороченная и любая отсябятина её поломает с непредсказуемыми последствиями.
Клик произошёл. Так что выделена ячейка должна быть под точкой клика. А кто-то (и таких людей наберется не мало) может сказать, "по клику я хочу сам выделить ячейку ту, которую считаю нужной, а не ту на которую ткнул пользователь". Допустим в одном столбце картинка во втором значение и по клику на картинку я хочу выделить соседнюю ячейку с изменяемым параметром. Кроме того не факт, что под курсором оказалась "не задизабленая" ячейка, об этом должен не забыть подумать прикладной программист.
Скроллирование тут при том, нажатие и отпускание мыши (пальца) происходит примерно в рандомном месте (два раза). На нажатие-отпускание пальца реакция может быть разной, скроллирование может остановиться/замедлится/пойти в другую сторону, при долгом нажатии остановиться и выделиться ячейка.
OnCellDblClick ведь сериализировать нельзя на единый обработчик кликов. Так и да, сделать два обработчика вместо одного — воистину адская по сложности работа :o) Да и странно, что таблица реагирует на нажатие также как кнопка, хотя всякое бывает.

Если продолжить философские рассуждения,
то на контролах не должно было быть событий относящихся к аппаратным средствам. Потому, что на разных платформах может быть мышь, а может сенсорный экран что на первый взгляд похоже но не совсем одно и то же, а может быть и то и другое, кстати и в этом разобраться очень трудно. Должны быть события относящиеся именно к контролам, к примеру вместо OnClick на кнопкообразных контролах должно быть что-то типа OnExecute. Может кликнули мышью, может ткнули пальцем, может нажали пробел на клавиатуре, может сдвинули пальцем переключатель, может еще что угодно о чем нам знать не обязательно и за это отвечает контрол — но в итоге произошло нечто в результате чего мы должны выполнить некоторое действие.
Также и в Grid можно десятью способами реагировать на разные клики/жесты в разных местах на разных платформах (включая будущие). На сколько правильно остаётся на совести компонента. Прикладной программист обрабатывает события не вдаваясь в подробности о том, в результате каких манипуляций они произошли, но реализует логику работы о которой можно догадаться из названия или краткой справки. Например OnSelectCell - неважно что произошло в подлунном мире, но грид хочет знать можно ли выделить определенную ячейку. OnSelChanged - опять, ни кого не интересует каким образом это произошло, но выделенная ячейка поменялась. OnExecute - надо выполнить какое-то действие. OnAltExecute - надо выполнить какое-то альтернативное действие и т.п.
К сожалению изначально на эту тему не задумывались. Сохранили совместимость с виндовой VCL там, где этого не следовало делать. Зато поломали совместимость там где в этом не было серьезной необходимости
Caption -> Text;
Left, Top: Integer -> Position.X, Position.Y: Single;
Font.Color -> FontColor
А ведь если бы можно было VCL-ный dfm запустить на андроиде... не, это было бы конечно не так круто, как натянуть грид на грани вращающегося куба, но гораздо более востребовано на практике.

Потому, что Х3 как определить то, что находится в гриде под курсором (обычная ячейка, недоступная ячейка, редактор ячейки, заголовок, пустое место), особенно в момент скроллирования на телефоне где и мыши-то нет. И ХЗ когда менять выделенную ячейку до срабатывания события, после срабатывания события, после первого клика, или после второго. И ХЗ как реагировать самому гриду на клик, если пользователь сам уже что-то сделал...
Поэтому в дизайнер введены другие события например OnSelectCell, OnCellDblClick, которые срабатывают в таком порядке
OnSelectCell
OnSelChanged
OnCellClick
OnCellDblClick

Потому, что Х3 как определить то, что находится в гриде под курсором (обычная ячейка, недоступная ячейка, редактор ячейки, заголовок, пустое место), особенно в момент скроллирования на телефоне где и мыши-то нет. И ХЗ когда менять выделенную ячейку до срабатывания события, после срабатывания события, после первого клика, или после второго. И ХЗ как реагировать самому гриду на клик, если пользователь сам уже что-то сделал...
Поэтому в дизайнер введены другие события например OnSelectCell, OnCellDblClick, которые срабатывают в таком порядке
OnSelectCell
OnSelChanged
OnCellClick
OnCellDblClick

Потому, что Х3 как определить то, что находится в гриде под курсором (обычная ячейка, недоступная ячейка, редактор ячейки, заголовок, пустое место), особенно в момент скроллирования на телефоне где и мыши-то нет. И ХЗ когда менять выделенную ячейку до срабатывания события, после срабатывания события, после первого клика, или после второго. И ХЗ как реагировать самому гриду на клик, если пользователь сам уже что-то сделал...
Поэтому в дизайнер введены другие события например OnSelectCell, OnCellDblClick, которые срабатывают в таком порядке
OnSelectCell
OnSelChanged
OnCellClick
OnCellDblClick

Потому, что Х3 как определить то, что находится в гриде под курсором (обычная ячейка, недоступная ячейка, редактор ячейки, заголовок, пустое место), особенно в момент скроллирования на телефоне где и мыши-то нет. И ХЗ когда менять выделенную ячейку до срабатывания события, после срабатывания события, после первого клика, или после второго. И ХЗ как реагировать самому гриду на клик, если пользователь сам уже что-то сделал...
Поэтому в дизайнер введены другие события например OnSelectCell, OnCellDblClick, которые срабатывают в таком порядке
OnSelectCell
OnSelChanged
OnCellClick
OnCellDblClick

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

Да, мило. Как уже было сказано можно подгружать фотографии и в TImageList в RunTime, примеров тут есть.
begin   Button1.Images := ImageList1;   Button1.ImageIndex := ImageList1.AddOrSet('Add', [1, 1.5, 2],     ['D:\Мои веселые картинки\Icons\add16.png',      'D:\Мои веселые картинки\Icons\add24.png',      'D:\Мои веселые картинки\Icons\add32.png']); end; Тогда в отличие от TList будет автоматически разруливаться ситуация с большим количеством одновременно созданных TBitmap.
TBitmap это довольно ресурсоёмкий объект (отсюда и возможные ошибки с дескрипторами) их количество ограничено, особенно на телефонах, TImageList хранит данные хоть и в памяти но просто в виде двоичных данных (в формате PNG), при этом системные объекты создаются и уничтожатся по мере использования, максимальное их количество можно задать свойством CacheSize (должно быть не меньше чем максимальное количество одновременно видимых картинок на экране).

Любопытно было бы взглянуть на приложение которое работает на телефоне и грузит 50Мб картинок в кнопки во время старта.

Любопытно было бы взглянуть на приложение которое работает на телефоне и грузит 50Мб картинок в кнопки во время старта.

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

Форма должна иметь значение свойства FormStyle равное fsPopup. См. также Всплывающие формы в XE5