CreateCellControl в Grid (Berlin)

[kami]

Добрый день всем!

В Seattle у TColumn была возможность создать свой контрол для редактирования содержимого, перекрыв CreateCellControl.

TStringColumn = class(FMX.Grid.TStringColumn)
  protected
    function CreateCellControl: TStyledControl; override;
  end; 

Пытаюсь перейти на Berlin Upd1 - и вижу, что этого метода нет.

Пошерстил по форуму, по исходникам, погуглил - да, грид переписан чуть более чем полностью. В стандартных примерах (если быть более точным - то по гриду только один) используются штатные колонки с их "штатными" редакторами.

Мне же нужно установить редактору мой StyleLookup, выставить тип клавиатуры и пару других параметров.
Собственно, вопрос - как?

P.S. Да, гриды - зло, знаю. Но это узкоспециализированное приложение, работающее только на планшетах.

[Равиль Зарипов (ZuBy)]

16 минут назад, kami сказал:

Добрый день всем!

В Seattle у TColumn была возможность создать свой контрол для редактирования содержимого, перекрыв CreateCellControl.

TStringColumn = class(FMX.Grid.TStringColumn)
  protected
    function CreateCellControl: TStyledControl; override;
  end; 

Пытаюсь перейти на Berlin Upd1 - и вижу, что этого метода нет.

Пошерстил по форуму, по исходникам, погуглил - да, грид переписан чуть более чем полностью. В стандартных примерах (если быть более точным - то по гриду только один) используются штатные колонки с их "штатными" редакторами.

Мне же нужно установить редактору мой StyleLookup, выставить тип клавиатуры и пару других параметров.
Собственно, вопрос - как?

P.S. Да, гриды - зло, знаю. Но это узкоспециализированное приложение, работающее только на планшетах.

беда сейчас с гридом, многое сломали. тоже пытался, но не смог сделать

[kami]

Ну вот зачем надо было выносить создание редакторов в FMX.Grid.Style.pas, в TStyledGrid?

Да еще жестко зашивать "какие редакторы могут быть созданы" в function TStyledGrid.GetEditorClass?

То есть теперь, получается, если нужен свой InplaceEditor, то мало создать свой класс TColumn, нужно еще перекрывать TStyledGrid...

[Равиль Зарипов (ZuBy)]

2 минуты назад, kami сказал:

Ну вот зачем надо было выносить создание редакторов в FMX.Grid.Style.pas, в TStyledGrid?

Да еще жестко зашивать "какие редакторы могут быть созданы" в function TStyledGrid.GetEditorClass?

То есть теперь, получается, если нужен свой InplaceEditor, то мало создать свой класс TColumn, нужно еще перекрывать TStyledGrid...

получилось? можно демку?

[kami]

Нет, конечно можно воспользоваться событием OnCreateCustomEditor.

Но сделать свой редактор на основе уже существующих - нельзя. Они все (существующие редакторы, включая TDefaultEditor) объявлены в implementation FMX.Grid.Style.pas

То есть - придется копировать код оттуда, дабы забрать функциональность ICellControl...

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

Как-то предыдущая архитектура грида мне больше нравилась...

1 минуту назад, ZuBy сказал:

получилось? можно демку?

Пока не получилось, будет результат - отпишусь.

[kami]

Ну, для моих нужд хватило следующего:
 

type
  TStringColumn = class(FMX.Grid.TStringColumn)
  protected
    // function CreateCellControl: TStyledControl; override; // это было в Seattle
  public
    function RefreshEditor(const InplaceEdit: TFmxObject; const Value: TValue): Boolean; override;
  end;

function TStringColumn.RefreshEditor(const InplaceEdit: TFmxObject;
  const Value: TValue): Boolean;
var
  ivk: IVirtualKeyboardControl;
begin
  // здесь уже создан штатный контрол-редактор из числа имеющихся в Grid.Style.pas
  if InplaceEdit is TStyledControl then
  begin
    TStyledControl(InplaceEdit).StyleLookup := 'editVariableHeightStyle'; // свой стиль
    if InplaceEdit.GetInterface(IVirtualKeyboardControl, ivk) then
    begin
      ivk.ReturnKeyType := TReturnKeyType.Done; // клавиатурные настройки
      ivk.KeyboardType := TVirtualKeyboardType.NumberPad;
    end;
  end;
  Result:=inherited RefreshEditor(InplaceEdit, Value); // и штатный вызов.
end;

Будет время (ох, вряд ли...) - попробую разобраться со всем остальным.

Изменено 4 октября, 2016 пользователем kami

[RoschinSpb]

В 04.10.2016 в 14:45, kami сказал:

Ну вот зачем надо было выносить создание редакторов в FMX.Grid.Style.pas, в TStyledGrid?

Да еще жестко зашивать "какие редакторы могут быть созданы" в function TStyledGrid.GetEditorClass?

