ладно. будем последовательны и не будем твердить одно и тоже разными словами. пойдем по принципу вопрос, ответ.
>>Итак - согласен и не совсем....
>>Инкапсуляция позволяет мне делать все что мне надо.
Насчет инкапсуляции красиво сказал.
>>Все контроли которые можно сделать в виндовс все равно проистекают из ВинАПИ. Тот кто советует весь интерфейс делать на АПИ либо никогда этого не делал, либо мазохист.
Обзываться не нужно. Интерфейсы бывают разные и лепить объекты в простом интерфейсе с одним тулбаром, меню и даже гридом совершенно не обязательно. Делал не одну сотню раз и не сложно абсолютно. Для этого: <Прошу на словах не ловить. Привожу лишь общие моменты, но со знанием дела.>
1. Создаем окно необходимого типа.
2. Окно каждого зарегистрированного в системе типа имеет набор определенных стилей, которые создают первоначальный базовый необходимый вид. С помощью определенных и уж прекрасно описанных наборов идентификаторов сообщений, можна в доступных пределах регулировать по мере возможности этот вид. Необходимо сделать custom? Очень быстро перекрываем оконную процедуру и делаем доработку необходимой функциональности и при этом никто не мешает оригинальную базовую преобработку вызывать из оригинала. Есть необходимый дополнительный набор API для некоторых контролов для синхронизации в роамках темы привязок и тому подобного. Есть прекрасный раздел using any that I want и вперед.
3. Ты прав в одном и это уже догма, так что надеюсь, что здесь даже спора нет. В объекты это объединять значительно правильнее.
>>МФСи по сути те же костыли, только сделанные производителем.
Без MFC значительно сузился бы круг разработчиков. Так что на этапе ее создания не будем умолять ее удобства, хотя она была обречена на замену.
>>Идея ООП - как уже тут говорилась идеально подходит для создания интерфейса. Причина проста, интерфейс по принятым в винде параметрам легко укладывается в понятие >>объекта (окно, меню и т.д.)
Конечно. С этим даже никто и не спорит. Любая сущность имеющая свойства укладывается в понятие объекта.
>>Наследуя свойства базового объекта не обяхзательно использовать их все.
Фраза очень общая и совершенно логичная и поэтому не знаю как это касется предыдущих высказываний.
>>Скажем начав писать свой ГУИ, я столкнулся с тем, что МФСя не дает возможности быстро и легко сделать то, что надо.
>>Все новомодные штучки - знятие достаточно муторное.
Согласен с тобой, а все потому что на этапе разработки перемудрили со взаимосвязями интерфейсов и поэтому перекрывая функциональность очень четко нужно придерживаться документации, что не всегда удобно.
>>Во что оно выливается:
>>1. Сосбтвенно создание самого контроля Custom Control (кто писал - поймет меня) базовым для которого будет класс CControlBar.
>>2. Написание своих методов обработки и рисования объекта на экране.
>>3. Отладка всевозможных случаев работы с интерфейсом со стороны юзера.
>>4. Написание новых классов использующих мои контроли в качестве базовых, для создания своих интерфейсов к конкретной программе, которая ничего общего с пунктами 1 и 2 не имеет. Просто окошко которое раньше было статически прикрепленным теперь уезжает вбок.
Комментировать можно сколько угодно. Скажу лишь одно, что использование чужой библиотеки оправдано лишь дополнением функциональности, либо не принципиальным изменением параметров. Зная происхождение самих кастомных контролов и их нижний уровень интерфейса, сделать любой кастом мазахизмом является лишь до определенного этапа, но от этого и зависит то как перфектно ты сможешь реализовать свой супер интерфейс. Поэтому если ты не нашел контрол, который достаточно лишь кастомизировать измененем базовых парамтеров лиюбо дополнением небольшой функциональностью, то прощу написать свой. Не сложно. Начнем спорить по этому поводу, напишем книгу "Бой двух теней в контексте окна за владение элементами интерфейса".
>>Таким образом - с одной стороны есть
>>1. Опасность чужих багов.
Волка боятся - в лес не ходить. Ты когда выбираешь себе библиотеку имеешь кучу stress tests для определения ее безглючности. Дальше - это уже твои баги. Выбор уже есть и практически на все.
>>2. Опасность работы с чужим кодом который нельзя поменять или нет возможноси поменять.
В слова поменять ты мог вкладывать не тот смысл, который я мог воспринять, но менять чужой код это изначально ошибочная идея. Безглючный вариант данного мероприятия гарантируется лишь при полном описании всего механизма этого чужого кода. Нужно дополнять или перекрывать функциональность, согласно оговоренного интерфейса. И если как ты говоришь этого сделать нельзя, тогда библиотеку использовать только как возможную документацию. Это правило и жизнь и никуда нам от этого не спрятаться не скрыться.
>>3. Нагруженность программы чужеродной библиотекой с кучей ненужных параметров.....
Современные компиляторы и технологии позволяют этого избежать и это проблемы разработчиков библиотеки, а не твои.
>>Я проанализировав ситуацию - сделал следующие выводы.
>>1. Никто мне не гарантирует, что я сам не понаделаю кучу багов написав базовые контроли.
Этого никто не гарантирует и от третьего производителя и никем и нигде. Не бывает программ без ошибок. Бывают лишь различная степень их проявления и периодичность. Это не я сказал, а родоначальники того, чем мы сейчас занимаемся.
>>Причина проста, свои контроли я писал давно, и более того - они были много менее функциональны. Сидеть и писать контроли вместо программы мне лениво.
Все что ты пишешь - это программа. Ты наверное имел ввиду разницу между враппером и алгоритмом.
>>2. Я так же не могу поменять код базовых контролей от винды (МФС) которые
>>а) имеют свои баги !
>>б) не всегда делают то, что мне нужно.
>>в) так же прогружают меня лишними текстами....
Сделать это можна
но ты поймешь меня почему этого делать не нужно, если ты хоть раз глубоко закапывался в MFC.
Еще раз повторяю можна и не сложно, но это более порочный путь чем любые другие.
>>3. Взяв чужую, но отлаженную библиотеку, я получаю те же базовые классы как и МФС но уже в нужном мне виде.
Если они полностью удовлетворяют, то да, но в жизни это практически не осуществимо, если эти контролы не стандартны.
1. Потому что третьи библиотеки кустомизят интерфейс лишь в стандартной его части и делают оболочку для работы с полным набором свойств, что как ты упоминал выше редко бывает нужно. И это не сложно зная и увидев мезанизм самому сделать и упростить, но учитывая очень много парамтеров оганичивающих качество и время разработки, тут можна делать любые финты. Все очень от многого зависит.
>>4. При нынешних размеров винчестеров, лишние пара мег библиотеки не является акутальной темой....
Эта фраза применима к сегодняшней жизни, но я никогда не придерживаюсь подобной догмы, поскольку тянет в яму и расслабляет мозги.
>>Вывод.
>>Если контроли которые я просматриваю мне подойдут и условия лицензирования будут приемлемы, то я
>>а) использую их как базовые.
>>б) при необходимости перегружу важные функции, которые и принесут мненеобходимую функциональность, затратив на все это намного меньше времени.
>>в) получу новый стандартный интерфейс с возможностью создать на его базе то, что мне понадобится.
>>г) буду заниматься самой программой и иметь сразу ее в презентабильном виде, а не в виде предложенном выше в виде лубочной аппликации для последующего доведение ГУИ до ума.
Выводы ты сделал совершенно правильно, лишь с небольшим уточнением, что лубочные аппликации делают лишь люди которые пишут ногами.
>>Ура.
>>Что делать с основными багами. Во первых есть исходники которые я могу сам подправить и так убрать баги.
>>Что делать с новоыми мне необходимыми разрботками, которые отсутствуют в покупном материале. писать самому нужный контроль на базе имеющихся или МФС - что не >>противоречит никакой лицензии ИМХО.
Ты имеешь право делать все что угодно.
___________________________________________
>>Теперь о задаче
>>Саму идею я раскрывать вот так не хочу. Суть - необходимо сделать очень крупный проект , типа студии разработки но не для разработки программ, а несколько специфического >>материала.
>>В планах, свой язык и парсер, работа с железом - драйвера.
>>С удовольствием приму помощь проверенных друзей, при успехе предприятия поделюсь славой и деньгами естественно.
Думаю что слов для восприятия достаточно и мы с тобой прекрасно понимаем что делаем. А выводы как говориться делайте сами.
все мы здесь коллеги и поэтому в определенном смысле друзья, так что благодарю за плодотворное обсуждение.
Я тоже безумно люблю реализацию алгоритмов по сравнению со стндартной писаниной интерфейса, но мы только предполагаем, а все остальные нас располагают как хотят.
