Fare un progetto in crowdsourcing su Canvas - pagina 39

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

...

Peter, hai fatto un ottimo lavoro nel creare una libreria GUI nel tuo stile. Ma se avete intenzione di pubblicarlo, vale ancora la pena di riprogettarlo con una tecnologia diversa. Sono pronto ad aiutarvi in questo e a trasferire passo dopo passo tutto il potere della vostra libreria in una nuova direzione.

Alexei, diciamo che sarei disposto a fare un tentativo. Come suggerisci di farlo? Il lavoro è incredibile.
 
Реter Konow:
Alexey, diciamo che vorrei provare. Come propone di farlo? È un lavoro impossibile.

Peter, probabilmente non riesco a immaginare nemmeno una piccola frazione della quantità di lavoro che hai fatto, e sono più che sicuro di aver semplicemente sottovalutato l'intera scala degli oggetti creati. MA!

Come sempre, c'è un MA!

Qualsiasi progetto, nemmeno necessariamente in programmazione.

Per cominciare, ci allontaniamo dagli oggetti che sono stati creati. Cioè, non li rappresenteremo come matrice, strutture o classi. Accetteremo semplicemente la nozione di un OGGETTO (alias elemento di controllo, alias forma, alias interfaccia nel suo insieme, e così via). Provate a stabilire l'interazione degli oggetti in modo strutturale. Quando scopriremo insieme ciò che è costruito, cercheremo di rivelare le regolarità su questa base. In linea di principio, non dovrete identificarli perché li avete identificati molto tempo fa e avete fatto un trattamento unificato per loro, spiegherete semplicemente il principio di funzionamento e lo scopo. Poi sostituiremo semplicemente un oggetto con un altro nel vostro progetto. Naturalmente, sarà molto più difficile che scrivere da zero. Ma nel nostro caso abbiamo un obiettivo leggermente diverso, quindi in linea di massima non c'è fretta. Ma le pubblicazioni sulla traduzione dell'algoritmo della matrice nell'algoritmo dell'oggetto sarebbero probabilmente interessanti non solo per i principianti. Sono convinto che nel processo di questo lavoro altri partecipanti si uniranno a noi e condivideranno le loro idee o suggeriranno un'implementazione più conveniente di questo o quell'algoritmo.

In un modo o nell'altro, l'idea stessa deve essere prima rappresentata da un diagramma di flusso dell'algoritmo.

Ho dato il mio suggerimento. Ma si può fare altrimenti, tutto dipende dal vostro desiderio e dalla vostra visione della questione (lavoro comune).

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

Peter, probabilmente non riesco a immaginare nemmeno una piccola frazione della quantità di lavoro che hai fatto, e sono più che sicuro di aver semplicemente sottovalutato l'intera scala degli oggetti creati. MA!

Come sempre, c'è un MA!

Qualsiasi progetto, nemmeno necessariamente in programmazione.

Per cominciare, ci allontaniamo dagli oggetti che sono stati creati. Cioè, non li rappresenteremo come matrice, strutture o classi. Accetteremo semplicemente la nozione di un OGGETTO (alias elemento di controllo, alias forma, alias interfaccia nel suo insieme, e così via). Provate a stabilire l'interazione degli oggetti in modo strutturale. Quando scopriremo insieme ciò che è costruito, cercheremo di rivelare le regolarità su questa base. In linea di principio, non dovrete identificarli perché li avete identificati molto tempo fa e avete fatto un trattamento unificato per loro, spiegherete semplicemente il principio di funzionamento e lo scopo. Poi sostituiremo semplicemente un oggetto con un altro nel vostro progetto. Naturalmente, sarà molto più difficile che scrivere da zero. Ma nel nostro caso abbiamo un obiettivo leggermente diverso, quindi in linea di massima non c'è fretta. Ma le pubblicazioni sulla traduzione dell'algoritmo della matrice nell'algoritmo dell'oggetto sarebbero probabilmente interessanti non solo per i principianti. Sono convinto che nel processo di questo lavoro altri partecipanti si uniranno a noi e condivideranno le loro idee o suggeriranno un'implementazione più conveniente di questo o quell'algoritmo.

In un modo o nell'altro, l'idea stessa deve essere prima rappresentata da un diagramma di flusso dell'algoritmo.

Ho dato il mio suggerimento. Ma si può fare altrimenti, tutto dipende dal vostro desiderio e dalla vostra visione della questione (lavorare insieme).

Tutto a posto. Farò quello che posso. Spiegherò le soluzioni e l'architettura. Ma non so se alla fine ci riuscirò.

Ora gli oggetti sono disposti nel kernel. Devono essere tolti dal kernel e messi in classi.

1. Probabilmente creerei tre classi di base: "Rectangle_label", che ospiterebbe tutte le proprietà di base delle etichette rettangolari, "Icon" e "Text". Questi oggetti fanno parte di quasi tutti i controlli.

