Zorro: 1) MFC аналог, пользователь перегружает все нужные методы и изменяет поведение стандартного класса. 2) WPF аналог, описываем интерфейс(например с помощью XML) и передаём в библиотеку набор классов ZoAction
Судя по описанию, 2 вариант будет жутким тормозом в сравнении, имхо
Комбинатор: Судя по описанию, 2 вариант будет жутким тормозом в сравнении, имхо
Только при создании формы, в работе должно быть одинаково. ZoUI строит ГУЙ по XML разметке и проставляет всем созданным объектам соответствующие ZoAction, во время работы по скорости должно быть как и MFC аналог, вот только с гибкостью у WPF аналога возможны проблемы...
Zorro: Есть у меня слабенький аргумент в пользу WPF - MFC аналог есть в стандартной библиотеке, зачем второй велосипед...
В стандартной библиотеке сделано на графических объектах. Здесь идет разговор про рисование сразу на канве. В любом случае сначала делать классы. Делать ли рисование интерфейса через XML это дело 10-е. Так же и в WPF можно через XML, а можно обычным образом с классами поработать, только писанины больше (немного).
Реализация MFC аналог уже есть и работает (бета), задумал я в последней версии выделить имплементацию базы UI от (назовём это) User Level части, аргумент один - избавить конечного пользователя от кишок базы UI, вот как это выглядит:
// пользовательский класс - фактически это интерфейсclass ZoFrame : public ZoBase
{
protected:
ZoFrame *m_impl;
bool Create(...) { m_impl=ZoFrameCreate(GetPointer(this),...); return(m_impl!=NULL); }
virtualvoid Destroy() { m_impl->Destroy(); }
virtualvoid GetFrameRect(ZoRect &rc) { m_impl->GetFrameRect(rc); }
virtual ZoFrame *GetParent(void) { return(m_impl->GetParent()); }
virtualvoid OnPaint(ZoGraph &graph) { }
virtualbool OnCreate() { return(true); }
virtualvoid OnDestory() { }
virtualbool OnMouseOver(bool over); // over = мышь вошла(true) или покинула (false) RECT объектаvirtualvoid OnMouseMove(int x,int y,uint key_state) { }
virtualvoid OnLButtonDown(void) { }
virtualvoid OnLButtonUp(void) { }
virtualvoid OnClick(void) { }
};
// класс библиотекиclass ZoFrameImpl : public ZoFrame
{
protected:
// тут куча полей, таких как ZoRect, флаги состояния объекта, ссылка на родительское окно и список child-ов и т.п.void OnMouseMove(int x,int y,uint key_state) { m_impl->OnMouseMove(x,y,key_state); }
public:
// далее куча внутренних методов для работы UI// например:bool MouseMove(int x,int y,uint key_state)
{
// проверка на попадание x,y в данный Frame// сначала перебираем child-ов, возможно MouseMove принадлежит им// если не child, то вызываем обработчик пользователя
}
};
ZoFrame : ZoBase // базовый класс для контролов, которые помещаются на ZoWindow ZoWindow : ZoFrame // класс который владеет своим канвасом и имеет объект на графике(чарте)
Это самом собой, от этого никуда не деться. Смысл в том, чтобы картинка была любая. Т.е. у контролов должны быть методы для установки картинок для внешнего вида.
1) MFC аналог, пользователь перегружает все нужные методы и изменяет поведение стандартного класса.
2) WPF аналог, описываем интерфейс(например с помощью XML) и передаём в библиотеку набор классов ZoAction
Судя по описанию, 2 вариант будет жутким тормозом в сравнении, имхо
ZoUI строит ГУЙ по XML разметке и проставляет всем созданным объектам соответствующие ZoAction, во время работы по скорости должно быть как и MFC аналог, вот только с гибкостью у WPF аналога возможны проблемы...
Есть у меня слабенький аргумент в пользу WPF - MFC аналог есть в стандартной библиотеке, зачем второй велосипед...
В стандартной библиотеке сделано на графических объектах. Здесь идет разговор про рисование сразу на канве. В любом случае сначала делать классы. Делать ли рисование интерфейса через XML это дело 10-е. Так же и в WPF можно через XML, а можно обычным образом с классами поработать, только писанины больше (немного).
Реализация MFC аналог уже есть и работает (бета), задумал я в последней версии выделить имплементацию базы UI от (назовём это) User Level части, аргумент один - избавить конечного пользователя от кишок базы UI, вот как это выглядит:
Как думаете, я на правильном пути?
ZoFrame : ZoBase // базовый класс для контролов, которые помещаются на ZoWindow
ZoWindow : ZoFrame // класс который владеет своим канвасом и имеет объект на графике(чарте)
ZoButton : ZoFrame // кнопка
ZoDateTimePicker : ZoFrame // контрол даты/времени
ZoComboBox : ZoFrame // комбобокс
ZoImage : ZoFrame // иконка
...
Народ, есть ли способ проверить, а не создан ли уже кем-то другим динамический ресурс с таким же именем?
В теории - нужно проверить:
Берем ResourceReadImage() - если она возвращает false и значение ширины и высоты при этом не поменялись - ресурса с проверяемым именем точно нет.