グラフィックライブラリーをゼロから作成する - ページ 3

新しいコメント
 
Maxim Kuznetsov:

エンジニアリングについて簡単に説明すると:

もし、ある「A」を再開発で改善したいという気持ちがあるのなら、その決定的な欠点を特定する必要がある。ただ、それらを列挙して、なぜAの進化の過程で難航しているのかを説明すればよい。

一方で、誰もそれを禁じてはいない。コードを書くのが好きなら書けばいい。A "を自分流に書き換えてみてください。

マックス、ハイ！

さて、私の視点から見た標準 ライブラリとAnatolyのライブラリの「欠点」は、すでに繰り返し説明してきました。

つまり、インターフェースにコントロールが多ければ多いほど、チャート自体にも分離されたオブジェクトが増えるということです。一方ではこれは問題ないように見えますが、他方ではドラッグ＆ドロップダイアログで、単一の「要素を持つフォーム」オブジェクトではなく、多くの異なる要素がドラッグ＆ドロップされるため、問題となるのです。そして、これにはさらなるリソースが消費されます。

アナトリーのライブラリーはとてもシックですが、構成が複雑で、メインプログラムに組み込むのが難しいです。また、標準ライブラリは、オリジナルのアーキテクチャは非常に良いと思うのですが、コントロール自体に制限があります。

実際、Petr Konovがやろうとしていることがベストソリューションでしょう。GUIコードを生成するGUIビルダーですが、拡張イベントモデルを備えているので、メインプログラムに統合するときに、膨大なGUIコードに手をつける必要がありません（MVVMアナログみたいなもの）、もちろん、ユーザーが独自に拡張できるオブジェクトを備えています。

 
Алексей Барбашин:

マックス、ハイ！

さて、私の視点から見た標準 ライブラリとAnatoly氏のライブラリの「欠点」は、すでに何度も説明してきました。

つまり、インターフェースにコントロールが多ければ多いほど、チャート自体も孤立したオブジェクトになるということです。一方ではこれは問題ないように見えますが、他方ではドラッグ＆ドロップダイアログで、単一の「要素を持つフォーム」オブジェクトではなく、多くの異なる要素がドラッグ＆ドロップされるため、問題となるのです。そして、これにはさらなるリソースが消費されます。

アナトリーのライブラリーはとてもシックですが、構成が複雑で、メインプログラムに組み込むのが難しいです。また、標準ライブラリは、オリジナルのアーキテクチャは非常に良いと思うのですが、コントロール自体に制限があります。

実際、Petr Konovがやろうとしていることがベストソリューションでしょう。GUIコードを生成するGUIビルダーですが、拡張イベントモデルを備えているので、メインプログラムと統合するときに膨大なGUIコードを書く必要はありませんし、もちろんユーザーが独自に拡張できるオブジェクトも備えて います。

引用文は下から上へ読むこと。下（下線部）の方が重要です。決定的なのは、これです。

現代はあらゆるヒューマンインターフェイスが発達しているので、座標ビューやフォームエレメントが前面に出てくるのは、むしろ驚きなんです。
同時に、誰もがRest/Ajaxでブラウザを使い、MVCとは何かを知っていますが、Expert AdvisorとそのGUIとの間のインターフェースについては考えていません。

モデルが記述され、それを扱うプロトコルがあれば、GUIは何でもよく、Expert Advisorに依存することはない。Expert Advisorにウィンドウを入れると、これはある種の悪だ。Expert Advisorの主な目的は取引であり、他のすべてはメインコードから除外され、オプションであるべきです。

 
Maxim Kuznetsov:

引用文は、下から上へ正しく読む必要があります。下（下線部）の方が重要です。それは、決定的なものです。

ヒューマンインタフェースが発展してきた現代において、座標表現とフォームエレメントが前面に出てくることは非常に驚くべきことです。
同時に、誰もがRest/Ajaxでブラウザを使い、MVCとは何かを知っていますが、Expert AdvisorとそのGUIとの間のインターフェースについては考えていません。

モデルが記述され、それを扱うプロトコルがあれば、GUIは何でもよく、Expert Advisorに依存することはない。Expert Advisorにボックスを置くと、これはある種の悪だ。Expert Advisorの主な目的は取引であり、他のすべてはメインコードから除外され、オプションであるべきです。

当初、開発者はインターフェイスの機能が必要になるかもしれないということを考えなかったと考えるべきでしょう。思い起こせば、初期のころのmqlにはOOPすらなく、インジケータを書くことだけが主目的で、すべてがそのために設計されていたのです。

