Войти
ПрограммированиеФорумОбщее

Вопросы по Delphi (55 стр)

Страницы: 154 55 56 57 58 Следующая »
#810
2:02, 9 ноя 2022

MrShoor
> dynamic_cast для Delphi для объектов посути то же, что и static_cast и
> reinterpret_cast.
Не совсем. foo as TBar сделает проверку в рантайме и кинет эксепшон, если foo не является на самом деле представителем TBar, тогда как TBar(foo), насколько я помню, верит на слово и кастует без лишних вопросов.

#811
(Правка: 2:12) 2:07, 9 ноя 2022

g-cont
> Иными словами, meOne = 0 превращается в meOne = 1<<0 как только мы начинаем их
> проверять в этих множествах?
Точнее:

meOne = 0
[meOne] = 1 shl 0

meTwo = 1
[meTwo] = 1 shl 1

[meOne, meTwo] = (1 shl 0) or (1 shl 1)

x in [meOne, meTwo] =
    ((1 shl x) and ((1 shl 0) or (1 shl 1))) <> 0

meOne - это просто число, а [meOne] в скобках - это уже множество, которое содержит это число.

Пища для размышлений: https://godbolt.org/z/ah5T7xWx1

#812
6:06, 9 ноя 2022

Имбирная Ведьмочка
> Не совсем. foo as TBar сделает проверку в рантайме и кинет эксепшон, если foo
> не является на самом деле представителем TBar, тогда как TBar(foo), насколько я
> помню, верит на слово и кастует без лишних вопросов.
Да, я имел ввиду, что в делфи каст не меняет сам указатель.

#813
(Правка: 18:23) 18:19, 17 ноя 2022

Добрался наконец-то до парсинга dfm-файлов, там где вся эта замута с конструированием объектов налету. Вопрос, собственно вот какого плана.
Там в dfm файлах, создаются как бы новые классы, ну может быть и не классы, а объекты, унаследованные от реальных классов в коде VCL\пользовательском коде. У этих классов, как я понял, невозможны никакие новые поля или функции, при условии, что класс объявлен только в dfm, а в коде он не прописан. Вопрос следующий - от этих виртуальных классов можно унаследовать что-то еще, прямо в самом dfm или нет?
Механизм в общих чертах понятен, но хотелось бы узнать поподробнее за его возможности.

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

#814
18:31, 17 ноя 2022

Понемногу начинает доходить. Если у объекта есть имя собственное, значит он будет фигурировать в качестве члена класса в коде.
Если имени нет, то это такой виртуальный объект, который существует только в dfm, сам VCL его видит, но из пользовательского кода напрямую к нему обратиться невозможно, разве что в том же dfm прописан каллбэк на какую-то из его функций.
И еще там линеаризация. То есть внутри объекта без имени вполне могут быть еще какие-то объекты, например комбобокс или радиобаттон, с именами, которые уже прописаны в базовом классе, их состояние можно считывать, но иерархия внутри кода никак не отображается. Вероятно эти же кнопки можно без проблем перенести в другую панель, редактируя чисто dfm.

#815
(Правка: 19:39) 19:27, 17 ноя 2022

g-cont
> Вообще есть возможность создавать объекты чисто в dfm-файле, ничего не
> прописывая в коде и не перекомпилируя его?
нет.
попытка грузить dfm, с классами, которых нет в коде (а значит для них RTTI) - вызывает ошибку.
(потенциально загрузчик dfm может подставить класс затычку, но функионала или нового класса это не добавит)

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

g-cont
> Если у объекта есть имя собственное, значит он будет фигурировать в качестве члена класса в коде.
> Если имени нет, то это такой виртуальный объект, который существует только в
> dfm, сам VCL его видит, но из пользовательского кода напрямую к нему обратиться
> невозможно, разве что в том же dfm прописан каллбэк на какую-то из его функций.
может как-то с примерами?! а то не понятно нифига.

#816
23:23, 17 ноя 2022

skalogryz
> может как-то с примерами?! а то не понятно нифига.
я же так обычно всё описываю. )))
Что там не понятного?

Если он сам создаёт объект (даёт ему имя), то он может с ним работать.
Если VCL за него это сделал, то сам он не может его контролировать.

Хотя по сути, наверняка можно вытащить ссылку на нужный объект и от него плясать. Так постоянно делали в VCL, дёргали панель, присваивали самолично объявленному объекту панели и работали с ним.

#817
23:28, 17 ноя 2022

Mirrel
> Если VCL за него это сделал, то сам он не может его контролировать.
что?  VCL это скайнет?!?!?!

можно с примерами?! а то не понятно нифига!

#818
23:34, 17 ноя 2022

skalogryz, я не знаю как он виртуально сделал VCL-компонент. ))) Это ведь визуальные компоненты, а значит имена уже есть.

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

