Разделение интерфейса и кода, подскажите

В приложении планируется стандартный дизайн, и скиновый. Подумалось что нужно сделать главную форму невидимой, а весь интерфейс размесить на двух других формах - на одной скиновый, на другой - обычный виндовый. При выборе одного из вариантов форма другого варианта освобождается из памяти, а другая создается и наоборот. Главная форма при этом невидимая и не участвует ни в чем. Что скажете? Могут быть какие то косяки?

Еще подумал, что при таком раскладе чтобы не зависеть от выбранной формы представления визуальных контролов нужно создать промежуточные классы, например класс VisualControls, он содержал бы в себе абстрагированные объекты типа FileList, CheckBoxSelectAll, при манипуляции с которыми класс сам решал бы какой форме отправить результирующее воздействие - скиновой, или нормальной, а код таким образом совершенно становится независимым от интерфейса. Работы больше, но вроде как так грамотнее. Или я так только багов наплодить могу? В общем поделитесь опытом кто уже решал подобные проблемы.

Добавлено 23.01.07, 15:44
я вот еще поясню. Например в коде нужно узнать, нажата ли кнопка. Глупо же наверное прям в функции писать условия типа

case ViewStyle of
normal: if SpeedButtonStartCopy.down then ...
skinable: if ImageButtonStartCopy.down then ...

Наверное нужно обратиться к общему классу ButtonStartCopy.Down, которое объявить как property, таким образом

TButtonStartCopy = Class
  Ptivate
  
  FDown: Boolean;
  function GetDown():boolean;
  
  Public
 
  Property Down: Boolean read GetDown write FDown;
 
end;
 
 
function TButtonStartCopy.GetDown():boolean;
begin
  case ViewStyle of
    normal: result := SpeedButtonStartCopy.down;
    skinable: result := ImageButtonStartCopy.down;
end;

Я мыслю в правильном направлении? Смущает только что придется на каждый контрол писать класс-посредник, с практически идентичными полями, т.е. может быть в виде класса посредника взять уже готовый класс (в данном случае TSpeedButton) и в нем просто переопределеить нужные методы? Вроде как меньше гимора должно быть. Только правильно ли это?

мыш, если нужно написать приложение со скинами, то нужно пользоваться компонентами, которые поддаются скиннированию (а таких полно). Если конечно нет цели написать что-то вроде Windows Media Player, где действительно есть основное окно и "режим обложки". Делать же разные формы – неразумно.

Smike, ты хочешь сказать что все приложения использующие скины идут по пути использования компонентов третьих лиц? Так почему то неохота это делать.. Не люблю я сторонние компоненты, итак глюков хватает в своем коде, а тут еще чужой добавляется...

Цитата Smike @ 24.01.07, 05:17

Делать же разные формы – неразумно.

Цитата Smike @ 24.01.07, 05:17

Windows Media Player, где действительно есть основное окно и "режим обложки"

Т.е. вывод из этого что WMP написан неразумно?

Цитата мыш @ 23.01.07, 15:21

Что скажете?

Скажем - это полное безобразие.
Тебе в MSDN, читать что такое DrawTheme* и DrawFrameControl. Не знаю как там в дельфи, а в VB есть возможность создать свой UserControl, и рисовать из него в двух режимах: скин (рисунок на DC) и стандартная тема Windows (рисовать на DC через указанные API).

Цитата мыш @ 25.01.07, 19:49

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

Нет, некоторые пишут свои компоненты/отрисовку

Цитата мыш @ 25.01.07, 19:49

Т.е. вывод из этого что WMP написан неразумно?

Я этого не говорил, просто там есть 2 режима: полный вид, но без скинов или "режим обложки" со скинами. А ты хочешь, чтобы пользователь мог использовать один и тот же интерфейс со скинами и без скинов.

Цитата B.V. @ 25.01.07, 22:47

Не знаю как там в дельфи, а в VB есть возможность создать свой UserControl, и рисовать из него в двух режимах: скин (рисунок на DC) и стандартная тема Windows (рисовать на DC через указанные API).

Сделано еще удобнее У компонентов есть события отрисовки, к тому же можно перекрыть как низкоуровневые события отрисовки (WM_PAINT, PaintControl) и рисовать на DC, так и высокоуровневые, пользуясь классом, инкапсулирующим функции GDI – TCanvas.