そして今、私たちは、mqlがすでにソケットやデータベースを、コアレベルでも動作させていることを知りました...。しかし、ユーザーとプログラムとのインタラクションの仕組みは置き去りにされている。

開発者自身は10年近く前に、インターフェースの開発はユーザーとアプリケーション間のインタラクションの非常に重要なメカニズムであると宣言し、この場合のための標準ライブラリを 開発したが、そのタスクへの適用性だけは示されておらず、実際今日でも多くのプログラマはその存在に気づいていない。

隙間をなくすようにします。他の参加者が必要としなくても、とにかく一定の経験を積むことができるのです。

 
Alexandr Andreev:

私はあなたのライブラリから始まり、それをありがとうございました、そして私はそれを少しいじり、さらに、さらに、さらに))) ライン関数の書き換えを含むすべてを変更し、Kanvasソースからの広いライン関数、偽関数の削除、イベントにスタブを置きました。他の要素にバイナリサーチによる左右のバーの計算を追加し、さらにバイナリサーチ自体に大小を選択できる機能を追加しています。また、あらゆる種類の配列（時系列/共通）からビルドする機能を追加しました。 そして、コンストラクタを変更すべきという結論に至りました))))

かっこいい。

そうですね、ライブラリは、初心者のための普遍的なものと、上級者向けの狭義のものとが必要ですね。

私自身、iCanvasは目的別にいくつかのバージョンを持っています。

そのため、意図や目標を立てたり、せめて方向性を示したりするようになったのです。そして、このリストを編集可能な状態で最初の投稿に入れる。

  
//whats TD (template define)? because TT is busy
//почемуто этот код в шаблонах на мкл не хочет компилироваться поэтому через дефайн - это Плохо надо бы через шаблоны как то придумать.... привет метаквотам
#define  TD1 int
#define  TD2 double 
#define  EMPY -1 
#define  GET this.operator>> 
#define  SET this.operator<< 
class CCoordD; 
class CSizeD;
class CCoordBaseD //полностью внутрений класс
   {
   private:
   #define  ME CCoordBaseD 
   TEMPL1(T)
   bool Chek(T *a)                  {return CheckPointer(a)!=POINTER_INVALID;}
   TEMPL1(T)
   bool Chek(T a)                   {return a!=(T)EMPY;}
   TD1 Error()                      {Print(__FUNCTION__," ",__LINE__," POINTER_INVALID size"); int a[]; a[0]=0; return (TD1)EMPY;};//wtf??? =P CRASH Error
   TD1 GetA()                       {return c.GetA()+ar;}
   TD1 GetP()                       {return c.Result() + size.GetP()*(TD1)pr;}
   public:
   ME()                                   {Init();} 
   ME(TD1 a)                              {Init(a);} 
   ME(TD1 a,CCoordD &b)                   {Init(a,b);} 
   ME(TD1 a,CCoordD &b,CSizeD &x)         {Init(a,b,x);} 
   ME(TD2 a,CSizeD &b)                    {Init(a,b);} 
   ME(TD2 a,CCoordD &b,CSizeD &x)         {Init(a,b,x);} 
   CCoordD *c;//one coord
   CSizeD *size;//size 
   TD1 ar;
   TD2 pr;//percent проценты
   void Init()                            {ar=(TD1)EMPY; pr=(TD2)EMPY; }  
   TD1 Result()                           {return Chek(ar)?Chek(c)?GetA():ar:Chek(pr)?Chek(size)?GetP():Error():(TD1)EMPY;}
   ME *GetMe()                            {return &this;}
   ME *GetCoorBase()                      {return c;}
   ME *GetSizeBase()                      {return size;} 
   CCoordD *GetCoor()                     {return c;}
   CSizeD *GetSize()                      {return size;} 
   void Init(TD1 a)                       {Init(); SET(a);}
   void Init(TD1 a,CCoordD &b)            {Init(); SET(a); SET(b);}
   void Init(TD1 a,CCoordD &b,CSizeD &x)  {Init(); SET(a); SET(b); SET(x);}
 //  void Init(TD2 p)                     {Init(); pr=p_;}
   void Init(TD2 a,CSizeD &b)             {Init(); SET(a); SET(b);}
   void Init(TD2 a,CCoordD &b,CSizeD &x)  {Init(); SET(a); SET(b); SET(x);}
   void operator >> (TD1 &a)              {a=ar;} 
   void operator >> (TD2 &a)              {a=pr;}  
   void operator >> (CCoordD &a)          {a=GetPointer(c);}  
   void operator >> (CSizeD &s)           {s=GetPointer(size);}  
   void operator << (TD1 &a)              {ar=a;} 
   void operator << (TD2 &a)              {pr=a;}  
   void operator << (CCoordD &a)          {c=GetPointer(a);}  
   void operator << (CSizeD &s)           {size=GetPointer(s);}  
   void operator << (ME &a)               {a>>c; a>>ar; a>>pr; a>>size;}  
   void operator = (CCoordD &a)           {SET(a);}
   void operator = (CSizeD &a)            {SET(a);}
   void operator = (ME &a)                {SET(a);} 
   #undef  ME
   #undef  TD1
   #undef  TD2
   #undef  GET 
   #undef  SET
   };
   
