От перестановки мест слагаемых сумма не изменяется...

На прошедшем в сентябре 2006 Девконе в Праге Graig Berntson представил доклад "Thnking Object", который он начал фразой. "All are the objects!". Целиком и полностью с ним согласен и придерживаюсь этого правила уже очень давно, с момента освоения VFP 3.0.

Действительно, процесс разработки значительно упрощается, если рассматривать всё, как объекты, и выделять свойства этих объектов, а также их события и действия (методы). Однажды, мне потребовался элемент управления (control), который никак не вписывался в даже в структуру элемента управления базового класса Control. И тогда пришла мысль о связях объектов между собой, которая потом выкристаллизовывалась в определение "объект-компаньон". Смысл этого определения заключается в том, что объекту можно назначить объект-компаньон, который будет отслеживать поведение командита (это не опечатка - именно командит - как старший компаньон) и соответственно изменять свое.

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

Ниже представлен этот же страничный фрейм, но уже с активным объектом компаньоном, правда, объект-компаньон "пробужден" внешней командой, без добавления страницы (вариант использования альтернативного дизайна, доступного пользователю, то есть свойство объекта "mimics_comandit" установлено в "own" - "не следовать стилю закладок командита", свойство "display_tabs" установлено в "short" - "короткие"), а свойство "display_location" установлено в "bottom".

Как это применимо к порядку инициализации, о котором зашла речь в предыдущей части?

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

If !This.cl_InitDefault
   this.cl_InitDefault=.T.
   Return .T.
Endif
...
* код инициализации
....
* последняя строка кода инициализации
This.cl_Inited=.T.

или так:

* необходимые проверки установок и переназначения
...
If !(type(This.co_Comandit)='O')
   Return .T.
Endif
...
* код инициализации
...
* последняя строка кода инициализации
This.cl_Inited=.T.

В первом примере, объект не инициализует определенное для него поведение и его экземпляр создается с установками по умолчанию. Его инициализация может быть проведена в каком то другом месте, например, в методе, ассоциированном с событием Init формы, где просто просматриваются объекты-члены и если их свойство cl_Inited установлено в False (.F.), то вызывается их инициализация.

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

При таком использовании события инициализации вы можете не беспокоится о порядке инициализации, который по умолчанию определяется порядком ввода элементов управления в контейнер. Например, в формах с многоязычным интерфейсом, экземпляр класса диспетчера, управляющего отображением заголовков (Caption) элементов управления формы в требуемом пользователю языке, создается в форме в случае, если ее свойство "cl_UseMUI" установлено в True (.T.). Поскольку свойства формы доступны до инициализации ее самой, то, к примеру, метка (Label), переписывает значение установленное для свойства формы "cl_UseMUI" в свое одноименное значение, и, если свойство установлено в True, а сохраненный в установках пользователя язык отображения не соответствует установленному по умолчанию, то это означает, что метка должна поменять свой заголовок, вызвав соответствующий метод диспетчера, который только еще будет введен в форму только при инициализации ее самой, то есть в момент инициализации метки еще отсутствует в качестве объекта-члена формы. В таком случае метка, переписывает значение своего свойства порядка инициализации и прекращает ее, возвратив True (.T.), не дойдя до последней строки метода, которая приведена в примерах. После того, как форма добавит в список объектов экземпляр класса диспетчера, то последний в конце своей инициализации, просматривает список объектов-членов формы и для тех из них, у которых cl_UseMUI установлен в True (.T.), но свойство "cl_Inited" осталось установленным в значение по умолчанию - False (.F.), установит соответствующие требуемому языку заголовки.

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

* необходимые проверки установок и переназначения,
This.co_Comandit=Thisform.co_MUIDisp
...
...

lcStingToTest=This.cc_MUIDispHost+'.'+This.co_Comandit+'.cl_Inited'
*Поскольку экземпляр класса диспетчера будет создаваться в методе,
*ассоциированном с событием Init формы, то следующая строка кода
*вернет "U"

If Type(lcStingToTest) = "U"
   Return .T.
Endif
...
* код инициализации
...
* последняя строка кода инициализации
This.cl_Inited=.T.

В данном примере свойство метки "cc_MUIDispHost" указывает на контейнер, в который будет помещен экземпляр класса диспетчера управления многоязычием формы, (обычно это свойство устанавливается для подобных случаев в "Thisform") а свойство "co_Comandit" указывает на имя экземпляра диспетчера, который переписывается из свойства формы co_MUIDisp

Удобно? И голова не болит о порядке инициализации.

Будет продолжено....