In MQL5 there is always room for an exploit ! ;) - page 9
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
Alexey, you should also tell me how to wrap arrays, issued by OnCalculate() function, into a class - in this case you can't do without copying pointers.
At the moment, I'm just copying data into my class-array, and then I'm pulling a pointer to this object. But that would get some extra copying, which, as I see, adds quite a noticeable "heaviness" with frequent ticks and large number of charts. I want to get rid of this copying. But, except for a crutch via DLL (standard or self-written), there is nothing I can suggest.
In Service Desk, they keep pushing me back saying "the object may be deleted". It's their own arrays! When I say that I may create an object and then remove it and the pointer will become invalid - they reply that "it is I who will be responsible for this". This is "double morality" at work.
And to hell with this DLL - but such indicators require constant confirmation at startup - which is very disturbing...
About the confirmation option. It has to be done once in the terminal netting, doesn't it? Where is the "permanent confirmation" here?
If one is an iron, I have an antidote... an indicator that goes into the mt settings and checks the box... True, this tool should also be imported first ))))
About the "object" and the Service Desk. The object in MT is a subjective notion. For MQL programmer the object is something that is caught by the herbage collector when there is a leak.
Something that is created by a legitimate MQL allocator.
From a WinAPI or process bell, this allocator itself and any "static" execution area of an indicator/expert and the hedgehog with it, is also an object.
An object that is somewhere in the MT hip along with windows, threads and the "close" button.
Hence the ambiguous morality, hence a number of MQL restrictions that don't allow working by real pointers, memory addresses, hooks, grafting all sorts of win-calbacks.
My opinion, the guys allowed dll import for nothing. It is probably the biggest pain in the neck now. On the one hand MQL programmers are asking for more power, but on the other hand the terminal itself must remain a monolithic product. Not a waffle at the mercy of various mods and patches from people's scribes.
I don't consider it a sin to import a dll that is already being pulled by the terminal as it is.
About the confirmation option. It has to be done once in the terminal setups, doesn't it? Where is the "permanent confirmation" here?
If one is an iron, I have an antidote... an indicator that goes into the mt settings and checks the box... True, this tool should also be imported first ))))
About the "object" and the Service Desk. The object in MT is a subjective notion. For MQL programmer the object is something that is caught by the herbage collector when there is a leak.
Something that is created by a legitimate MQL allocator.
From a WinAPI or process bell, this allocator itself and any "static" execution area of an indicator/expert and the hedgehog with it, is also an object.
An object that is somewhere in the MT hip along with windows, threads and the "close" button.
Hence the ambiguous morality, hence a number of MQL restrictions that don't allow working by real pointers, memory addresses, hooks, grafting all sorts of win-calbacks.
My opinion, the guys allowed dll import for nothing. It is probably the biggest pain in the neck now. On the one hand MQL programmers are asking for more power, but on the other hand the terminal itself must remain a monolithic product. Not a waffle at the mercy of various mods and patches from people's scribes.