В общем понятно что делать если скины - это просто другая отрисовка компонентов, которые все равно остаются на своих местах. А что делать если скин - это совершенно иной вид, компоненты меняют свои места, размеры, расположение? Меню исчезает, форма окна меняется. Пример - режим оболочки WMP. Выходит в этом случае самый простой и безболезненный способ все-таки использовать отдельную форму?

Цитата мыш @ 26.01.07, 08:38

Выходит в этом случае самый простой и безболезненный способ все-таки использовать отдельную форму?

Нет, использовать "поддержку прозрачного цвета".

Цитата мыш @ 26.01.07, 08:38

А что делать если скин - это совершенно иной вид, компоненты меняют свои места, размеры, расположение?

Для этого создают динамически все элементы окна. В том числе по конфигурационным файлам (WMP – яркий пример).

Мыш, ну ты загнул!

Не проще вынести весь ГУИ в отдельный модуль? Который будет торчать наружу набором интерфейсов: типа показать сообщение, спросить имя собаки, запустить форматирование диска Ц.
И реализуй ты этот интерфейс как хочешь - хоть на Вин32 АПИ, хоть со скинами. И подгружай ДЛЛку динамически.

deil, я так не делал никогда, с первого взгляда мысль понравилась Только что-то тут подозрительное ощущается... Как будто бы это как то ограничивает... Не знаю, надо думать.

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

Если всё-равно боишься - вот более извращенный способ:
объект UI пускается в отдельном потоке и всё, что получает на вход - событие, которое надо обработать; результат обработки - тоже посылаемое взад событие; обработка идёт в порядке очереди и асинхронная; типа:
- Ядро: UI, хочу имя собаки!
- UI: принято
... жую сопли ...
- UI: Ядро, собаку зовут "Бобёр"
- Ядро: спасибо

В таком случае ты не ограничен почти ничем





А теперь.. ещё раз взгляни на первый способ. Правда, он классный?

По поводу skinable-интерфейса, советую делать так как у PowerDVD. Там формы в разных DLL-ках, функционал - в самой программе. Делал DVD-плеер, похожий к PowerDVD. Результат работы со скинами впечатляет

Цитата Smike @ 26.01.07, 16:29

Для этого создают динамически все элементы окна. В том числе по конфигурационным файлам (WMP – яркий пример).

Цитата 2005fs @ 15.09.07, 19:39

Там формы в разных DLL-ках,

Smike, смотри-ка, взрослые дяди делающие PowerDVD не парились с конфигурационными файлами, а пошли тем путем который я изначально и описал Я так понимаю что единственный плюс динамического создания контролов - экономия памяти, ведь скомпиленная в dll форма весит много больше чем xml или dfm файл. Но видишь, товарищи из PowerDVD не парились. Нафига оно простым смертным?

Мыша, а в чем связь с твоим методом? Там как раз все по другому вроде бы: реакция на событие одна, а вот диалоги разные, каждый по своему отрисовывается. Ты же предлагал сделать 2 интерфейса с 2 разными обработчиками, что есть глупость. Здесь — один взаимозаменяемый пользовательский интерфейс и одно общее ядро.

мыша бла
У динамического создания формы есть одно огромнейшее преимущество: я могу сделать свой собственный скин для WMP, BSPlayer'а или WinAMP'а (я имею в виду пятый) при помощи любимого графического редактора, любимого текстового редактора и архиватора (подойдет встроенный в Total Commander). По крайней мере для BSPlayer'а я подгонял понравившиеся скины под свои предпочтения. Единственно чем динамическая форма уступает, это тем, что она чуток медленнее отрисовывается, но она не сильно загружена работой, так что заметить это непросто.
Для создания же собственного скина, как dll'ки требуется программировать модуль.
Соответственно, программа теряет популярность. Возможность нарисовать собственный скин, даже если человек его никогда рисовать и не будет, довольно привлекательна.
В результате все равно придется писать dll'ку для поддержки динамических форм, и скорее всего она вскоре станет основной если не единственной используемой.

Да если всегда надо иметь некоторый скин по умолчанию.