My approach. The core is the engine. - page 7

New comment
 
The best way to arrange properties, objects and elements is to create a table.

The core of the elements is the table.

We have created a proto-kernel model, designed to store the initial object parameters of a particular element.

Next, we have to create a main Kernel and write as many elements as we need into it.

Then, we will set new values to each element inside the main kernel.

After that we will create elements.

Then we will work with them at different events.


 

Declare the main core:

int G_CORE[All_objects][All_properties];

Each row of the Core will occupy one Object.

We have to determine how many total objects will be in the core. To do this, we have to calculate the number of Items we want to create and the number of Objects in each Item.

Let's say we have 10 buttons. So: 10 elements * 3 objects = 30 objects. So there are 30 rows.

#define  All_objects     30
#define  All_properties  10

We have increased the number of properties in the main core, because in addition to the basic parameters we need the names of elements and objects, links between them and some other properties.


We redeclare the properties of the objects:

#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
//-------------------

The TEXT property will contain a reference to another array that will contain button texts.

The ELEMENT property is needed to link objects of the same element within the core (to avoid confusion which object belongs to which element). In this property we will set the sequence number of the element.

 
Реter Konow: //This is what calls to element properties would look like:

It is very easy to confuse base, text, and icon. It is clear in the description what is inside this or that index. In real programming, you have to keep it all in your head. I know Peter is a titan of memory with a sharply impaired ability to forget. But I'm afraid there aren't many such titans. I'm already forgetting where and what to put in the next day.

Wouldn't it be better to have roughly the following (I would do so):

Declare the elementary structures we need.

struct SPosition
{
uint m_uiX;
uint m_uiY;
};

struct SElementSize
{
uint m_uiXSize;
uint m_uiYSize;
};

Now we can get the base, text and icon interfaces from the common object:

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

And any of these three interfaces - sets the appropriate property. Well, for example, text:

ptText.SetPosition(SPosition& rpPos);

We fill the position structure (X and Y), call the text interface from the core, and from this interface we call the position setting function with our structure. Each of these interfaces also has a function for setting size and colour. It makes sense to inherit them from a common purely virtual interface, where all functions are set to zero.

Here, it's much harder to mix things up. Because at any given moment, you only have access to what you need to do your job. And for something else, you still have to call it, and if you're not allowed to do that, you can't even call this "forbidden" interface, thereby protecting yourself from mistakes.

 

And so, let's first change the number of prototype kernel properties, they were the same as in the main kernel. Next let's do a cycle of building 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;    
  }


After this cycle G_CORE core will be filled with prototypes of 10 buttons. Next, our task is to give the Elements unique names and bind the Objects to their Elements, giving each Element a unique index.

 
Реter Konow:

And so, first let's change the number of prototype kernel properties, they were the same as in the main kernel. Then let's make a loop to build G_CORE.

You can see it perfectly from this code.

I've already forgotten what a1 stands for and what a2 stands for.

But it's half the trouble - if I have forgotten, I will have to look above. But I can be sure that I haven't forgotten, and I can still mix up the elements. And then it's good, if it turns out right away. Otherwise it is not a fact at all, and the error may occur much later, and it will affect, by the law of bad luck, in the most vulnerable place, and at the most inopportune moment.

Peter's approach is that of a titan of memorizing, which is also quite normal. But how many participants are such titans?

 

In the meantime, even some a small company opened up the code of their lame GUI :-)

they're really going around the bend...they're scared of the competition !!!

jokes, jokes, but anyone interested can see how the Windows GUI is built from the inside:

WPF is a .NET Core UI framework for building Windows desktop applications.: https://github.com/dotnet/wpf

Windows Forms is a .NET Core UI framework for building Windows desktop applications: https://github.com/dotnet/winforms

Backward-compatible versions of Windows UI features including UWP XAML controls, and Fluent styles and materials: https://github.com/Microsoft/microsoft-ui-xaml


 
Maxim Kuznetsov:

In the meantime, even some a small company has opened up the code of its cheesy GUI :-

The GUI is not the issue here. My approach can be extrapolated and applied to any purpose. Including AI.

Next, I'll show you how it can be done.

 
George, please let me continue. I know that you prefer OOP and you are more comfortable that way. But, your decisions are calculated on the basis of a programmer's credentials. I am now looking for an approach, through which one can achieve maximum development. Convenience comes second.
 
Реter Konow:

We have to determine how many objects will be in the core. To do this, we have to calculate the number of Items we want to create and the number of Objects in each Item.

#define  All_objects     30
#define  All_properties  10

Question from the audience:

Let's assume that we create a table of deals of the trading Expert Advisor. Each row - one transaction with the entry, exit price, volume, etc. How to know in advance, before we compile, the number of trades that the Expert Advisor will perform to correctly determine the number of rows in the table?

 
Vasiliy Sokolov:

Question from the audience:

Suppose we create a table of trades of a trading Expert Advisor. Each row is one trade with the entry, exit price, volume, etc. How can I know in advance, before the compilation, the number of deals the Expert Advisor will perform, in order to correctly determine the number of rows in the table?

Add a number to the array using ArrayResize on each transaction, and record the properties of the deal into it.

At the same time, the properties will be distributed in advance among the cells.

Afterwards, all the data will be ordered.

1234567891011121314...184
New comment