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

type
  TForm1 = class(TForm)
    DBGrid1: TDBGrid;
  private
    { Private declarations }
  published
    DM: TDataModule2;
  end;

Однако дизайнер Delphi не позволяет в компонентах формы (DBGrid1) задать ссылки на DM. Можно это как-то обойти, помимо ручного присвоения нужных ссылок в ран-тайм?

Здравствуйте, konstbel, Вы писали:

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

Хм. Почитайте вот это — практически Ваше желание.

K>Однако дизайнер Delphi не позволяет в компонентах формы (DBGrid1) задать ссылки на DM.

Кто Вам сказал такую глупость? В меню, кажется, File, делаете Use unit — и отлично задаете ссылки.

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, konstbel, Вы писали:

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

S>Хм. Почитайте вот это — практически Ваше желание.
Списибо, довольно забавное решение, хоть и несколько через Ж. Я одно время игрался с переименованием компонентов в ран-тайм, частенько напарываясь на загадочные глюки.

K>>Однако дизайнер Delphi не позволяет в компонентах формы (DBGrid1) задать ссылки на DM.

S>Кто Вам сказал такую глупость? В меню, кажется, File, делаете Use unit — и отлично задаете ссылки.
Нет, он даст ссылку именно на глобальную переменную в другом модуле. Я надеялся, что объявление его как published решит проблему — ан нет видимо, или предложенный обман механизма сериализации, или регистрить датамодуль как компонент...

Здравствуйте, konstbel, Вы писали:

K>Списибо, довольно забавное решение, хоть и несколько через Ж. Я одно время игрался с переименованием компонентов в ран-тайм, частенько напарываясь на загадочные глюки.

http://softwarer.ru/basic.html#NoMagic

Фраза "загадочные глюки" означает то, что Вы программист, который верит в магию; который вместо того, чтобы разобраться и сделать, пробует: "А вдруг так сработает? А если вот здесь поменять то, что я не понимаю, на то, что тоже не понимаю?"..

K>Нет, он даст ссылку именно на глобальную переменную в другом модуле.

Ошибаетесь. Глобальную переменную в другом модуле можете хоть удалить — ничего от этого не изменится. Он дает ссылку на объект, свойство Name которого равно указанному.

Здравствуйте, Softwarer, Вы писали:

S>Фраза "загадочные глюки" означает то, что Вы программист, который верит в магию; который вместо того, чтобы разобраться и сделать, пробует: "А вдруг так сработает? А если вот здесь поменять то, что я не понимаю, на то, что тоже не понимаю?"..

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

S>Ошибаетесь. Глобальную переменную в другом модуле можете хоть удалить — ничего от этого не изменится. Он дает ссылку на объект, свойство Name которого равно указанному.

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

Здравствуйте, konstbel, Вы писали:

K>Однажды мне до зарезу потребовалось переименовать компонент в ран-тайм, после чего и вылезли те самые глюки.

Полагаю, эти (последний пример).

K>Естественно, после этого я полез разбираться, что же это было.

Хм. Вот "загадочные глюки" как результат разбора меня и удивляют

K>Да, вы правы, он дает ссылку на умолчательное имя объекта

Он дает ссылку на реальное имя объекта. Единственное, что делает среда — поддерживает соответствие имени объекта и имени глобальной переменной, если последняя существует.

K>Вероятно, это логично с точки зрения среды, но все же я не считаю такое поведение (игнорирование переменных) правильным,

Хм. Я бы считал правильным, если бы в настройках была галка "не генерить этих дурацких глобальных переменных". Потому как они — один из глобальных источников ошибок.

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

Почему обман? Система работает строго специфицированным образом. Вся связь сериализации с глобальными переменными выражена в Application.CreateForm — только там переменная соотносится классу модуля. Создавать модули не привязанные к глобальным переменным разрешено, одобряется итп.

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

Кто сказал, что не даёт?!

Ссылку на датамодуль прописываем в uses, который после interface,
переменную объявляем в разделе public, и после этого в инспекторен объектов можно выбирать и указывать компоненты из датамодуля.

Здравствуйте, MylnikovDm, Вы писали:

MD>переменную объявляем в разделе public, и после этого в инспекторен объектов можно выбирать и указывать компоненты из датамодуля.

Будет интересно услышать хоть про какую-нибудь связь между переменными в разделе public и Object Inspector. На худой конец — между вообще хоть какими-нибудь переменными и object inspector.

Здравствуйте, MylnikovDm, Вы писали:

MD>Кто сказал, что не даёт?!

MD>Ссылку на датамодуль прописываем в uses, который после interface,
MD>переменную объявляем в разделе public, и после этого в инспекторен объектов можно выбирать и указывать компоненты из датамодуля.

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

Здравствуйте, Softwarer, Вы писали:

K>>Однажды мне до зарезу потребовалось переименовать компонент в ран-тайм, после чего и вылезли те самые глюки.
S>Полагаю, эти (последний пример).

Взглянул на свои старые записи — меня тогда убило то, что если выполнить
DataSource.Dataset:=Query1;
Query1.Name:= 'Something';
Query2.Name:= 'Query1';
то
Query1.Active:= true; — реально открывает Query2
Query2.Active:= true; — вызывает AV
а
DataSource.Dataset.Active:= true; — открывает таки Query1
Теперь-то мне ясно, что это было, однако тогда (после Borland Pascal) это был шок: обращение к переменной попадает совсем в другое место.

K>>Вероятно, это логично с точки зрения среды, но все же я не считаю такое поведение (игнорирование переменных) правильным,
S>Хм. Я бы считал правильным, если бы в настройках была галка "не генерить этих дурацких глобальных переменных". Потому как они — один из глобальных источников ошибок.

Можно и так, хотя на самом деле сбивает с толку именно совпадение имени переменной и Name объекта, и, думая что обращаешься к переменной, на самом деле вызываешь ObjectByName

PS. Кажется, пора завязывать, уже флейм пошел

Здравствуйте, konstbel, Вы писали:

K>Взглянул на свои старые записи — меня тогда убило то, что если выполнить

Ну да. Именно что мой пример с кнопками

Полагаю, борландеры здесь решили сделать "очень красиво и правильно" — в чем и ошиблись. Эту логику надо было запихнуть в механизм сериализации, а они решили "пусть компонент сам заботится о своих свойствах".

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