Mon approche. Le noyau est le moteur. - page 7

Nouveau commentaire
 
La meilleure façon d'organiser les propriétés, les objets et les éléments est de créer un tableau.

Le cœur des éléments est la table.

Nous avons créé un modèle de proto-noyau, conçu pour stocker les paramètres initiaux de l'objet d'un élément particulier.

Ensuite, nous devons créer un noyau principal et y inscrire autant d'éléments que nécessaire.

Ensuite, nous allons définir de nouvelles valeurs pour chaque élément à l'intérieur du noyau principal.

Après cela, nous allons créer des éléments.

Ensuite, nous travaillerons avec eux lors de différents événements.


 

Déclarer le noyau principal :

int G_CORE[All_objects][All_properties];

Chaque rangée du noyau occupera un objet.

Nous devons déterminer combien d'objets au total se trouveront dans le noyau. Pour ce faire, nous devons calculer le nombre d'éléments que nous voulons créer et le nombre d'objets dans chaque élément.

Disons que nous avons 10 boutons. Donc : 10 éléments * 3 objets = 30 objets. Il y a donc 30 rangs.

#define  All_objects     30
#define  All_properties  10

Nous avons augmenté le nombre de propriétés dans le noyau principal, car en plus des paramètres de base, nous avons besoin des noms des éléments et des objets, des liens entre eux et de quelques autres propriétés.


Nous redéclarons les propriétés des objets:

#define  NAME        0
#define  TYPE        1
#define  ELEMENT     2

#define  X           3
#define  X_SIZE      4
#define  Y           5
#define  Y_SIZE      6
#define  BG_COLOR    7
#define  TEXT_COLOR  7
#define  TEXT        8
#define  CORNER      9
#define  STATE       10
//-------------------

La propriété TEXT contiendra une référence à un autre tableau qui contiendra les textes des boutons.

La propriété ELEMENT est nécessaire pour lier les objets d'un même élément au sein du noyau (afin d'éviter toute confusion quant à l'appartenance d'un objet à un élément). Dans cette propriété, nous allons définir le numéro de séquence de l'élément.

 
Реter Konow: //Voici à quoi ressembleraient les appels aux propriétés des éléments :

Il est très facile de confondre base, texte et icône. La description indique clairement ce que contient tel ou tel index. Dans la vraie programmation, il faut garder tout ça dans la tête. Je sais que Peter est un titan de la mémoire avec une capacité d'oubli fortement diminuée. Mais j'ai peur qu'il n'y ait pas beaucoup de tels titans. Je suis déjà en train d'oublier où et quoi mettre le lendemain.

Ne serait-il pas préférable d'avoir à peu près ce qui suit (je le ferais) :

Déclarer les structures élémentaires dont nous avons besoin.

struct SPosition
{
uint m_uiX;
uint m_uiY;
};

struct SElementSize
{
uint m_uiXSize;
uint m_uiYSize;
};

Maintenant nous pouvons obtenir les interfaces base, texte et icône à partir de l'objet commun :

CBaseI* pbBase = core.GetBase();
CTextI* ptText = core.GetText();
CIconI* pbIcon = core.GetIcon();

Et n'importe laquelle de ces trois interfaces - définit la propriété pertinente. Eh bien, par exemple, le texte :

ptText.SetPosition(SPosition& rpPos);

Nous remplissons la structure de position (X et Y), appelons l'interface texte à partir du noyau, et à partir de cette interface nous appelons la fonction de mise en position avec notre structure. Chacune de ces interfaces dispose également d'une fonction de réglage de la taille et de la couleur. Il est logique de les hériter d'une interface commune purement virtuelle, où toutes les fonctions sont mises à zéro.

Ici, il est beaucoup plus difficile de mélanger les choses. Parce qu'à tout moment, vous n'avez accès qu'à ce dont vous avez besoin pour faire votre travail. Et pour autre chose, vous devez l'appeler, et si vous n'êtes pas autorisé à le faire, alors avec une conception correcte du système, vous ne pouvez même pas appeler cette interface "interdite", vous protégeant ainsi des erreurs.

 

Et donc, changeons d'abord le nombre de propriétés du noyau prototype, elles étaient les mêmes que dans le noyau principal. Ensuite, nous allons faire un cycle de construction de G_CORE.

int P_CORE[3][10] = {
//Основание кнопки.-----------------------------
//
//NAME     TYPE   ELEMENT     X    Y     X_SIZE  Y_SIZE       COLOR 
//----------------------------------------------
{ 100001,  base,  button,    100, 100,    200,    50,    C'245,245,245'},
//---------------------------------------------- 
//Текст кнопки.---------------------------------
//
//NAME    TYPE   ELEMENT   X    Y     X_SIZE  Y_SIZE       COLOR 
//----------------------------------------------
{100002,  text,  button,  120, 120,     0,      0,       C'245,0,0'},
//---------------------------------------------- 
//Иконка кнопки.-------------------------------- 
//
//NAME    TYPE     ELEMENT   X    Y     X_SIZE  Y_SIZE       COLOR 
{100003,  icon,    button,  140, 140,     16,     16,           0},
//---------------------------------------------- 
};
//Далее, строим G_CORE:
//--------------------------------------
int q = 0;
//--------------
for(int a1 = 0; a1 < All_objects; a1++)
  {
   for(int a2 = 0; a2 < All_properties; a2++)
    {
     G_CORE[a1][a2] = P_CORE[q][a2];
    }
     q++;
     if(q == 3)q = 0;    
  }


Après ce cycle, le noyau G_CORE sera rempli de prototypes de 10 boutons. Ensuite, notre tâche consiste à donner des noms uniques aux éléments et à lier les objets à leurs éléments, en donnant à chaque élément un index unique.

 
Реter Konow:

Et donc, changeons d'abord le nombre de propriétés du noyau prototype, elles étaient les mêmes que dans le noyau principal. Ensuite, faisons une boucle pour construire G_CORE.

Vous pouvez le voir parfaitement à partir de ce code.

J'ai déjà oublié ce que signifie a1 et ce que signifie a2.

Mais c'est la moitié du problème - si j'ai oublié, je devrai regarder au-dessus. Mais je peux être sûr de ne pas avoir oublié, et je peux encore mélanger les éléments. Et puis c'est bon, si ça tourne tout de suite. Sinon, ce n'est pas un fait du tout, et l'erreur peut se produire beaucoup plus tard, et elle touchera, par la loi de la malchance, à l'endroit le plus vulnérable, et au moment le plus inopportun.

L'approche de Peter est celle d'un titan de la mémorisation, ce qui est aussi tout à fait normal. Mais combien de participants sont de tels titans ?

 

En attendant, même certains une petite entreprise a ouvert le code de son interface graphique boiteuse. :-)

ils sont vraiment en train de prendre le virage... ils ont peur de la concurrence ! !!

Des blagues, des blagues, mais toute personne intéressée peut voir comment l'interface graphique de Windows est construite de l'intérieur :

WPF est un cadre d'interface utilisateur .NET Core permettant de créer des applications de bureau Windows. https://github. com/dotnet/wpf

Windows Forms est un cadre d'interface utilisateur .NET Core permettant de créer des applications de bureau Windows : https://github.com/dotnet/winforms.

Versions rétrocompatibles des fonctionnalités de l'interface utilisateur Windows, y compris les contrôles UWP XAML, ainsi que les styles et matériaux fluides : https://github.com/Microsoft/microsoft-ui-xaml.


 
Maxim Kuznetsov:

En attendant, même certains Une petite entreprise a ouvert le code de son interface graphique de mauvais goût. :-

L'interface graphique n'est pas le problème ici. Mon approche peut être extrapolée et appliquée à n'importe quel objectif. Y compris l'IA.

Ensuite, je vais vous montrer comment faire.

 
George, laissez-moi continuer. Je sais que vous préférez le mode opératoire ouvert et que vous êtes plus à l'aise de cette façon. Mais, vos décisions sont calculées sur la base des références d'un programmeur. Je suis maintenant à la recherche d'une approche permettant d'atteindre un développement maximal. La commodité vient en second lieu.
 
Реter Konow:

Nous devons déterminer combien d'objets se trouveront dans le noyau. Pour ce faire, nous devons calculer le nombre d'éléments que nous voulons créer et le nombre d'objets dans chaque élément.

#define  All_objects     30
#define  All_properties  10

Question du public :

Supposons que nous créions un tableau des transactions de l'Expert Advisor de trading. Chaque ligne - une transaction avec le prix d'entrée, de sortie, le volume, etc. Comment connaître à l'avance, avant de compiler, le nombre de transactions que l'Expert Advisor effectuera pour déterminer correctement le nombre de lignes dans le tableau ?

 
Vasiliy Sokolov:

Question du public :

Supposons que nous créions un tableau des transactions d'un conseiller expert en trading. Chaque ligne correspond à une transaction avec le prix d'entrée, le prix de sortie, le volume, etc. Comment puis-je savoir à l'avance, avant la compilation, le nombre de transactions que l'Expert Advisor effectuera, afin de déterminer correctement le nombre de lignes dans le tableau ?

Ajoutez un numéro au tableau en utilisant ArrayResize sur chaque transaction, et enregistrez-y les propriétés de la transaction.

Dans le même temps, les propriétés seront réparties à l'avance entre les cellules.

Ensuite, toutes les données seront ordonnées.

1234567891011121314...184
Nouveau commentaire