#819
23:50, 17 ноя 2022

если ты создаёшь компоненты в runtime-е, то в dfm они попасть не могут.
dfm для design-time

#820
9:53, 19 ноя 2022

Давайте с примерами.

    object Label2: TLabel
      Left = 14
      Top = 14
      Width = 377
      Height = 33
      Align = alTop
      AutoSize = False
      Caption = 'Name'
    end

Вот описание объекта, который привязан в коде через имя этого самого объекта - Label2.
А вот объект без собственного имени

  object TLabel
    Left = 9
    Top = 6
    Width = 67
    Height = 13
    Caption = 'New Label'
  end

Очевидно первый объект будет иметь привязку к классу через собственное имя, тогда как второй из пользовательского кода не будет доступен, хотя VCL, а значит и Windows смогут его обрабатывать на общих основаниях, согласно свойствам объекта.
Второй момент - объекты размещённые внутри других реализуют не наследование классов на уровне языка, что естественно невозможно сделать из dfm, а наследование на уровне WinAPI, определяя, чей объект является родительским для другого и значит все унаследованные объекты будут перемещаться вместе с родительским, а так же исчезать\появляться вместе с ним. Ну и конечно хэндлер сообщений перенаправляется в родителя, если не обработан в дочерних элементах.

#821
9:57, 19 ноя 2022

Развивая мысль. Если бы dfm-файлы лежали снаружи приложения, я бы допустим мог их отредактировать для уже скомпилированного приложения и получить какие-то новые элементы в интерфейсе? Пусть даже без возможности подключить их к коду, ну или задействуя уже имеющиеся каллбэки.
Может быть сущесвует какой-то Resource Hacker, который позволяет редактировать dfm уже в готовом экзешнике и добавлять новые элементы.
Моя идея заключается в том, чтобы dfm-скрипты лежали снаружи и редактировались для уже скомпилированного приложения.
А чтобы реализовывать новый функционал для них, механизм будет построен не на каллбэках, а на системе команд. Конечно система команд не предполагает обратной связи, но всё равно это будет гибче, чем текущий механизм.

#822
13:07, 19 ноя 2022

Что делают функции SetOrdProp и GetOrdProp?

#823
(Правка: 16:33) 16:24, 19 ноя 2022

g-cont
> Что делают функции SetOrdProp и GetOrdProp?
собственно начался RTTI. по имени свойство читает (ordinal) / назначает значение у объекта
GetOrdProp

g-cont
> Если бы dfm-файлы лежали снаружи приложения, я бы допустим мог их
> отредактировать для уже скомпилированного приложения и получить какие-то новые
> элементы в интерфейсе?
да, конечно. Если все классы, которые "использованы" в dfm, (так или иначе) известны твоему приложению.
(Либо для неизвестных классов ты используешь какие-либо заглушки)
собственно, Delphi IDE является примером такого приложения.

g-cont
> А вот объект без собственного имени
мне кажется безымянное объявление вырвано из контекста.
вангую, что такое безымянный объект, на самом деле "лежит" внутри "списка", а сам "список" вполне себе несёт некоторое имя.
(есть полный пример dfm файла?!)

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

#824
17:17, 19 ноя 2022

У меня основные сложности не с пониманием того, как всё это работает, а со знаниями, какие конкретно данные находятся и пишутся.
Вот к примеру функция.

function TReader.GetFieldClass(Instance: TObject; const ClassName: string): TPersistentClass;
var
  I: Integer;
  ClassTable: PFieldClassTable;
  ClassType: TClass;
begin
  ClassType := Instance.ClassType;
  while ClassType <> TPersistent do
  begin
    ClassTable := GetFieldClassTable(ClassType);
    if ClassTable <> nil then
      for I := 0 to ClassTable^.Count - 1 do
      begin
        Result := ClassTable^.Classes[I]^;
        if Result.ClassNameIs(ClassName) then Exit;
      end;
    ClassType := ClassType.ClassParent;
  end;
  if FFinder <> nil then
    Result := FFinder.GetClass(ClassName)
  else
    Result := GetClass(ClassName);
end;

Вроде бы всё понятно. Но не совсем. Например, что означает ClassName? Если это класс типа, TForm, TButton или аналогичный, то к чему такие сложности с явным указанием объекта-инстанса? Если все описания классов где-то хранятся, то это ведь глобальная таблица?
Следовательно здесь у нас поиск по имени членов класса, входящих в этот объект, так? Потому что перебор в цикле останавливается на первом же найденном, значит гарантированно в массиве ClassTable не может быть двух одинаковых имён, а подобное условие выполняется только для имён членов класса. Дальше, найденный по имени член класса возвращает свой тип, по которому динамически конструируется объект?
Я прав или что-то упустил?

Страницы: 154 55 56 57 58 Следующая »
ПрограммированиеФорумОбщее