0001006: В Параметрах карты/слоя свести все настройки в единую таблицу

После упорядочивания zmp как раз подумываал свести в таблицу GPs\GSm а потом и другие опции. Длу ускорения процесса пока что не буду добавлять те параметры которые используются но не редактируются напрямую из программы, например скрипт из ZMP.

KGrid довольно любопытен. установился мгновенно. Обычная таблица с строками. Но !

case InitialCol of
    1:
    begin
      AEditor := TEdit.Create(nil);
    end;
    2:
    begin
      AEditor := TComboBox.Create(nil);
      TComboBox(AEditor).Style := csDropDown;
    end;
    3:
    begin
      AEditor := TButton.Create(nil);
    end;
    4:
    begin
      AEditor := TCheckBox.Create(nil);
      TCheckBox(AEditor).Font.Color := clRed; // applies only without OS themes (in Delphi)
    end;
    5:
    begin
      AEditor := TScrollBar.Create(nil);
      TScrollBar(AEditor).Max := 10;
    end;


и так любой тип контрола создается динамически на время редактирования.

Один минус. Возможности сгруппировать параметры и скрывать -раскрывать группу я не нашел, а без этого таблица кажется неупорядоченной.

Virtual Tree установился из исходников не сразу. аж три директории прописал, да и еще ошибка - пакаджи лежат на одну папку глубже чем это прописано. так что если svn скачивать будет не айс (это не hg и толку от них мало, проще в папку requires кинуть и все.) Изучаю функции.

Код простой, но не лишённый недостатков. Основной - создание компонентов не произвольных, а только из закрытого перечня, свойства тоже руками пишутся в коде. События налету не связать с другими объектами. То есть конечно VTV наиболее близок из доступных к идеалу, но я предлагаю создавать объекты несколько по-другому. Возможно не получится, если компонент заточен под приаттаченный код, но тем не менее если получится, будет куда интереснее, проще потом, менее ресурсоёмко и более гибко.

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

    object TMyWindow: TTBXDockablePanel
      Left = 65
      Top = 0
      DockedWidth = 170
      DockPos = -6
      DockRow = 2
      TabOrder = 1
      Visible = False
      Caption = 'Codecoder'
      object MyPanel: TPanel
        Left = 0
        Top = 0
        Width = 170
        Height = 551
        Align = alClient
        AutoSize = True
        BevelOuter = bvNone
        TabOrder = 0
        object MyDock: TTBXDock
          Left = 0
          Top = 0
          Width = 170
          Height = 9
        end
        object MyScrollBox: TScrollBox
          Left = 0
          Top = 9
          Width = 170
          Height = 542
          HorzScrollBar.Visible = False
          VertScrollBar.Smooth = True
          VertScrollBar.Tracking = True
          Align = alClient
          Color = clWhite
          ParentColor = False
          TabOrder = 1
        end
      end
    end

конкретно тут нет свойств, но обработчики тут тоже натягиваются, проверено.

Далее зовётся код типа

procedure TfrmMain.LoadDFMPlugins;
var
  fs: TFileStream;
  ms: TMemoryStream;
  rd: TReader;
  new_panel: TTBXDockablePanel;
  new_toggler: TTBXVisibilityToggleItem;
begin
  try
    ms:=nil;
    fs:=nil;
    rd:=nil;
    try
      ms:=TMemoryStream.Create;
      // load
      fs:=TFileStream.Create('vsagps_fly-on-track.dfm', fmOpenRead);
      // convert
      ObjectTextToBinary(fs, ms);
      // make
      ms.Seek(0,soFromBeginning);
      new_panel:=nil;
      new_toggler:=nil;
      try
        new_panel:=TTBXDockablePanel.Create(Self);
        rd:=TReader.Create(ms, 4096);
        rd.OnFindMethod:=PluginDFMReader_FindMethod;
        rd.OnFindComponentClass:=PluginDFMReader_FindComponentClass;
        rd.ReadRootComponent(new_panel);
        new_panel.Parent:=TBDockLeft;
        // make visible-toggler
        new_toggler:=TTBXVisibilityToggleItem.Create(Self);
        new_toggler.Control:=new_panel;
        new_toggler.Images:=NPanels.Images;
        new_toggler.Caption:=new_panel.Caption;
        new_toggler.Hint:=new_panel.Hint;
        NPanels.Add(new_toggler);
      except
        FreeAndNil(new_toggler);
        FreeAndNil(new_panel);
      end;
    finally
      FreeAndNil(ms);
      FreeAndNil(fs);
      FreeAndNil(rd);
    end;
  except
  end;
end;

В общем-то этот код фактически рабочий. Это пример "плагина" в виде dfm, который умеет открываться в программе (да! некоторые уже живут с плагинами!). В приложении к настройкам необходимо только удалить toggler и добавить поиск класса по имени (в этом смысле это тоже фигня, ибо это фактически и так сделано тривиально в обработчике PluginDFMReader_FindComponentClass, код ниже). Конечно что угодно так не создашь, нужна инфа о компоненте, но стандартные слинкованные в сас все создаются замечательно. Обработчик PluginDFMReader_FindMethod вообще пишется ровно один раз для любых случаев, находит объект (именовать внутренние объекты можно через точку) и мапит события. Типа такого (здесь нет обработки внутренних объектов, легко делается через точку межуд именами, меня же интересовали только события главной формы):
procedure TfrmMain.PluginDFMReader_FindMethod(
  Reader: TReader;
  const MethodName: string;
  var Address: Pointer;
  var Error: Boolean);
begin
  if Error then begin
    Address:=self.MethodAddress(MethodName);
    if Assigned(Address) then
      Error:=FALSE;
  end;
end;

Руками только одно надо сделать - обработку хитрых обработок типа "если тут заполнено а здесь выключено, то это посерить, а тут очистить", но такие вещи по любому либо руками, либо писать скрипты.
Причём так как ReadRootComponent не создаёт объект, а только натягивает свойства из потока, но очевидно легко реализуется наследование, которое поможет для плагинов. В этом смысле плагин не будет иметь свой гуй но будет говорить программе "построй для меня гуй по этой схеме", и перед каждым натягиванием свойств на объекты из плагина можно будет легко предварительно (или наоборот после) натягивать базовые свойства для этих объектов (например, так реализуется единое оформление гуя).
Причём что самое приятное - по ресурсам это требует дополнительно почти ноль, аналогичный код и так линкуется в EXE-ху.

procedure TfrmMain.PluginDFMReader_FindComponentClass(
  Reader: TReader;
  const ClassName: string;
  var ComponentClass: TComponentClass);

  procedure _Lookup(const AComponent: TComponent);
  var i: Integer;
  begin
    if AComponent.ClassNameIs(ClassName) then begin
      ComponentClass := TComponentClass(AComponent.ClassType);
      Exit;
    end;
    if (0<AComponent.ComponentCount) then
    for i := 0 to AComponent.ComponentCount - 1 do begin
      _Lookup(AComponent.Components[i]);
      if Assigned(ComponentClass) then
        Exit;
    end;
  end;
begin
  _Lookup(Self);
end;

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

Но это касается только создания объектов. Сохранение и восстановление свойств - через приведение к базовому классу типа эдитки.