My approach. The core is the engine. - page 140
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
Yes. Exactly. All the information needed for the engine to reproduce a specific GUI and work with it. I'm now installing it directly into the engine, and then making it loadable from the file the builder prints.
How complicated and confusing this is.
Wouldn't it be easier for the user of your shaitan boilers to make it so that after the user builds the required forms, windows and elements, it just outputs an mqh file to connect to the program via #include? The file already contains OnChartEvent(), OnTimer(), OnTick() and other linking elements. The only thing remaining is to prescribe the necessary actions to it, which in any case, it will have to do, but you also need to learn your markup language. Otherwise you don't need any of it - just write in mql what you need in generated mqh-file and be happy.
You've gone down the road of creating a markup language and connecting it using a language the user doesn't understand for some reason. This solution will not attract mql language users to the product.
It seems, looking at the wonders in this thread - the most mental effort one tends to make is to remain a fool.
But it will overwrite all the user edits and bindings that are in the events ?
As soon as the GUI changes - the user presses a button and prints the new files. The engine loads the new kernels and the user application has to connect the updated pairing files.
In this case, one file just needs to be replaced (Conjunction Properties) and the other file needs to be reconnected. But, it is possible to copy already written code from previous file.
The main thing is not to fill in the connection files before one decides on the GUI. If new windows are added, this will hardly affect anything. If old windows and elements are changed, the code may have to be reworked in the program as well.
This is all in the constructor. The KIB code is written and the file is recompiled.
Here's how to work with the constructorhttps://www.mql5.com/ru/blogs/post/717782
Looked at... Silly childish mistakes with names of files and folders, you work in editor as if you're opening it for the first time...
And what I realized is that it's not a constructor at all. I thought you had a visual constructor...
And you call this concept a breakthrough? From where and to where?
How complicated and confusing this is.
Wouldn't it be easier for the user of your shaitan-boiler to make it so that after the user builds the required forms, windows and elements, it simply outputs an mqh-file to connect to the program via #include? The file already contains OnChartEvent(), OnTimer(), OnTick() and other linking elements. The only thing remaining is to prescribe the necessary actions to it, which in any case, it will have to do, but you also need to learn your markup language. Otherwise you don't need any of it, just write in mql what you need in generated mqh-file and be happy.
You've gone down the road of creating a markup and connectivity language using a language the user doesn't understand for some reason. This solution will not attract mql language users to the product.
By the way, yes.
I've got exactly the same way when recompiling. Of course, I've never made ready-to-use MQH-files, I just write simple text ones and then from them I transfer texts of initialization procedures to basic modules, but the idea is the same.
Peter, really - it would make your users' lives quite easy if instead of settings that you have to remember how to use - a ready-made MQH-file with ready-made settings would be generated !
And this is your concept you call a breakthrough? From where and to where?
This is a breakthrough - from people who want ready-made Expert Advisors with one button "chop dough" (or at least with two buttons, another one - "chop huge dough") - to people who will trade in semi-automatic mode, opening trades, accompanying them and closing with the help of Peter's visual components!
I am convinced that if such people appear - it will really be a breakthrough.
I just have doubts that it is possible. People are lazy by nature, and for hand trading (even semi-automatic) - you need a lot of experience, and where does the local beau monde get it from?
By the way, yes.
This is exactly the way I go when recompiling. I don't make ready MQH-files though, I write plain text ones and then from them I transfer the text of initialization procedures to the main modules, but the idea is the same.
Peter, really - it would make life easier for your users, if instead of settings, which you have to remember how to use - a ready-made MQH-file with ready-made settings would be generated !
Didn't understand what settings we're talking about. But I'll do what I can.
Explain in more detail.
No documentation, so links from memory (somewhere from the depths of the track) :-)
You generate a file with a function with many nested switches that dispatches messages from the interface elements to "pressed" "released". The user types in reactions to events there.
You changed-edited the interface, now what about this file?
How much work, for example, should a user have to do to divide the panel into two windows - one containing buttons and the other a table (so, for example, the user could close it and not loiter on the screen)?
And, for example, some columns should be swapped. It's just typical - make a layout, use it, change the appearance to a more convenient one
I don't know what settings we're talking about. But I'll do what I can.
The idea is that after all the forms, windows, visual elements are built, a ready-made MQL-file would be created, intended for direct compilation.
As I understand it now, users have to enter all sizes, coordinates, indents... This is a very tedious and tedious work. It would be nice if it was automated. The result would be an MQH-file that is ready to be recompiled.
I don't know what settings we're talking about. But I'll do what I can.
Learn OOP, and you would have long ago done, and not only what you could, but much more - a huge space for creativity, which you are not even aware of now. Quickly, efficiently and professionally.
But for years you've been mucking about with your constantly overblown engine.
And if you're proud of the amount of code you've written, you're an "Indian" in programming. This is not an insult - just search for this definition, it fits exactly what you do.
You can write code of a thousand lines and write code of a hundred lines, and both will do the same set of actions. But it's much harder to change or supplement bloated code than unbloated code. But you prefer to boast about the number of lines you've written (poking Nikolai in the nose with them), calling it all a huge project. Like a child, by golly.