То есть теперь, получается, если нужен свой InplaceEditor, то мало создать свой класс TColumn, нужно еще перекрывать TStyledGrid...

Потому, что кроме TStyledGrid есть еще TiOSGrid, а в перспективе по одному на каждую платформу. И на каждой платформе своя нативная реализация ячеек и редакторов ячеек для каждого типа TColumn. На мобильных дэвайсах реализация вообще радикально другая, контролы не рисуются на канве, а используются системные объекты это приводит к некоторым ограничениям, но зато даёт ощутимый выигрыш по скорости отрисовки. 

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

[RoschinSpb]

В 04.10.2016 в 14:50, kami сказал:

...дабы забрать функциональность ICellControl...

Да, функциональность ICellControl просто неподъёмная  GetColumn SetColumn

[kami]

54 минуты назад, RoschinSpb сказал:

Да, функциональность ICellControl просто неподъёмная

Она подъемная. Но зачем дублировать код того же TDefaultEditor, если можно было бы просто унаследоваться от него и дополнить нужным функционалом, если бы эти редакторы были объявлены в interface-секции.

Допустим, в следующей версии RAD функциональность редакторов расширяется, они обрастают новыми интерфейсами. Копи/паст в свой модуль одного из редакторов об этом не узнает. И о том, что нам нужно заново производить копирование кода узнаем только в runtime, когда TStyledGrid не получит необходимый интерфейс у нашего inplaceEditor. Поправка - об этом узнают те, которые не боятся лезть в исходники FMX, остальные будут спрашивать "почему перестало работать".

В общем, не знаю... Я сужу со своей колокольни - мне платформенные гриды не нужны. Возможно, если включить в мои рассуждения еще и необходимость их поддержки, то текущая картина действительно станет единственно верной. Но пока - объявления редакторов в implementation и жесткое задание "какой редактор какой колонке сопоставить" в TStyledGrid.GetEditorClass (пусть даже это виртуальный метод) мне кажется значительно усложняющим фактором.

[RoschinSpb]

6 часов назад, kami сказал:

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

вот как-то так получается, что бóльшей части пользователей FM требуется именно поддержка платформ, потому, что если не требуется, то более разумно использовать vcl+100500 других библиотек. Все-таки специально заточенные под конкретную платформу библиотеки всегда будут проще и лучше, как кофемолка всегда (при прочих равных условиях) будет проще и лучше молоть кофе чем кухонный комбайн. Но это лирика...

Здесь идея состоит в том, что надо разделить платформонезависимую и платформозависимую части. По этому все наследники TColumn и TCustomGrid ни чего не знают о TDefaultEditor, TStyledGrid... и наоборот. В этом случае можно реализовать свой редактор для TStyledGrid и при этом не убить TiOSGrid. 

TColumn таким образом потерял всю функциональность связанную с отображением чего-либо, это мог бы быть вообще не TControl, а, например, TCollectioltem, но оставлен как есть для совместимости. 

Если очень хотите опубликовать TDefaultEditor и пр. напишите в QC. Хотя мне кажется там реализация слишком тривиальна, чтобы что-то еще наследовать. Есть три (два с половиной) необязательных интерфейса ICellControl, IDrawableCell, IDrawableCellEx, которые можно реализовать, по образу и подобию.

В FMX.Grid.iOS все редакторы опубликованы, но там реализация совсем другая.

[kami]

8 часов назад, RoschinSpb сказал:

вот как-то так получается, что бóльшей части пользователей FM требуется именно поддержка платформ,

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

Ок, не вижу смысла заводить запрос в QC, возможно - когда действительно возникнет реальная необходимость (на текущий момент не могу придумать железобетонную аргументацию, чтобы запрос был принят).

Последний вопрос, уже из чистого любопытства - не пойму, а как активируется iOS-овская реализация грида? Вот стилизованную - вижу, когда бросаешь грид на форму - там автоматом в uses падает FMX.Grid.Style и в initialization этого модуля идет регистрация. А вот iOS - да, тоже есть регистрация в initialization, но этот модуль нигде не фигурирует в uses, в т.ч. и в штатных исходниках... и получается, что компилятор его просто не включит в работу со всеми вытекающими. Его при необходимости использования нужно прописывать ручками?

Изменено 11 октября, 2016 пользователем kami

[RoschinSpb]

 

6 часов назад, kami сказал:

а как активируется iOS-овская реализация грида?

В Berlin'e — да, надо руками добавить модуль FMX.Grid.iOS в проект и хотя бы в один раздел uses, ну и не забыть ControlType грида установить в Platform.

В следующей версии наверно тоже будет автоматически добавляться, а здесь к моменту выхода еще не допилили иосную реализацию и не включили её в пакет FMX поэтому такой вот не совсем стандартный подход. В Update1 там много что было исправлено, так что можно смело пользоваться.