RoschinSpb

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

Зря Вы TPurgatory угробили Простой пример: при потере фокуса закрывается всплывающее меню и разрушается всплывающая форма с этим меню, на OnClick всплывающего меню повешен обработчик, в обработчике возникает исключение которое приводит к появлению окошка с сообщением об ошибке появление окна с сообщением об ошибке закрывает и разрушает контекстное меню получается внутри метода объекта мы совершенно незаметно для себя уничтожили этот объект и на выходе из обработчика OnClick мы уже попадаем ... куда? В код разрушенного объекта. Может там остались старые данные и всё отработает нормально, а может там уже данные другого объекта, или еще какой мусор и приложение аварийно выкидывается из памяти. Как оно в итоге получится зависит от везения и фазы луны. Подобные ситуации могут возникнуть и в других, менее очевидных случаях. Так что будьте бдительны.

Постараюсь

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

Вообще много что поменялось в TGrid при переходе от 10.0 к 10.1. Процедура удалена за ненадобностью. Что конкретно Вы хотите чтобы было сделано? Для начала посмотрите, будет ли работать без неё.

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

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

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

Если всё прикладное приложение обвешивать директивами условной компиляции, то реально работать будет невозможно, не говоря уже о том, что в этом случае надо будет изучить апи каждой платформы. Поэтому лучше исхитряться в сторону использования стандартных высокоуровневых возможностей. Директивы условной компиляции обычно используются только для тех случаев, где действительно логика работы зависит от платформы: {$IFDEF MSWINDOWS} Caption := Caption + ' for Windows'; {$ENDIF} В данном случае проверять наличие значения Touch в Shift.

Подозреваю Shift содержал значение ssTouch GetSystemMetrics(SM_TABLETPC)<>0 На андроиде работает? Это я к тому, что если Вы привязываете работу только к Windows, то лучше пользоваться VCL это и проще и стабильнее и сторонних библиотек немеряно написано. А при использовании FMX не стоит использовать системные функции т.к. это уничтожит одно единственное достоинство Fire Monkey - кроссплатформенность.

Можно попробовать TListBox.AniCalculations.MouseWheel См. также Платформонезависимый скроллинг в Fire Monkey

Если всё сделать в одном блоке BeginScene EndScene, и без Application.ProcessMessages и Repaint не заработает? if panel.Canvas.BeginScene then try // рисовать всё finally panel.Canvas.EndScene; end;

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

Да, именно так, сам на это напарывался, даже вроде баг заводил. Понять это невозможно, это надо знать! Раздел Uses может добавиться автоматически, например по Ctrl+A и он добавляется после implementation и перед %CLASSGROUP.

Да. Во всяком случае так было в той версии которая у меня и которой я занимался. Задержка порядка 50 мс. это мало, чтобы заметить но не 0. Если бы задержки не было вообще, то при любой попытке скрола, менялась бы выделенная ячейка. Вот видео, записал как смог. Это ни как не настраивается, просто после многих проб и ошибок подобрался наиболее оптимальный вариант. Похожий на стандартное поведение. Да, были с этим проблемы, при чем как всегда: "Не знаю, не знаю, у меня всё работает, что у вас за телефон?". Тут надо понимать, что это некие искусственные события которые эмулируют работу с мыши т.е. добавляют свою логику поверх системной, и там в зависимости от модели могут быть разные особенности, лучше обрабатывать жесты. Посмотрите исходники, можно сделать по образу и подобию. А чем собственно не удовлетворяет стандартное поведение? Я так и не понял.