MQL разработчикам! Вы писали панельки на чистой канве? - страница 2

 
Zorro:
1) MFC аналог, пользователь перегружает все нужные методы и изменяет поведение стандартного класса.
2) WPF аналог, описываем интерфейс(например с помощью XML) и передаём в библиотеку набор классов ZoAction
Судя по описанию, 2 вариант будет жутким тормозом в сравнении, имхо
 
Комбинатор:
Судя по описанию, 2 вариант будет жутким тормозом в сравнении, имхо
Только при создании формы, в работе должно быть одинаково.
ZoUI строит ГУЙ по XML разметке и проставляет всем созданным объектам соответствующие ZoAction, во время работы по скорости должно быть как и MFC аналог, вот только с гибкостью у WPF аналога возможны проблемы...
 
Есть у меня слабенький аргумент в пользу WPF - MFC аналог есть в стандартной библиотеке, зачем второй велосипед...
 
Ну так дерзайте, посмотреть в любом случае будет интересно
 
Zorro:
Есть у меня слабенький аргумент в пользу WPF - MFC аналог есть в стандартной библиотеке, зачем второй велосипед...

В стандартной библиотеке сделано на графических объектах. Здесь идет разговор про рисование сразу на канве. В любом случае сначала делать классы. Делать ли рисование интерфейса через XML это дело 10-е. Так же и в WPF можно через XML, а можно обычным образом с классами поработать, только писанины больше (немного).

 
Ok, у меня ещё один вопрос.

Реализация MFC аналог уже есть и работает (бета), задумал я в последней версии выделить имплементацию базы UI от (назовём это) User Level части, аргумент один - избавить конечного пользователя от кишок базы UI, вот как это выглядит:

// пользовательский класс - фактически это интерфейс
class ZoFrame : public ZoBase
  {
protected:
   ZoFrame          *m_impl;
   bool              Create(...) { m_impl=ZoFrameCreate(GetPointer(this),...); return(m_impl!=NULL); }
   virtual void      Destroy() { m_impl->Destroy(); }

   virtual void      GetFrameRect(ZoRect &rc) { m_impl->GetFrameRect(rc); }
   virtual ZoFrame  *GetParent(void) { return(m_impl->GetParent()); }

   virtual void      OnPaint(ZoGraph &graph) { }
   
   virtual bool      OnCreate()  { return(true); }
   virtual void      OnDestory() { }
   virtual bool      OnMouseOver(bool over); // over = мышь вошла(true) или покинула (false) RECT объекта
   virtual void      OnMouseMove(int x,int y,uint key_state) { }
   virtual void      OnLButtonDown(void) { }
   virtual void      OnLButtonUp(void)   { }
   virtual void      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        // класс который владеет своим канвасом и имеет объект на графике(чарте)

ZoButton : ZoFrame               // кнопка
ZoDateTimePicker : ZoFrame  // контрол даты/времени
ZoComboBox : ZoFrame         // комбобокс
ZoImage : ZoFrame               // иконка
...
 
Это самом собой, от этого никуда не деться. Смысл в том, чтобы картинка была любая. Т.е. у контролов должны быть методы для установки картинок для внешнего вида.
 
Народ, есть ли способ проверить, а не создан ли уже кем-то другим динамический ресурс с таким же именем?
 
Комбинатор:
Народ, есть ли способ проверить, а не создан ли уже кем-то другим динамический ресурс с таким же именем?

В теории - нужно проверить:

Берем ResourceReadImage() - если она возвращает false и значение ширины и высоты при этом не поменялись - ресурса с проверяемым именем точно нет.