Crowdsourced GUI. Open beta testing. - page 48

New comment
 

Peter, you can treat me as you like, it's your right, but take advice from a slightly more experienced comrade.

#include <GUI_DRIVE.mqh>
#include "..\Files\CORES.mqh"
#include "..\Files\Internal_API.mqh"

TheGUI_DRIVE.mqh file is connected first in the code. Nothing is declared before it.

If you compile it you will get error of missing G_CORE, and it is logical because the array is not declared in this file!

Conclusion? Well, the conclusion is elementary: the array must be declared in this file. In the end, it is this file that operates with this array, because this file is the "engine"! Therefore, the declaration of the array itself in it is correct, according to the context of use.

The next file,CORES.mqh , fills the array with the description of form elements.

Of course, when compiling the EA itself with these files, if the array is declared in the first file, there will be no compilation problems, because when you compile the second file, the array will already be visible in the context of the program.

But what we are saying is that each file should compile without errors. Since the second file fills the G_CORE array with elements, we will quite naturally encounter an error when compiling this file, if the array is not declared.

And here we use, as Alexander said, a stub.

Pyotr, you're a big fan of defines, so you'll know what's going on.

In the file GUI_DRIVE you declare a global array of kernel elements G_CORE, after that the file should compile without errors.

Then in this file you add a define.

#define __DRIVE__

Move on to the Cores file. Before declaring an array, use the compile preprocessor.

#ifndef __DRIVE__
int G_CORE[][prop_limit];
#endif

And then you fill the array. Of course, you'll have to change the way you fill the array a bit, to do it without declaration.

I think you got the gist: If the CORES file is compiled, the__DRIVE__ default is gone and the array declaration code is compiled and everything just works out fine.

If the file is compiled as part of the EA, then after compiling the first file, the define is declared and in the second file the array is not declared because the compiler "cuts" this piece of code.

I really hope I've made myself clear.

I'll repeat it again: every file must compile without errors. If you have dependencies, you need to properly provide for their location and add recompilation processors as needed.

When you have every file compiled without errors, you have more confidence in the integrity of the whole system.

Also, don't forget to add a property in each file:

#property strict

This property gives a tighter check on the code.

 
This makes little practical sense. If each file compiled without errors, regardless of the integrity of the overall assembly, the user could easily miss the connection of one of the files. It's easy to forget.

Anyway, it's so insignificant that I'm not wasting my time on it. This is a complete nonsense. It is a nonsense.
 
Yes, you can make it so that each file is compiled separately without errors by manipulating the preprocessor.

But that is where the mistake lies. They are parts of a whole and should not "portray" independence from other parts. And indeed, the user may decide that not all the files are needed, because it works as it is.

Wasting time on such an activity that makes very dubious sense? Who am I trying to fool? The compiler?

The "experienced" comrades seem to be afraid of its stern voice and believe it is always right in everything. So they try to adapt, even if it doesn't make sense.

I had thousands of warnings in my markup language code because I had to put (sring) before constants. I can imagine what the code would be like if I put a type conversion before each number. But at least there would be no warnings.
 
Реter Konow:
Yes, by manipulating the preprocessor you can make each file compile separately without errors.

But that is where the mistake lies. They are parts of a whole and should not "portray" independence from other parts. And indeed, the user may decide that not all the files are needed, because it works as it is.

Wasting time on such an activity that makes very dubious sense? Who am I trying to fool? The compiler?

The "experienced" comrades seem to be afraid of its stern voice and believe it is always right in everything. So they try to adapt, even if it makes no sense.

I had thousands of warnings in my markup language code because I had to put (sring) before constants. I can imagine what the code would be like if I put a type conversion before each number. But at least there would be no warnings.

There are some comrades are writing a separate software that slightly changes the interface of the meta-editor itself - for ease of use only!

This standard is like using a keyboard - instead of typing letters in morse code through a squeaker. Stubs do not change anything except constantly flipping between files at compile time. But a stub is 2 lines of code. How much time we would spend on this browsing just to press one button. And how many times we will flip 7 and what will become more rational so as not to waste our lives typing letters through a squeaker

Note that we're not talking about objects or classes, we're just talking about saving time. Your time... And you can come up with a standard for writing them yourself.
 
Not to mention coding in Russian, which is discriminated by default by English-language development environment. Also to adapt and leave my brain a measly 30% performance, while I can use all 100% in Russian?

So much for the price of "professionalism".
 
Реter Konow:
Not to mention coding in Russian, which by default is discriminated by English-language development environment. Should I also adapt and leave my brain a measly 30% of performance, while I can use all the 100% in Russian?

So much for the price of "professionalism".

Professionals use their own data types in their code. In general, it does not matter what language they are in.

But if a function expects an integer in this order: Accept (width, height).

Instead we accidentally mix it up and write

Accept (height, width) - then the copyulator itself says that we have a mix-up here. Whether it works for you - it's not about the language or the objects either. It's just about not having to search for this error by yourself

 
Alexandr Andreev:

In professional code, individuals use their own data types. It doesn't really matter what language they are in.

But if a function expects an integer in this order: Accept (width, height).

Instead we accidentally mix it up and write

Accept (height, width) - then the copyulator itself says that we have a mix-up here. Whether it works for you - it's not about the language or the objects either. It's just about not having to search for this error by yourself.

This is a branch for testing ready-made solutions and communicating them to users.

I need constructive testers, not ambitious "professionals" looking for something to complain about.

I'm not going to discuss abstract issues. Did you connect the assembled panel, find bugs, report them? Thank you very much! Playing smart and picking on things you don't understand - goodbye.
 
Gentlemen clever people, you don't belong here.

For those who haven't run the editor and haven't connected the panel, but are "teaching", the conversation is short.

The rest of you, welcome!
 
Алексей Барбашин:

Peter, you can treat me any way you like, that's your right, but take the advice of a slightly more experienced comrade.

.......

Also don't forget to add a property in each file:

#property strict

This property gives a tighter check on the code.

it's for 5 - it's always the same there!

although in general I agree: a lot of warnings at compilation does not increase confidence in the code.

 
Igor Zakharov:

it's made for five - it's always strict!

although I agree in general: a lot of warnings at compile time does not increase confidence in the code.

I will remove the warnings. Temporarily.
1...414243444546474849505152535455...58
New comment