Creating a GUI for MQLs in graphical mode. - page 11
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
How is that still the case?
All the possibilities for interoperability have been around for a long time. DLL support in general was introduced in 2004.
Our languages are constantly evolving and becoming more powerful and functional. And the ecosystem is more powerful than anyone else's.
Well done! And I'm sure it's only going to get better! Absence of rigidity is the best characteristic of a team and success of developers! ))
Well done! And I'm sure it's only going to get better! Absence of rigidity is the best characteristic of a team and success of developers! ))
Our party is our helmsman ! Down with rigidity - swing with the party lines ! Come on !!!
Well done! And I'm sure it's only going to get better! Absence of rigidity is the best characteristic of a team and success of developers! ))
It will be, especially when we freeze 32 bit versions in September and will only support 64 bit platform versions.
Now we are preparing a serious upgrade of the compiler with the transfer of some system functions into MQL5 programs, which will dramatically improve the optimizer and accelerate the resulting code of MQL5 programs.
We will publish full performance benchmarks for comparison with C++, along with the source code, so that anyone can check them for themselves.
How is that still the case?
All the possibilities for interoperability have been around for a long time. DLL support in general was introduced in 2004.
Our languages are constantly evolving and becoming more powerful and functional. And the ecosystem is more powerful than anyone else's.
It's at a level, sorry, somewhere like Borland C++ in the late 80s. Give us a full-featured API with events, colbels, implementable as a COM object - the terminal would be priceless.
Why forgive? Stop raving, please.
We have a powerful application language that has shown by the ecosystem we have built that we are going in the right direction. Protecting users, developers and ourselves.
This is a business, not a platform for populists.
This is a level, sorry, somewhere like Borland C++ in late 80's. Give me a fully-functional API with events, coliboxes, implemented as a COM-object - and the terminal will be of no value.
Although rapidly becoming obsolete, it would be cool for terminal COM-interface.
Only it doesn't really fit in with the real time :-(.
Why forgive? Stop raving, please.
We have an application language that has shown by the built ecosystem that we are going in the right direction. Protecting users, developers and ourselves.
This is a business, not a platform for populists.
A COM interface for the terminal would be cool, though rapidly becoming obsolete.
But it doesn't really fit in with real time :-(.
We will, especially when we freeze 32-bit versions in September and will only support 64-bit versions of the platform.
Now we are preparing a serious upgrade of the compiler, moving some system functions into MQL5 programs, which will dramatically improve the optimizer and accelerate the resulting code of MQL5 programs.
We will publish full performance benchmarks for comparison with C++, along with the source code, so that anyone can check them for themselves.
Renat, before you disable x32, please make sure to run x64 under your hostname. If you don't want/need to, tell me too, so that we have time to think through the options.
And let's skip the feminine emotion and go with the numbers. How much load is the CPU putting into servicing this awful bottleneck? The CLR engine is constantly running in Windows anyway and we're not the only ones who use it. First and foremost, it is the wind itself that uses it.
The whole .net, # thing is a slow and clumsy machine, how can managed and native code compare?
"And the CLR machine is constantly running in the wind anyway, we're not the only ones using it. It's primarily the wind itself that uses it" - I sympathise. Looking at memory, here's my memory consumption by the system (linux):
MiB Mem : 2998.9 total, 2411.2 free, 38.9 used, 548.8 buff/cache
38.9 MB, unattainable for the Windows with its virtual machines, and that's while swap is not used:
MiB Swap: 8192.0 total, 8192.0 free, 0.0 used. 2474.6 avail Mem
And you can tell without emotions - in what way forms in C# are better than in C++/FLTK, for example there is a form editor - FLUID, though not necessary in my opinion, a simple window, a dozen or two dozen strings?