class CSizeD : public CCoordBaseD
   {
   public:
   CSizeD(){};
   };
   
class CCoordD : public CCoordBaseD
   {
   public:
   CCoordD(){};
   };

class CTX {public:CTX(){}}; 
class CTY {public:CTY(){}};
class CTZ {public:CTZ(){}};
TEMPL(T)
class CCoordA : public T
   {
   public:
   CCoordA() {};
   CSizeD size;
   CCoordD ar; 
   void operator <<(CSizeD &a)   {return ;}
   void operator <<(CCoordD &a)  {return ;}
   };
   
class CCoord
   {  
   public: 
   CCoordA<CTX> X;
   CCoordA<CTY> Y; 
   CCoord ()                              {} 
   bool MouseOn(CMouse &mouse)//px
      {
      //return X.ar.Result()<=mouse.X && X.ar.Result()+X.size.Result()>=mouse.X && GetY()<=mouse.Y && GetY()+GetH()>=mouse.Y;
      return false;
      }
   };  
 

とにかく、私が何か間違ったことをしているか、クラス宣言（空）テンプレートが動作したくないかのどちらかです。そのため、このコードは特に便利なものではありません。

を変えようと思っています。

 
こんな美しいコードなら、展覧会に持っていってもよさそうだ。何のために、どのように、何を解決するのかは不明ですが、とても美しいです...。
 
みんな、私に教えてくれたんだから、私も教えてあげる。

そもそもGUIの仕組みがどうなっているのかを理解した上で、コードを書き始めるべきでしょう。元素の構造と挙動、様々な状況下での反応について知っておく必要があります。まず、テンプレートとして提示し、イベントモデル、ステートハンドラ、現象、座標、バインディング、描画など、用意された技術基盤の上にインスタンスを作成する。最終的には、キャンバス上に生のグラフィックライブラリが 出来上がります。マークアップ言語には程遠いでしょう。編集者はもちろんのこと。でも、頑張れ。

既成のものをそのまま、より高いレベルに引き上げようというのでは、まともな開発はできないでしょう。
 
Реter Konow:
みんな、私に教えてくれたんだから、私も教えてあげる。

そもそもGUIの仕組みがどうなっているのかを理解した上で、コードを書き始めるべきでしょう。元素の構造と挙動、様々な状況下での反応について知っておく必要があります。まず、テンプレートとして提示し、イベントモデル、ステートハンドラ、現象、座標、バインディング、描画など、用意された技術基盤の上にインスタンスを作成する。最終的には、キャンバス上に生のグラフィックライブラリが出来上がります。マークアップ言語には程遠いでしょう。編集者はもちろんのこと。でも、頑張れ。

既成のものをそのままパクると思っているようでは、まともな開発はできないでしょう。

判断は待ってくれ......基本以上のものでもない。そして、GUIを完成させるということは、まずあり得ない--最初にそう言ったんです。大規模プロジェクトについては......あなたのコードラインでは大規模プロジェクトに太刀打ちできないので、そう言っているのですが......。


問題は、なぜその仕掛けがうまくいかないかである。

class CB; 
class CC;

class CBx{public: CBx(){};};
class CBy{public: CBy(){};};
TEMPL(T) 
class CA : public T
   {
   public:
   CA(){}
   CB<T> *b;
   CC<T> *c;
   };
    
TEMPL(T) 
class CB : public CA<T>
   {
   public:
   CB(){}
   };
    
TEMPL(T) 
class CC : public CA<T>
   {
   public:
   CC(){}
   }; 

CB<CBy> cc;
 
Alexandr Andreev:

...

さて、問題は、なぜこのトリックがうまくいかないのか、ということです。

なぜうまくいかないのか、誰にもわからない......。

ライブラリのスキーマを先に作り、その後にコードを書く。普通はそうですよね。
12345678910...15
新しいコメント