What are the chances that a malicious user could steal the code or tamper with it in the repository?
Just the same as on GitHub, I reckon.
Why is it a concern that it might be stolen, when public projects are created precisely so that people don’t steal them, but simply use them?
Well, as for the private ones – I’ve already mentioned that above.
I’m not sure how to structure this project (code for the article) properly, as it consists of a pair of mqh files and several scripts.
When I try to compile one script, it complains about the presence of OnStart() in another script.
Perhaps it’s better to do it the old-fashioned way – attach the code to the article itself?
When I try to compile one script, I get an error saying that OnStart() is present in another script.
Perhaps it’s better to do it the old-fashioned way – attach the code to the article itself?
If there are several executable files in a single project, you need to create an empty project and place the required files in it. This is clearly stated in the article.
That’s exactly what I did.
It gives an error during compilation, saying that the OnStart() function is already defined in another script.
'OnStart' – function already defined and has a body days.mq5 18 6
see declaration of function 'OnStart' trend.mq5 18 6
Are there any examples of projects consisting of several scripts?
And that’s exactly what he did.
It throws an error during compilation, saying that the OnStart() function is already defined in another script.
Are there any examples of projects consisting of several scripts?
To be honest, I’d forgotten… My apologies.
For example, this repository.
For some reason, I couldn’t find this project in the editor (in the tab with the list of public projects). I struggled to find it on the Forge website, where I discovered it could be downloaded as an archive.
In my opinion, the option of attaching code to an article is still more convenient for readers. The only advantage might be if you need to re-upload incorrect code without editing the article.
I suppose for now it’s best to combine both methods of posting code.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Check out the new article: Code, Tears, and Algo Forge.
All work with Algo Forge is based on three simple rules that quickly become a habit. First, we lay the foundation in the Shared Projects folder, since this is where direct access to the cloud opens. Then we train ourselves in the "first step" rule: Before we start working on the code, we get the latest version from the repository using the "Get updates from Git" command—this is especially important if you use different computers. Finally, we commit our work: It's sufficient just to click "Commit changes to Git," and our edits are commited and reflected in the cloud.
The developers have simplified this process as much as possible by combining local commit and sending code to the cloud into a single action. By following this artless sequence, you'll forever protect yourself from version confusion, and your project will always be in perfect order and at hand.
Let's see how this looks in practice. The entire process of integrating your code into Algo Forge boils down to two simple paths: Either you give a new lease of life to your old code, or you start a new project right away, following all the rules.
Author: Artyom Trishkin