Discussion on "How to write a DLL for MQL5 and exchange data in 10 minutes". - 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
Will it be possible to create simple dlls using mcl5 means? Simply speaking, write them in a unitor and compile them...?
And where to get the compiler and linker with all the Windows libraries and Platform SDK?
You can do much easier - download and install free Visual Studio 2008 Express and make the necessary DLLs in it.
And where to get the compiler and linker with all the Windows libraries and Platform SDK?
You can do something much simpler - download and install free Visual Studio 2008 Express and use it to make the necessary DLLs.
The question is not about being free...
The question is that I had to download and install a monster for the sake of a small one.
Anyway, thanks for your reply...
One more little question...
What needs to be downloaded from this page:
http://www.microsoft.com/express/Downloads/
it's
Visual C++ 2008 Express Edition
or all
All - Offline Install ISO image file
?
Visual C++ 2008 Express Edition
It's enough.
Thanks, I'm downloading it now.
But it's all in one file (800 mb).
I don't really trust the network installation...
We have methodically created 4 generations of trading languages since 2001 with a huge community of traders. Competitors were dying, their control languages were not developing, but we were working, working and will continue to work.
But where to get compiler and linker with all Windows libraries and Platform SDK?
You can do much easier - download and install the free Visual Studio 2008 Express and use it to create the necessary DLLs.
First of all we have to find out what "their" control languages are, delimit "their" functions and then find out what "their" development means. I don't mean competitors, I mean languages. As you can see, trading programs and systems live among variety of surrounding shells, even under winndas we have C++/.net/JScript/shell script/ and others, and it is correctly noted above that there is no point in trying to drag everything into a trading platform - the creation of some DLL, or providing timers, data exchange and so on should be based on existing and widely known means of the OS itself, freely available add-ons. modules (say, constantly developing .net framework with its runtime-versions) + the most powerful development and debugging tools - why bother with a bicycle or next generation Trading OS like Chrome OS everywhere?
IMHO the TC writing language development should serve the specific tasks of trade, i.e. information gathering, analysis, testing, trade management and integration with other systems - all this can and IMHO should be done at a high level of modern development tools, i.e. by integrating and extending the selected standard framework using generally accepted methods (OOP, etc.). The task is not to write a self-contained and self-sufficient platform on a mixture of C / C + + or whatever, but primarily the quality of writing a trading platform framework, its services, API and user interface. For the task of integrating the trading platform that we already have, even if it is the best one, is unavoidable. A simple example is AutoTrading. Probably it is clear that the Windows start-up with autologin and МТ terminal in Start folder of OS - is already a malicious anachronism, we need a normal Windows service for robots to work regardless of user (server?) logins. Fiddling with DLL's may not be necessary, base the platform on say .net. Write in C#, managed C++, Delphi, J++ and a bunch of other stuff. IMHO this was due to developers fear of making too extensible and flexible a platform that would be much harder to control than any under-subscribed sandbox.
How many times have I heard exactly those words - why reinvent the wheel, why not take java, Net, etc. as a base. And I myself started writing my first trading strategies exactly 11 years ago, when there was no idea about API to a trading account.
Take ready API of different brokers and make your own solutions, for God's sake.
Except that practice shows that only programmers demand raw APIs. And for one programmer ready to go "hand-to-hand" to write the system, there are 1000 traders who want to test their strategies on a ready and secure framework.
Newbies ask for API, sometimes they get it, and then a month of agony passes and they understand that the API for writing even the simplest trading strategy is not enough, and all they need is a ready-made market environment. It turns out that there is no market for the simplest programs without API, that buyers are not interested in being bound to one terminal, etc. And the desire to write more is invariably lost.
The normal development of an autoprogramming environment in trading platforms requires a secure framework with a rigid sandbox, otherwise no one will share scripts out of fear of Trojans. If they don't share, the community will die and so will the language.
The community is not 50, 100 or 500 programmers (who will happily wipe you down/wipe your feet), but tens and hundreds of thousands of traders who use systems with a minimum of complexity.
By the way, only MQL4.community receives more than 30 000 unique visitors every day, and we estimate that there are well over a million MetaTrader 4 users around the world.
In build 240 the wrappers have been simplified, the call rate is now 19,911,000 calls per second.
How many times have I heard these exact words - why reinvent the wheel, why not use java, Net etc. as a base. But I myself started writing my first trading strategies exactly 11 years ago, when there was practically no API to my trading account.
That's one way of putting it. And even after 11 years something had to change :)
Take ready API of different brokers and make your own solutions.
Sometimes people are tempted to do it. And why not try to improve the situation, especially if the position allows?
But the practice shows that only programmers are demanding the raw API. And for every programmer who is ready to "hand-to-hand" writing the system, there are 1000 traders who want to check their strategies on a ready and secure framework.
Raw is a relative concept. However, sometimes an API is better than nothing. Or worse, they are forced to use them due to the inherent limitations of the platform.
On the subject of "secure" frameworks, the debate is open, what we protect, from whom and how.
Newbies demand an API, sometimes they get one, then a month of agony passes and they realise that the API is not enough to write even the simplest trading strategy, and they need a ready-made market environment for everything else. It turns out that there is no market for the simplest programs without API, that buyers are not interested in being bound to one terminal, etc. And the desire to write more is invariably lost.
This is what we're talking about - not API, but extensible framework with specialized interfaces, tailored to specific tasks! Binding to the terminal does not interest anyone, but brokers "love" to bind themselves. Of course, you have to feel sorry for them.
A normal developing environment for autoprogramming in trading platforms requires a secure framework with a rigid sandbox, otherwise no one will share scripts for fear of Trojans. If they don't share, the community will die, and so will the language.
I beg to differ with you here, but I am open to changing my mind and changing my position. Name an example from the history of autoprogramming trading platforms where the (excessive) power of a particular available development environment outgrew the fear of users and doomed such an environment to destruction and extinction. Agree that allowing DLL calls in MT to be ticked off practically solves nothing in this regard, especially if there is a justifiable reason to resort to DLLs.
The community is not 50, 100 or 500 programmers (who will happily wipe/wipe your feet), but tens or hundreds of thousands of traders who use systems with a minimum of complexity.
That's when you need to make up your mind from the start, rather than trying to cram OOP for a guy who has a vague idea about programming. Speaking specifically about autotrading systems, give traders a minimum of complexity and it will grow into a maximum of complexity under the blanket of a graphical interface (and, eventually, a nightmare for the programmer of the system) - isn't it easier not to mislead anyone and allow for maximum flexibility in creating systems, rather than try to find a compromise of what is allowed to work for 95% of cases (read - "all except a few pluckers are very happy, this is how our company positions itself")?
By the way, MQL4.community receives over 30 000 unique visitors every day and we estimate that there are over a million MetaTrader 4 users worldwide.
What are you going to do with this statistics? Clearly, in terms of business, brokerage companies have 98% of poor traders who have bought nice looking Expert Advisor in trading terminal with no doubt nice looking terminal with all sorts of tricks...
Dear pisara,
Let us be clear - there is an argument between a theorist and a practitioner. Of course, no one forbids you to fight for "world peace", but take into account more factors than "why not improve?
Ради бога, берите готовые API разнообразных брокеров и делайте свои решения.
Иногда к этому склоняют. А почему бы не постараться улучшить ситуацию, тем более если позиция позволяет?
That's what I wrote - you won't use it, because you don't want to engage in routine work. You will have to get everything on a silver platter - all the indicators, all the market environment, all the history in different periods, etc. And there will have to be charting, because you won't manipulate all the indicators in your mind.
So, in fact, you need a full-fledged terminal. And we give it to you: MetaTrader 5 + MQL5 + DLL. Call it a framework or just give us the terminal in source code/components (because this is what you want).
Programmers mistakenly think it's "powerful" to be able to write scripts for trading systems in unprotected native languages, and then are surprised that no one is even going to use their creations. That's why they die before they are even born. Those who have developed and created a community of users think much deeper (because they got the knocks before) and do not make such mistakes.
Controlled (disabled by default) DLL call is acceptable, but downloading DLLs made by someone else into your trading terminal is a hole as big as an unpatched Internet Explorer 6.
For information, Google Trends statistics on trading terminals with automation: