Rostislav D. Kudryashov,

Ребята никто не спрашивал как? :))

почти все файлы в VFP это таблицы только с разными расширениями в том числе и библиотеки (vcx) (вся информация об этом доступна в хелпе)

в приведенном мной примере я создал обычный объект custom с именем pattern отредактировал его как хотел в плане методов
после открыл библиотеку как таблицу




нашел класс objname = pattern, platform=windows

изменил поля class, baseclass c custom на empty
обнулил поле properties

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

Не знаю что там у вас за грабли но я использую с 2009 года в "коммерческой разработке" и ничего живой
Я представляю что вы скажете на screen во вложении.


Dima TИ чего выиграл по сравнению с custom ?
Я ничего, а что должен был ?

Dima T Тогда непонятно зачем ...
Если интересует практическая часть применения то pattern это реальный класс на основе Empty плотно используемый мной при разработке, в предыдущем моем посте на скрине виден cursoradapter c кучей вложенных коллекций так вот почти все они содержат в себе объекты на основе pattern

Я его использую там где custom много а Empty мало просто надоело постоянно писать код типа
и все возможные его интерпретации, а также перебирать не именованную коллекцию для поиска и удаления одного из ее "empty" объектов изначально имея ссылку на этот самый "empty" объект.

sg12Можно подробнее про эти ваши классы, что на картинке.
Что именно интересует порядок создания того го рода класса или его предназначение

На скрине я показал что в объекты которые оприоре не могут содержать дочерних объектов типа cursoradapter можно всунуть как не визуальные так и визуальные классы и спокойно редактировать их методы и свойства в стандартном редакторе свойств VFP

sg12 сама идея взаимодействия - раз они вложены, значит должны существовать их родители

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

Если говорить о конкретном примере то весь это огород позволяет иметь динамически настраиваемый cursoradapter

sg12 Query комплектуется один на весь проект
Query это SQL parser вложенный как дочерний объект cursoradapter(а) который разбирает строку запроса SelectCmd на коллекции Fields,From,Where,Tables ... , а вот уже в коллекциях содержатся объекты (Pattern)


как пример: Tables содержит Pattern(ы) Table которые создаются
Createobject("Pattern","Name;TableSource;TableSourceType;Buffering;Tag")

Изменяя свойства объектов в соответствующих коллекциях я могу быстро изменить весь запрос не говоря уже о изменении условия выборки или упорядочивания

sg12Насколько можно вас понять, для этого вы открываете редактирование с переименованием классов.
NSFuimus1 не удалось повторить фокус ...: "Object class is invalid for this container" при попытке открыть его в class designer


Редактировать такие классы как Empty,Header через стандартный Fox(вый) редактор не получится так как и до "танцев с бубном" над ними этого сделать нельзя было, если очень хочется то надо провести обратные действия с переименованием.

Что же косается остальных то это вполне реально. Я так понимаю это просто "ход конем" который не закрыли разработчики Fox(а) и что меня радует больше всего что уже навряд ли когда закроют

Суть данного хода заключается в том что созданный класс условно назовем его "не такой как все" изначально отредактировать нельзя, а вот его наследника можно но надо помнить о том что наследника нужна изначально создать до того как класс станет "не такой как все"

sg12Может удобнее вынести установку свойств объектов в отдельный Custom, где и устанавливать собственно все параметры.Тогда необходимость в изменении объектов отпадет.
Если вы про танцы с бубном над классами то из вышесказанного ясно что это делается один раз при разработке объектной структуры класса который как мы помним "не такой как все"

NSFuimus1,

baseclass у наследника не изменил

в приложении пример

NSFuimus1изменил

Вам оттуда виднее

в примере редактируется класс "_de" но если перед ним попытаться отредактировать родителя "__de" то после ошибки надо выполнить clear all [classlib] так как Fox корректно не закрывает класс родителя

NSFuimus1,


pattern это пример класса на основе Empty

авторРедактировать такие классы как Empty,Header через стандартный Fox(вый) редактор не получится так как и до "танцев с бубном" над ними этого сделать нельзя было, если очень хочется то надо провести обратные действия с переименованием.