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

 
Vasiliy Sokolov:

Will there be an answer to the second question? I will repeat it again:

This is what it means in my understanding to "set button properties":

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

It has to be done in advance.

If it's about initialising properties in the kernel, it can be done whenever.

 
Реter Konow:

Once you have established the number of object properties, you can no longer change it. If you change it, you will be out of the array.

You have to know all properties of your objects beforehand. Give them indices. And all of them must fit in the row of the Kernel.

But, the Kernel can be dynamic, and you can change the number of Items and Objects in it. For this, use ArrayResize.

And what happens if in the process of development it suddenly turns out that you need to expand the number of properties of your "object". Will you have to rewrite the whole code?

 
Vitalii Ananev:

What happens if you suddenly realise during development that you need to extend the number of properties of your "object". Will you have to rewrite all the code?

No. Not all of it. My number of Object properties kept increasing during development. It started with 20-30, and now it's 236. I can add new properties, changing only the size of the Core dimension, and put them into the code. There is no need to change anything.

 
Реter Konow:

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},
//---------------------------------------------- 
};

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.

Okay, I don't get it. Why do you have the button name as a number? What does the number 1000003 mean? And how do you set the button name as text?

 
236 properties for each object. About 50 different elements. And here they prove to me that the approach is difficult. If it were difficult, would I pull it off?
 
Реter Konow:

No. Not all of it. In my development process, the number of Object properties kept increasing. It started with 20-30, and now it's 236. I can add new properties, changing only the size of the Core dimension, and fit them into the code. There is no need to change anything.

I see. But you are contradicting yourself.

Once you have set the number of an object's properties you cannot change it anymore. If you change it, it will go beyond the array's limits.

What do you mean by that?

 
Vasiliy Sokolov:

OK, I don't get it. Why do you have the name of the button as a number? What does the number 1000003 mean? And how do you set the name of the button as text?

When you have a lot of graphical objects, it doesn't make sense to give them string meaningful names. So, numbers. Besides, it's easier to name them this way in the loop.

 
Vitalii Ananev:

I see. But you are contradicting yourself.

How is this to be understood?

It means that the size of the kernel should correspond to the number of object properties. If you change the number of properties and do not change the size of the kernel, you are out of the array.

 
Реter Konow:

There will be no new horizons with lists. My concept requires no additions. It is complete and self-sufficient.

Its advantage is that it does not contain unnecessary entities and tools created by OOP.

It's understandable, you don't know anything about them yet :( All the discoveries are ahead...

I'm amazed how the branch is getting more and more interested...

And how did the philosophically trained topic-starter stoop to a trivial array? They might say: simplicity is power, but we're already flying into space :)

I don't get it :( Reality awwww....

 
Реter Konow:

When there are many graphical objects, it is meaningless to give them string meaningful names. Therefore, numbers. Besides, it's easier to name them in a loop.

Okay, let's assume that under the name you have a number (wild of course, but let's assume). But each button has a caption, a text, for example "Cancel" or something like that. How do you specify this property? Like this:

int P_CORE[3][10] = {
//Основание кнопки.-----------------------------
//
//NAME     TYPE   ELEMENT     X    Y     X_SIZE  Y_SIZE       COLOR  TEXT
//----------------------------------------------
{ 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},