CTAC-KOПривет!

Хочется собирать/строить PageFrame из отдельных Page, как это осуществить так, чтобы и в дизайнере такой PageFrame нормально поднимался?

спасибо

вфп9

создать виз.библиотеку.
1.в ней создать свой класс на основе базового Page
2.в ней создать свой класс на основе базового PageFrame
3.своему классу на основе базового PageFrame прописать св-во MemberClass

далее кладете уже свой класс PF куда угодно, странички уже будут от своего класса.

что означает нормальный подъем? и что не получается?

CTAC-KOтак получится что у одного пф все страницы будут из одного класса. а мне надо в одном пф чтобы каждая страница была из другого класса

господи, божечка ты мой.

гы, шучу я.

ну давай так:
нафек?

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

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

давай постановку задачи.

CTAC-KOна каждом шаге свой отдельный набор контролов.
в принципе я не вижу как это можно сделать из пф, хотя мне тут где-то предлагали осуществить подобное. Разве что замутить что-то очень похожее на контейнерах

ну дык клади контейнер,
а контейнер уже на пейдж (а еще возможно - контрол с интерфейсом доступа к св-вам объектов извне - зависит от целей и задачи).
что испугало?

CTAC-KOдык а как программно? и как потом оно будет в дизайнере подниматься?

никак.

пива - извращенец.

делай визуально - потом голову не будешь ломать.

прогрраммный автомат можно сделать для
подъема каких-то преднастроек-описателей
(типа есть какой-то свой визуальный настройщик интрафейса).

2 CTAC-KO

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

этож неверно изначально.
сам просто подумай.

как классика жанра:
в дизайнере класса формы уже положить пф и у него наложить контролы

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

CTAC-KOв пф легче передвигаться от страницы к странице, т.к. есть .pages(), а в контейнерах придется еще создавать подобную фичу.

гы, не надо, убери от контейнеров руки.
никаких фич там не создавай.
там все и так работает если "правильно" все делать.

CTAC-KOпрошелмимо2 CTAC-KO
сам подумай, какое отношение набор контролов имеет к пейджу.
почему ты заморочился, что класс пейдж нужно разработать с уже
готовым набором контролов? а почему нет? как для конструктора мне кажется нормально. просто я пф оцениваю как контейнер контейнеров типа page. просто иначально пф (по дизайнеру) хочет один класс для всех page.

патамучта.

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

у тебя класс с уже набором готовым - это конечный результат.
смысл его разрабатывать в виде класса?

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

CTAC-KOвообщето я еще надеялся на form.saveas() чтобы потом в дизайнере уже готовую фому мб окучивать, но пока что не вышло - жалуется что какой-то класс-мембер отвалился...

послушай, ну если ты заморочился на легкости виз. настройки внешнего вида форм,
то почему ты решаешь сделать реал-ю через ....

почему тогда не заморочиться на свой описатель объектов,
которые будут на форме,
и такие формы строить автоматом на основе свойств, заготовленных в описателе?

CTAC-KOпрошелмимотебе нужно было сделать пустой класс-страницу.
класть в такой контрол-контейнер объекты нужно уже в дизайнере формы,
редактируя такой класс.так я и делаю обычно. а сейчас мне хочется конструктор пф из отдельных страниц. :)

зачем? мазохист.

зачем класс конечный с конечным набором контролов?

тупо даю пример, сделанный на коленке.
надеюсь что-то станет понятным.

переход по страницам Ctr+tab

CTAC-KOда это понятно, как уже писал - так и делаю, но в данном конкретном случае меня такое решение не устраивает

чем?

чем таким устраивают отдельные классы-страницы,
а не устраивает единый класс-страница?

почему видоизменение страниц при помощи добавления контролов в нее
является худшим, чем прямое создание страницы как класса с готовым набором
контролов в конечном виде?

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

ну и последние вопросы:
почему нельзя форму-класс, в которую положен pf править?
почему это нельзя делать прямо редактируя страницы pf в дизайнере класс-формы?

CTAC-KOчето я затупил как фсихда... :))
можно же те методы, что реализованы на страницах, реализовать в контейнерах... так и сделаю пожалуй.

вот именно.
что может стоит отдать какие-то дела самим контролам,
которые лежат на странице?

почему именно страница должна что-то знать и делать за контролы?