PavelBuilderВообще, если хочешь повысить собственную щкуропродажность, знание PFC огромный плюс. Даже если не использовать эти бибилиотеки и писать на чистом Билдере навыки работы с этой бибиотекой хорошо вправляют мозги на написание правильного кода.Я бы сказал что они хорошо свихивают мозги. Ибо на вкус человека хорошо знакомого с множеством других библиотек, PFC очень криво написан. Каждый раз как залажу в PFC матерюсь и частенько словами которые утром еще не знал :)
Но так как PFC является де-факто стандартом для PB-общества, PFC действительно знать надо.

Филипп White OwlЯ бы сказал что они хорошо свихивают мозги. Ибо на вкус человека хорошо знакомого с множеством других библиотек, PFC очень криво написан.
Это на плохой вкус...Да, я подозревал что Филипп возмутится первым :)
Но если PFC такая хорошая вещь - объясните например почему в pfc_u_dw сделны два элемента один типа u_Calendar, а другой u_Calculator? Сделать один общий pfc_u_dropdown_from_dw и унаследовать календарь с калькулятором от него тяму не хватило?
Зачем вообще они сделали pfc* и pfe* библиотеки и при этом базовые классы лежащие в pfc ссылаются на классы из pfe, которые при этом унаследованы из pfc? И это называется ООП?!

Знать PFC - надо, потому что оно самая стандартизированая библиотека для PB. Использовать можно, оно все таки работает и даже не особо глючит (по сравнению с самой средой PB особенно :). Подражать авторам PFC - боже упаси.

Филипп1) Может потому-что два элемента один типа u_Calendar, а другой u_Calculator сделаны НЕ в pfc_u_dw, и их можно использовать не только на datawindow?А что, если у них сделать общего предка их нельзя будет использовать в том же pfc_u_em? У этих несчастных pfc_u_calendar и pfc_u_calculator одинаковый код во всем что касается отрисовки и позиционирования. Почему бы не вынести этот код в предка? Так нет, создатели PFC поместили этот код в совершенно отдельный класс и создают объект этого класса (n_cst_dropdown) в каждом iuo_Calendar и iuo_Calculator?! Это вообще классический пример как нельзя писать в объектном языке.

Филипп2) вы просто в принципе не понимаете стратегию расширения PFC, посему все остальные ваши замечания на эту тему можно спокойно игнорировать...Нет, не понимаю.
Я совершенно не понимаю зачем в PFC сделаны два набора классов c префиксом pfc_ и без префикса. Объясните мне тупому, пожалуйста.

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

PavelBuilderА вопрос можно? Чего общего между калькулятором и календарем с объектной точки зрения?Это виджет выпадающей панельки привязаный к другому виджету. У них как минимум есть общий код самопозиционирования относительно главного виджета. И общий код показываться-прятаться по событию в главном. Вот все то, что сейчас в PFC реализовано как pfc_n_cst_dropdown должно по хорошему быть общим предком для pfc_u_calendar и pfc_u_calculator. Предком, а не элементом.

PavelBuilderвозможны ли случаи использования обоих объектов одновременно в привязке к одному объекту ввода/редактирования?Нет, невозможны конечно, но вот как раз этот вопрос к делу не относится.
Главный виджет должен уметь работать с выпадающими унифицировано. Не через два отдельных набора функций и событий, а через один общий набор функций.

PavelBuilder White OwlЯ совершенно не понимаю зачем в PFC сделаны два набора классов c префиксом pfc_ и без префикса. Объясните мне тупому, пожалуйста.читайте документацию, тогда такие вопросы возникать не будут. так поставленный вопрос говорит о том что вы вообще не знаете что такое PFC, уж извините ...Вот и объясни. Покажи цитату из документации которая объясняет почему базовые классы имеют в себе приватные объекты классов потомков?

ЗоринАндрей White OwlВот все то, что сейчас в PFC реализовано как pfc_n_cst_dropdown должно по хорошему быть общим предком для pfc_u_calendar и pfc_u_calculator. Предком, а не элементом.Весь(!) PFC написан исходя из принципа "делегирование вместо наследования".В том то и дело, что там есть и делегирование и наследование. Вот если бы было что-то одно из двух - я бы ни слова не сказал против. Наоборот хвалил бы. А вот то что там смесь - это как раз и плохо. Библиотека должна быть стройной. На то она и библиотека. Не набор скиданых как попало классов, а система классов. Сделаных по одному общему дизайну, по одной общей технологии. Как только начинается смесь в библиотеке - она превращается из полезной вещи в головную боль.

ЗоринАндрейИ в коде узнаваемы в принципе известные паттерны ООП. Десять лет назад почти. George вот скажи - ты десять лет назад про паттерны чтонибудь слышал? в работе использовал? в business application development? и коллеги твои тогдашние тоже? Погоди, "известные паттерны ООП" это что имеется в виду? Стандартные подходы к решению стандартных проблем или паттерны в современном понимании? Если про паттерны в современном понимани - нет не слышал. Ни в SmallTalk, ни в C++, ни в Java их в десять лет назад не было еще :)

ЗоринАндрей White Owlпочему базовые классы имеют в себе приватные объекты классов потомковбрр... кто кого в себе имеют?
Вот объясни где это ты увидел и почему тебя это так возмущает?Посмотри на ссылку которую ты мне дал. Открывай там Page3 и смотри рисунок номер 8.
Сверху PFC в который программер лазать не имеет права. Ниже PFE который программер волен править и наследовать от него свои собственные классы. Я правильно читаю эту картинку? :) Так почему класс pfc_u_dw в числе своих public instance objects имеет u_calendar iuo_Calendar? Почему принадлежащий PFE u_calendar, а не принадлежащий PFC pfc_u_calendar?
Зачем мы смешиваем два разных по изначальному дизайну слоя? Или нарушать свой собственный дизайн в PB считается хорошим тоном? :)

Они (авторы PFC) сами видять какую фигню нагородили, вон читай на той же самой странице дальше:
LimitationsOnce the generic framework code is combined with the application specific it cannot be easily separated.

This approach is based on an assumption that there is little or no need for reusable code. The extension scope is defined as two components PFC and application. If you plan to reuse any code or to share it between multiple applications this approach is not practical.

Do not underestimate the common framework requirement for your application. The reusable framework may be as small as a few PFC bug fixes. Reapplying the same fixes for the next project can be very tedious.


Requires maintaining a separate copy of PFE and PFC pbls for each project.

The reason for separate PFE pbls is clear, they are specific to each project, but why PFC? The answer lies in the nature of object relationships between the two layers. PFC layer contains many objects which are inherited from the objects in the PFE layer, for example pfc_w_sheet is a descendant of w_master. The same is true for associative and aggregate relationships. The transaction object referenced in PFC objects is n_tr and not pfc_n_tr. In many cases by modifying the PFE objects with the application specific code makes the PFC objects application specific as well.

This brings up an important distribution issue: If you create pbds or dlls from the PFC pbls they may not be compatible between multiple applications!
Ну и как такая библиотека может хорошо вправить мозги на написание правильного кода? Разве что от противного - так делать библиотеки нельзя.

ЗоринАндрейПотому что во всех объектах унаследованных от pfc_u_dw я должен иметь мой расширенный u_calendar, а не стандартный pfc_u_calendar который я менять не имею права.Угу. Про наследование мы уже значит слыхом не слыхивали? :)