Discussion of article "MQL as a Markup Tool for the Graphical Interface of MQL Programs. Part 1" - page 3
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
There will be no XML. The whole point is to do without MQL. The goal is to make an MVP-level markup system "native" to MQL - no frills, but functional and extensible enough for those who need it. It will be possible not to go into the internal structure. It's just that it's usually better to have a description of the concept and device than not to have one.
...
There are no users of graphical libraries, markup language or visual editor in fact (maybe there are, but you don't see them). There are people eager to learn. If articles don't have a markup language concept, they are meaningless. Write a concept. Good luck.
There are no users of graphical libraries, markup language or visual editor (maybe there are, but you don't see them). There are people trying to learn. If articles don't have a markup language concept, they are meaningless. Write a concept. Good luck.
Meaning. There's no language in the article, not even the concept itself?
Meaning? Not that there is no language in the article, not even the concept itself is absent?
The author didn't describe how the markup language works. Ask the question"how does the markup language work?" and find a detailed answer in the article. There isn't.
The author did not describe how the markup language works. Ask the question"how does the markup language work?" and find a detailed answer in the article. There isn't one.
Probably it will be in the next issue.
Probably will be in the next issue.
I thought it would be in the next one, too. We're not simpletons here. Everyone understands.
There will be no XML. The whole point is to do without MQL. The goal is to make an MVP-level markup system "native" to MQL - no frills, but functional and extensible enough for those who need it. It will be possible not to go into the internal structure. It's just that it's usually better to have a description of the concept and device than not to have one.
I'm not crazy about the standard library either, but there's not a lot of choice, so it's (for now) the best compromise between those few very small and super fancy libraries that I have big questions about anyway.
The supposed luminaries in programming and GUI creation who declared themselves as such on the basis of naive crafts are advised to demonstrate their hat-trickery in their own threads.
Who exactly are you referring to? Especially since it is in the plural, and there are not many of us here. If it were singular, I would have thought it was about Peter... but it's plural. It raises questions.
Why don't you just use your first name? So that no unnecessary questions arise. Or can't you just kick the air?
To the topic of the article. For the fifth time I re-read the whole thing carefully, neutrally and as objectively as possible. And here's the bottom line:
1. At the beginning of the article, the author clearly and lucidly discusses with the reader the issues of GUI relevance in programmes. Tells about the available graphical tools of MQL - MT-objects, libraries and even a view editor. Asserts that GUI is rather necessary than not. This is a clear and pleasant part of the article.
2. Acceleration begins. The author gives an example of standard library code and deservedly criticises it - it is long, inconvenient, inefficient when building a GUI. Sympathies are on his side.
3. Then, the author moves on to the discussion of GUIs in other languages, where he correctly notes that the description of layout is wisely separated from the programme code and represents an independent branch simplifying the routine layout of interfaces. He lists the advantages. This time, the author uses general phrases and references to literature, .Net platform, Android, XML.... He says that there, as well as here, everything is in "one flacon" and the hierarchy is visible, and also "single controllers" are defined. He doesn't clarify, he just goes on. For the unenlightened, the clarity ends and everything sinks into a fog. Where, what, why....
4- The author "flies" and the dialogue with the reader turns into a high-speed monologue. The clear sequence of presentation disappears: questions/themes/solutions/examples/codes - everything is mixed up. Of course it is not difficult for telepaths, but the rest of us have a hard time. It seems that the author is thinking up solutions for a new language on the fly and is going to finish everything by the end of the article. Like"don't interfere, I'll do it all!". In a frantic rhythm, scraps of thoughts, codes, names of variables and methods (maybe known to someone...) flash by. The jumps are more and more frequent and my head can't cope with the search for links between sentences. It becomes really hard to read.
5. The dialogue with the reader was lost after the first two chapters and further reading did not bring me clarity in anything. Although, I tried very hard. The question remained: " and what exactly does the author suggest?".
I closed the article and couldn't remember anything except the example with the spots and the first paragraphs. Everything else dissolved into a fog.
Hopefully, in the next issue, the author will continue the dialogue with the reader and keep the narrative structure until the end of the article.
Thanks.
Dmitry Fedoseyev, although offensive, very funny video insert. I laughed for a long time. When I read what you highlighted, I realised that it looked really stupid. It would be more accurate to say not rewritten, but improved and supplemented. I have read a lot of your articles for five years of your presence on this site, and I don't doubt that your knowledge is much more than mine, but I don't agree with you that there is no need for OOP in express-writing. Since in complex programmes, using graphical interfaces, combining several TS in one EA, keeping statistics, etc., OOP helps a lot, to structure the code of the programme better, and design patterns (although I am still at the very beginning of their study) increase the power of OOP many times. Of course, this does not mean that you should push it into a small EA, where you can do with ordinary procedures, and the speed of its writing will be many times greater. If it will be interesting I will describe an example where I applied OOP and one template, and how it simplified my life. And if it's not too difficult Dmitry, could you show your words"and even more so in creating an analogue of a delegate using OOP while there are pointers to functions" on an example. Or in which article you can find information about function pointers. Thanks in advance.
Everything is in the documentation, study it, use it.