Как скрыть испольуемые фреймом компоненты?

← →
Дмитрий С © (2010-08-10 19:52) [0]

Есть фрейм:
TPageEditor = class(TFrame) Panel1: TPanel; edText: TMemo; btH1: TSpeedButton; procedure btH1Click(Sender: TObject); private function GetText: String; procedure SetText(const Value: String); public property Text: String read GetText write SetText; end;

И его экземпляр на другой форме:
edPageText: TPageEditor;

Как скрыть TPageEditor.edText, TPageEditor.btH1, TPageEditor.Panel1 для контекста формы?

Пробовал использовать слово private - компилируется, но не работает:
--------------------------- Application Error --------------------------- Exception EClassNotFound in module Project1.exe at 00034642. Class TPanel not found. --------------------------- ОК ---------------------------

← →
Дмитрий Тимохов (2010-08-10 20:03) [1]

Я думаю, что никак.
Published они должны быть, иначе никак.

← →
Ega23 © (2010-08-10 20:16) [2]

> Я думаю, что никак.

Не, ну почему? Убрать в приват и создавать в ран-тайм.

← →
Игорь Шевченко © (2010-08-10 20:48) [3]

А нафига ?

← →
Дмитрий С © (2010-08-10 21:01) [4]

> Не, ну почему? Убрать в приват и создавать в ран-тайм.

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

> А нафига ?

Чтобы не мешались

← →
Ega23 © (2010-08-10 21:04) [5]

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

Тады ой, по другому не скроешь.

← →
Игорь Шевченко © (2010-08-10 21:31) [6]

> Чтобы не мешались

Выкинь фрейм

← →
Юрий Зотов © (2010-08-10 23:13) [7]

Хм... действительно странная архитектура.

← →
Дмитрий С © (2010-08-10 23:15) [8]

> Хм... действительно странная архитектура.

А что странного?

← →
Asail © (2010-08-10 23:44) [9]

> Дмитрий Тимохов (10.08.10 20:03) [1]

> Я думаю, что никак.

+1

> Дмитрий С © (10.08.10 23:15) [8]

> А что странного?

+1
Действительно, что не так?

← →
Юрий Зотов © (2010-08-11 00:17) [10]

Если вся начинка фрейма спрятана, то зачем он вообще нужен?

← →
Alkid © (2010-08-11 00:18) [11]

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

← →
Юрий Зотов © (2010-08-11 00:20) [12]

> Alkid © (11.08.10 00:18) [11]

Как Вы без этого представляте себе визуальное проектирование?

← →
Юрий Зотов © (2010-08-11 00:23) [13]

А по сабжу - насколько помню, надо зарегистрировать фрейм, как компонент, и этот компонент уже кидать на форму.

← →
Alkid © (2010-08-11 00:25) [14]

> Юрий Зотов © (11.08.10 00:20) [12]
> Как Вы без этого представляте себе визуальное проектирование?

Так, как это сделано в C#. Там дизайнер форм совместим с приватностью компонентов. То есть можно сделать фрейм, визуально набросать на него кнопочки и проч. и все это будет private. Никакой козел не сможет извне моему Button1 выставить свойство в обход моего кода.

← →
Игорь Шевченко © (2010-08-11 00:38) [15]

Alkid © (11.08.10 00:25) [14]

А где в C# хранятся свойства набросанных компонентов ? Правильно, в соседнем .cs файле, который точно также компилируется и в конструкторе, который выполняется. А в Delphi - в dfm, который загружается и анализируется в runtine. Потому published свойства, что их можно по имени получить и нужное значение присвоить.

Можно и в Delphi такое сделать, эксперт есть, называется Components to code, только нафига ?

← →
Alkid © (2010-08-11 00:43) [16]

> Игорь Шевченко © (11.08.10 00:38) [15]

А какие преимущества run-time загрузки dfm перед compile-time кодогенерацией? Если уж мы завели поля в классе для компонентов, то они УЖЕ известны нам на этапе компиляции.

