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

New comment
 
OOP does not interfere with kernel implementation, on the contrary.
Usually there is code and data. The kernel, in our case, is the code, strongly separated from the data. The data can also be the code itself. The kernel usually has more complete functionality to handle specific data, or at least some self-sufficient minimum.
This approach allows you to use the most convenient data format, it is assumed that there will be a lot of data.
Here is another example where this approach can be applied: there are a lot of strategies in the Expert Advisor, the data represent only the logic of strategies, the core is the functionality to manage them, namely, order management, risk management, work with the trading environment, indicators, error handling, display of some or all statistics, trailing/grid/..... functions
 

Реter Konow:

You create an array and write the values of the properties of the button you want to create into it.

A button consists of three objects: Base, Text, Picture.

Each object exists inside a Button Element, hence the array must be two-dimensional.

So, why bother with all those arrays when you can (and should) use a structure for it. And we can address these values humanly - by field name, not by index (which may cause a lot of silly mistakes).

As a result, instead of a two-dimensional array there will be an array of structures. The declaration is the same concise, but simplicity and reliability is much higher, plus rational use of memory, because each field has its own type. And OOP has nothing to do with it at all.

Here's an example:

struct TObject { char type;  string name;  int x;  int y;  int width;  int height;  color clr; };

TObject Objects[]= { { OBJ_BITMAP, "Bitmap", 100, 100, 200, 200, clrRed },
                     { OBJ_BUTTON, "Button", 150, 150, 50, 10, clrWhite },
                   };
 
Alexey Navoykov:


The result is an array of structures instead of a two-dimensional array. The declaration is the same, but the convenience and reliability are much higher, plus rational use of memory, because each field has its own type. And OOP has nothing to do with it at all.


It's kind of ambiguous... which is better - an array of structures or a structure of arrays?

but MQL is designed to work with Forthran arrays, that's a fact...

 
Maxim Kuznetsov:

There's a bit of a quandary here... which is better - an array of structures or an array structure?

What kind of array structure are we talking about? The author just has arrays

 

I don't think Peter has ever seen how to create a DialogBox template in Visual C++, drag and drop any Controls into it, such as Button, CheckBox, EditBox, ComboBox, etc.

In other words, the elements you can see in Windows, including different options for displaying DB strings with field and string adjustments.

And with the use of MFC you can make quite complex dialog boxes in a few minutes and very briefly.

 
Alexey Navoykov:

And why all these perversions with an array, when you can (and should) use a structure for this purpose. It is initialized in exactly the same way - with values, separated by commas. And these values can be accessed humanly - by field name, not by index (which may lead to a lot of silly mistakes).

As a result, instead of a two-dimensional array there will be an array of structures. The declaration is the same concise, but simplicity and reliability is much higher, plus rational use of memory, because each field has its own type. And OOP has nothing to do with it at all.

Here is an example:

It's a nice solution. But this structure cannot be integrated into the kernel. If when building a kernel according to my technology, you just need to make a loop on the array with the prototype elements and rewrite them into the kernel, in the case of your solution, the loop is impossible.

Although it could be possible, but each element should be wrapped into a separate structure. And how to display it on the global scope? Where to declare it all... It's not clear.

Mine is simple. An array of element prototypes. All the properties of the objects are inside it. The array itself is global. Access is the simplest and from anywhere in the program.

 
Doesn't your gut resist using doubles? After all, it's also a composite object with its own methods. There is no place for them in orthodox kernel arrays! Look, because it is impressive (mantissa, exponent, sign):
_NEW_OBJECT, тра-та-та-та-та-та, 3, 10, 1, тра-та-та-та-та-та
 
pavlick_:
Doesn't your gut resist using doubles? After all, it's also a composite object with its own methods. There is no place for them in the orthodox kernel arrays! Look, it's impressive (mantissa, exponent, sign):

I don't get it.

 

I get rid of unnecessary syntax and tambourine, I simply initialize element properties in a global prototype array.

It's used only once - when element prototypes are rewritten into Kernel.

Rewriting is done in a simple loop.

As a result, at the build stage, the Kernel begins to contain prototypes of user-selected elements.

Next, new cycles on the Kernel begin. In them, I write the user-defined values of the elements' properties.

At the end, you get a finished Kernel, which contains the finished user windows with all the elements.

 

The process described above, I call the "kernel building process".

After the core is built, the "engine" begins to work.

The engine is the code that controls the mechanics of the elements.

The engine is only trained to work with the Kernel. Its engine is various events (mostly coming from OnChartEvent()).

1234567891011...184
New comment