Discussion of article "Graphics in DoEasy library (Part 83): Class of the abstract standard graphical object"
Good afternoon,
- Can you give examples of duplicates to answer more specifically?
- The structure and concept of building library objects is not quite in line with the concept of the standard library. But if you might have noticed, the library is built on the standard CObject and CArrayObj.
Anyway, I will be glad to answer questions, accept criticism and suggestions.
Thanks for your interest.
- Can you give examples of duplicates to be more specific?
- The structure and concept of building library objects doesn't quite clash with the concept of the standard library. But if you could notice, the library is built on the standard CObject and CArrayObj.
In any case, I will be glad to answer questions, accept criticism and suggestions.
Thanks for your interest.
1. If specifically I meant about the section from where the code begins"Further on the code of theclass write methods for simplified access to set and return properties of the object: ".
As I understand this is a description of functions in the base class, i.e. they are exhaustive for all objects and have access level public, if a successor is created it will see all these functions, but not every object has properties for control and text output for example, etc.... and to use this object it will always pull the base class, and not its own direct from CObject , of course it may make sense to get all the features of the base class, log output, etc. but then when creating inheritors it is necessary to virtualise and hide all functions that can not be applied to the class of the inheritor in the access level private.
Perhaps this is the trick of your implementation, if it is so then SUPER!))))))
By the way, perhaps the protected level for some functions will be more appropriate than public, but here you know better, of course, depending on what sense is put into it.
2. Yes, I've reviewed your code again, your concept of building a library is different, I agree, the main thing is that when you create upper levels of classes, create public functions virtual, so that other developers can use your solution without directly editing libraries.
3. I also noticed that you use string merge with +, in some versions of the terminal at large merges and with long terminal operation unpredictable situations in such implementation)))
I use StringFormat and StringAdd functions, the reliability of work has increased, and also visually the code becomes more readable.
4. I also wanted to warn about the limitation of the length of created objects when rendering, keep it in mind, it is better to generate a hash from the name and on its basis create an object, the limitation has a standard function, I do not remember exactly, but probably ResourceCreate....
1. If specifically I meant about the section where the code starts"Further on the code of theclass we will write methods for simplified access to set and return properties of the object: ".
As I understand this is a description of functions in the base class, ie they are exhaustive for all objects and have access level public, if a successor is created it will see all these functions, but not every object has properties for control and text output for example, etc.... and to use this object it will always pull the base class, and not its own direct from CObject , of course it may make sense to get all the features of the base class, log output, etc. but then when creating inheritors it is necessary to virtualise and hide all the functions that can not be applied to the class of the inheritor in the access level private.
Maybe this is the trick of your implementation, if it is so then SUPER!)))))))
By the way, perhaps the protected level for some functions will be more appropriate than public, but of course you know better depending on the meaning of it.
2. Yes, I've reviewed your code again, your concept of library construction is different, I agree, the main thing is that when you create upper levels of classes, create public functions virtual, so that other developers can use your solution without direct editing of libraries.
3. I also noticed that you use combining strings with +, in some versions of the terminal at large combinations and with long terminal operation unpredictable situations in such implementation were obtained))))
I use StringFormat and StringAdd functions, the reliability of work has increased, and also visually the code becomes more readable
4. I also wanted to warn about the limitation of the length of created objects when rendering, keep this in mind, it is better to generate a cache of the name and on its basis create an object, the limitation has a standard function, I do not remember exactly, but probably ResourceCreate....
1. The publicity of methods and their redundancy is the cost of wanting to make many different ways to access the same properties. But some methods will indeed be either virtual or prescribed only in inheritors. But again, this only applies to the objects of the library itself. When inheriting from them, alas, all public methods will be inherited.
2. I'll think about it. But actually the top level of access will be another entry point into libraries, and it will be user-defined functions, again, repeating already implemented features of the library, but will be more understandable to the average user - just use the function to get the result, and not to invent logic and handlers - all this will be done inside the library, and the output will be usercase-functions to simply get the necessary information.
3. I have not optimised anything (except for the logic thought out in advance) and have not profiled anything. This is for the very last moment.
4. Checked it my way. There long object name is possible. But thanks, I'll keep that in mind and keep an eye on it.
1. Making methods public and redundant is the cost of wanting to make many different ways to access the same properties. But some methods will indeed be either virtual, or prescribed only in inheritors. But again, this only applies to the objects of the library itself. When inheriting from them, alas, all public methods will be inherited.
2. I'll think about it. But actually, the top level of access will be another entry point into libraries, and it will be user-defined functions, again, repeating already implemented features of the library, but will be more understandable to the average user - just use the function to get the result, and not to invent logic and handlers - all this will be done inside the library, and the output will be usercase-functions to simply get the necessary information.
3. I have not optimised anything (except for the logic thought out in advance) and have not profiled anything. This is for the very last moment.
4. Checked it my way. There long object name is possible. But thanks, I'll keep it in mind and keep an eye on it.
4. This error may have been eliminated, but not sure...the function seems to work, but the object is not created, this is the behaviour when the length is large
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Graphics in DoEasy library (Part 83): Class of the abstract standard graphical object has been published:
In this article, I will create the class of the abstract graphical object. This object is to serve as a basis for creating the class of standard graphical objects. Graphical objects feature multiple properties. Therefore, I will need to do a lot of preparatory work before actually creating the abstract graphical object class. This work includes setting the properties in the library enumerations.
Re-compile and launch the EA.
Various graphical objects are added to the chart, while the journal displays messages about adding a new object together with its short description:
As we can see, everything works as expected.
Author: Artyom Trishkin