← →
Плохиш © (2010-08-11 02:46) [17]

Раз уж дошло до холивара

> Alkid © (11.08.10 00:43) [16]

> А какие преимущества run-time загрузки dfm перед compile-time кодогенерацией?

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

PS. Всегда прикалывают индивиды кричащие, что у одного средства что-то сделано по-другому, чем у другого и это с их точки зрения более правильно. Кто мешает сменить средство разработки?

> Юрий Зотов © (11.08.10 00:17) [10]
> Если вся начинка фрейма спрятана, то зачем он вообще нужен?
>

Вот к примеру у меня есть куча фреймов, наследующихся от некоего базового фрейма. Есть некий интерфейс, который они реализуют... Есть форма, которая создает и отображает те или иные фреймы (в зависимости от ситуации). Весь обмен данными между формой и фреймами осуществляется посредством того самого интерфейса (ну, т.е. методами его реализующими). А всеми визуальными компонентами на фрейме управляет исключительно он сам. Форма не должна знать какого цвета TEdit на том или ином фрейме и есть ли там вообще этот самый TEdit...
Так вот... Что неправильно в такой архитектуре?

Alkid © (11.08.10 00:43) [16]

читай еще раз сюда: Игорь Шевченко © (11.08.10 00:38) [15]

"run-time загрузки dfm" не альтернатива, а приятное дополнение к "compile-time кодогенерацией".

> Если уж мы завели поля в классе для компонентов, то они
> УЖЕ известны нам на этапе компиляции.

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

> Asail © (11.08.10 03:00) [18]

Ну так и не давай никому фрейм, давай интерфейс.

А для дизайнтайма (и по теме), например:
заводится панель-контейнер для фреймов со свойством "класс фрейма";
контейнер знает только про базовый фрейм (интерфейс);
при смене свойства создается (или появляется) экземпляр класса фрейма;

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

> Плохиш © (11.08.10 02:46) [17]
> Раз уж дошло до холивара

Холивара пока нет :)
Но "пришел Штирлиц и началась драка".

> Встречный вопрос, те же самые букавы, только выделенное
> поменено местами.

Основной плюс compile-time выполнения работы заключается в том, что отпадает необходимость в наличии механизма, который то же самое будет делать динамически, и всех издержек, связанных с ним. Плюс к этому, если есть какие-то правила верификации загружаемых данных, то лучше пусть они отработают при сборке проекта и выдадут все свои ошибки сразу, чем в рантайме. Так что если на этапе компиляции есть готовые данные, то пусть лучше они будут обработаны сейчас, чем когда программа запустится.

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

Если ты обо мне, то ты ошибся.
Я такого не кричал :)

Кто мешает сменить средство разработки?

Никто не мешает. Я, собственно, много программировал на Delphi, а сейчас - самое на C#.

> int64 © (11.08.10 04:06) [20]
> Ну так и не давай никому фрейм, давай интерфейс.

Тут есть проблема с тем, как это реализовано в дизайнере форм. Если ты бросаешь компонент на форму, то заводится поле с типом конкретного класса этого компонента.

RTFM

DefineProperties method (TControl)

Provides methods to read and write the IsControl property to a stream such as a form file.

Delphi syntax:

procedure DefineProperties(Filer: TFiler); override;

C++ syntax:

virtual void __fastcall DefineProperties(Classes::TFiler* Filer);

Description

DefineProperties is called automatically by the streaming system that loads and saves VCL components. It allows persistent objects to read and write properties that are not published. Published properties are loaded and stored automatically.

DefineProperties uses the methods of the filer passed as the Filer parameter to assign methods that can load and save the IsControl property.

Override DefineProperties to persist unpublished properties. Call the DefineBinaryProperty or DefineProperty method of the Filer parameter to assign methods that load or save property values.

Note: When overriding this method, call the parent class’s DefineProperties method first.

> то заводится поле с типом конкретного класса этого компонента.

Да, к нему некоторые иногда в коде обращаются :)

Как скрыть испольуемые фреймом компоненты? Найти похожие ветки