2. Successivamente, create un gruppo di classi discendenti. Sarebbero divisi secondo i seguenti criteri: a) elementi che controllano un parametro. b) elementi che sono controllati dal parametro.

3. Le classi descriverebbero le proprietà specifiche di ogni elemento.

Queste sono solo le prime idee. Potrebbero sbagliarsi.

Con questo schema, l'ereditarietà risulta immediatamente essere multipla - le classi di elementi (eredi) devono includere le proprietà di tre classi base contemporaneamente.

 
Реter Konow:

Tutto a posto. Farò del mio meglio. Spiegherò le soluzioni e l'architettura. Ma non so se alla fine avrò successo.

In questo momento gli oggetti sono organizzati nel kernel. Devono essere tolti dal kernel e messi in classi.

1. Probabilmente creerei tre classi di base: "Rectangle_label", che ospiterebbe tutte le proprietà di base delle etichette rettangolari, "Icon" e "Text". Questi oggetti fanno parte di quasi tutti i controlli.

2. Successivamente, create un gruppo di classi discendenti. Sarebbero divisi secondo i seguenti criteri: a) elementi che controllano un parametro. b) elementi che sono controllati dal parametro.

3. Le classi descriverebbero le proprietà specifiche di ogni elemento.

Queste sono solo le prime idee. Potrebbero sbagliarsi.

Con questo schema, l'ereditarietà risulta essere plurale allo stesso tempo - le classi di elementi (discendenti) devono includere proprietà di tre classi di base allo stesso tempo.

Quindi ecco un po' di ragionamento.

"Creerei tre classi base: "Rectangle_label", che conterrebbe tutte le proprietà di base delle etichette rettangolari, "Icon" e "Text". - Classicamente, il primo oggetto si chiama semplicemente Rectangle o Rect, il secondo generalizzato Image, bene, il terzo può essere descritto da proprietà separate o anche fare un oggetto separato. Per indicare che il tipo di dati creato è una classe in c++ e in mql si usa indicare C prima del nome del tipo, cioè CRectangle, CImage, CText. Ma i tipi semplici che contengono solo dati eterogenei sono più convenienti da creare come strutture.

La prima cosa da considerare sono tutte le proprietà di base dei controlli LARGE. Più avanti potete aggiungere qualsiasi proprietà, non sarà un problema.

"a) elementi che controllano un parametro. b) elementi che sono controllati da un parametro". - Qui è necessaria una decifrazione. Non capisco cosa significhino queste descrizioni.

"ci sarà successo alla fine" - è ancora meglio essere sicuri che ci sarà successo. Altrimenti, è meglio non iniziare.
 
Алексей Барбашин:

Beh, ecco un po' di ragionamento.

1. "Creerei tre classi di base: "Rectangle_label", che conterrebbe tutte le proprietà di base delle etichette rettangolari, "Icon" e "Text". - Classicamente, il primo oggetto si chiama semplicemente Rectangle o Rect, il secondo generalizzato Image, beh, il terzo può essere descritto da proprietà separate o fare un oggetto bianco. Per indicare un tipo di dati creato come classe in c++ e in mql, si usa indicare C prima del nome del tipo, cioè CRectangle, CImage, CText

2. "a) elementi che controllano il parametro. b) elementi che sono controllati dal parametro". - Qui è necessaria una decifrazione. Non capisco cosa significhino queste descrizioni.

"Ci sarà successo alla fine" - è ancora meglio essere sicuri che ci sarà successo. Altrimenti, è meglio non iniziare.

1. La classe più elementare è GHObjest (oggetto grafico di base). Ci dovrebbero essere le proprietà x,y, x_size, y_sixe e diversi tipi di binding delle coordinate. Queste sono proprietà comuni a TUTTI gli oggetti.

2. i suoi discendenti sono CRec, CImage, CText. Hanno solo proprietà specifiche e intrinseche.

3. Poi, ci sono le classi della piattaforma della finestra. Ce ne sono diversi: finestra di menu, finestra delle opzioni, finestra di dialogo, finestra dinamica. Lì ci sono una serie di proprietà specifiche.

3. Poi, ci sono le classi di elementi. Possono essercene fino a 50. Sono divisi in categorie: 1) per metodo di elaborazione dei parametri, 2) per metodo ornamentale.

Questo è un buon punto di partenza. Dobbiamo fare un linguaggio di markup, non una libreria. Che senso ha altrimenti?


ZS La maggior parte dei controlli funziona con il parametro che gli viene dato. L'essenza del loro scopo è controllare qualche parametro dell'utente. Ma ogni controllo lo fa in modo diverso.

ZSY. Ho dimenticato di aggiungere - hai bisogno di una classe base di parametro con le sue proprietà. CParam per esempio.

 
Реter Konow:

1. La classe più elementare è il GOBijest (oggetto grafico di base). Ci dovrebbero essere le proprietà x,y, x_size, y_sixe e diversi tipi di binding delle coordinate. Queste sono proprietà comuni a TUTTI gli oggetti.

2. i suoi discendenti sono CRec, CImage, CText. Hanno solo proprietà specifiche e intrinseche.

3. Poi, ci sono le classi della piattaforma della finestra. Ce ne sono diversi: finestra di menu, finestra delle opzioni, finestra di dialogo, finestra dinamica. Lì ci sono una serie di proprietà specifiche.

3. Poi, ci sono le classi di elementi. Possono essercene fino a 50. Sono divisi in categorie: 1) per metodo di elaborazione dei parametri, 2) per metodo ornamentale.

Questo è un buon punto di partenza. Dobbiamo fare un linguaggio di markup, non una libreria. Che senso ha altrimenti?


ZS La maggior parte dei controlli funziona con il parametro che gli viene dato. L'essenza del loro scopo è controllare qualche parametro dell'utente. Ma ogni elemento lo fa in modo diverso.

Sto avendo un'esplosione di cervello... )) Bisogna disegnare tutto, altrimenti non si può digerire. )

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

Mi sta venendo un po' di confusione al cervello... )) Bisogna disegnare tutto, altrimenti non si può digerire. )

)) Niente...

La classe base dei parametri CParam ha diversi discendenti. Il punto è che ci sono proprietà generali dei parametri degli oggetti controllati, e ce ne sono di specifiche. Per esempio: un pulsante ha un parametro controllato di tipo bool, mentre un elenco a discesa ha un tipo "menu". Cioè, un pulsante alterna 1/0, mentre una lista offre una selezione limitata. Il cursore, per esempio, ha un tipo di parametro "range", cioè intervallo. Ci sono diversi altri tipi e tutti hanno proprietà uniche.

Pertanto, anche le classi che discendono dalla classe base dei parametri dovrebbero esserlo. Qualcosa come "CBool", "CRange", "CMenu".

 
Реter Konow:

)) Niente...

La classe base dei parametri CParam ha diversi discendenti. Il punto è che ci sono proprietà comuni per i parametri degli elementi controllati, e ce ne sono di specifiche. Per esempio: un pulsante ha un parametro controllato di tipo bool, mentre un elenco a discesa ha un tipo "menu". Cioè, un pulsante alterna 1/0, mentre una lista offre una selezione limitata. Il cursore, per esempio, ha un tipo di parametro "range", cioè intervallo. Ci sono diversi altri tipi e tutti hanno proprietà uniche.

Pertanto, anche le classi che discendono dalla classe base dei parametri dovrebbero esserlo. Qualcosa come "CBool", "CRange", "CMenu".

Aspetta. Proviamo a guardarlo ora in modo un po' più astratto.

Peter, dal tuo punto di vista, cosa hanno in comune controlli come Button, Text label, Input box, Picture box?

Документация по MQL5: Константы, перечисления и структуры / Константы объектов / Типы объектов
Документация по MQL5: Константы, перечисления и структуры / Константы объектов / Типы объектов
  • www.mql5.com
При создании графического объекта функцией ObjectCreate() необходимо указать тип создаваемого объекта, который может принимать одно из значений перечисления ENUM_OBJECT. Дальнейшие уточнения свойств созданного объекта возможно с помощью функций по работе с графическими объектами.
 
Алексей Барбашин:

Aspetta. Proviamo a guardarlo ora in modo un po' più astratto.

Peter, dal tuo punto di vista, cosa hanno in comune controlli come Button, Text label, Input box, Picture box?

1. Coordinate, dimensioni.

2. Dipendenze di coordinate, dipendenze di dimensioni.

3. un mucchio di altre cose a seconda del numero totale di proprietà nella funzionalità di controllo. Ho 270 proprietà nel mio nucleo. La maggior parte di loro sono comuni. Ma, ho una funzionalità sviluppata che supporta un sacco di caratteristiche. Quindi, un tale numero di proprietà. Dobbiamo iniziare con le proprietà più semplici.

 
Реter Konow:

1. Coordinate.

2. Coordinare le dipendenze.

3. un mucchio di altre cose a seconda del numero totale di proprietà nella funzione di controllo. Ho 270 proprietà nel mio nucleo. La maggior parte di loro sono comuni. Ma, ho una funzionalità avanzata che supporta un sacco di caratteristiche. Quindi, un tale numero di proprietà. Dobbiamo iniziare con le proprietà più semplici.

Sì, naturalmente con le proprietà più semplici. In quali oggetti primitivi potrebbe consistere la stessa Text Label? O in quali oggetti primitivi potrebbe consistere un semplice Pulsante?