
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
Something we don't understand each other.
But don't get bogged down - you won't create a thread via CriAtTrade() inside µl, you need to pass a pointer to a function (where the thread will start), but as noted above - kukush.
Make your own DLL that creates the right number of threads by itself.
If you want to do complex calculations, then pure WinAPI calls are not enough.
Yes, we have made a lot of WinAPI call prototypes in-house, but that does not mean that all of them can be cleanly called from MQL.
no one has ported anything, what you see in the endunit are just function signatures
to create a thread, you need the body of the function - that's the body that will run in the thread!
To register a thread in Windows you need to fill in the structure:
seelpStartAddress - this is the entry point address of the function that will run in the thread, don't worry about memory allocation
to solve this problem, you need to find an opportunity to get the address of MyFunc() - in memory, and it is absent - well, nowhere at all ... none!
I don't know how else to explain the problem ... which is not the essence ))))
Here's a ported function in an inluder, with parameters, what's the difference?
And here is the ported function, getting the address of the function
In fact, you cannot call CreateThread fully from MQL because the physical addresses of the functions are not available.
You need to make your own DLL that will provide real handlers.
In fact, you cannot call CreateThread fully from MQL because the physical addresses of the functions are not available.
You need to make your own DLL that will provide real handlers.
Bummer. They portedCreateThread(); andGetProcAddress();
And you can't get physical addresses of functions, what's the trick? ))
Security is a good thing but, as you see, it restricts the use of the standard WinAPI.
Why were these functions ported and included into standard mql library?
Misleading the user, if you can not use them))
And you suggest to write your own asynchronous dll, which I wanted to get rid of, using the standard WinAPI
But i guess i'll have to go back to writing my own asynchronous dll.
p.s.
Here are the pitfalls of mql, for those who like to send all the time to Google, there is no this information by definition.
Bummer. They ported in theCreateThread(); andGetProcAddress();
And you cannot get the physical addresses of functions, what's the trick? ))
Security is a good thing but, as you see, it restricts the use of the standard WinAPI.
Why were these functions ported and included into standard mql library?
Misleading the user, if you can not use them))
And you suggest to write your own asynchronous dll, which I wanted to get rid of, using the standard WinAPI
But i guess i'll have to go back to writing my own asynchronous dll.
p.s.
Here are the pitfalls of mql, for those who like to send all the time to google, there is no this information by definition.
Don't confuse prototyping WinAPi functions and porting functionality.
We purposely did a great job of providing prototypes of standard WinAPI functions, so that developers don't have to reinvent the wheel. This is not a library, but descriptions.
Having raw WinAPI descriptions does not mean that we provide a guarantee/opportunity for insecure calls.
In an application language of this level, security is paramount.
How then from mql to normally initialize the dll to be loaded and the functions to be exported ?
Hmm... Then another problem arises.
How then from mql normally initialize the loadable dll, and exported functions ?
can you read? can you use search engine? there are more than 20 articles on writing DLLs on this resource, some articles are written first-hand - by admins (developers), read, do, everything is in free access, - there are no more detailed instructions on how to write a DLL without any knowledge of programming languages, but only on this resource! - even with pictures!
what are you trying to accomplish? - ban for flooding?
But I guess I'll have to go back to writing my asynchronous dll.
what prevents you from writing? do you need fanfare sounds? - anybody who is familiar with basic C++ or even simpler in C# - during a day is able to find this information, write and check in the code, here you only need "desire and ass assiduousness" - so one of admins wrote, imho, it's impossible to choose the expression more precise
SZS: I do not remember a case where an admin would have written so many responses to a user within an hour, something has changed, or the stars aligned so? )))))
can you read? can you use search engine? there are more than 20 articles on writing DLLs on this resource, some articles are written first-hand - by admins (developers), read, do, everything is in free access, - there are no more detailed instructions on how to write a DLL without any knowledge of programming languages, but only on this resource! - even with pictures!
what are you trying to accomplish? - ban for flooding?
SZS: I don't recall a case where an admin wrote so many replies to a user within an hour, is something changed? )))))
There is no description in these articles about initialization of dll and functions !!!
Show me where the initialization of the dll library andexportable functions is described, I would be only grateful.
No need to think that people do not read articles before referring to a forum!
what's stopping you from writing? do you need fanfare? - anyone who knows basic c++ or even simpler C# can google this information, write it and check in the code, all you need is "desire and a plodding ass" - so wrote one of the admins, imho, the expression couldn't be more precise
Nothing prevents! The task was to use pure WinAPI. Without any self-written dll!
The topic was created to discuss the problem of multithreaded programming in mql, you have some kind of negative attitude today, what kind of flooding in the topic created by me?
Please refrain from such comments.
Hm... Then another problem comes up.
How then from mql to normally initialize the dll to be loaded and functions to be exported ?
You don't need to pull these functions into mql. Create processes there in the dll.
You don't need to pull these functions into mql. Create processes there in dll.
Your dll, initialize it inDLL_PROCESS_ATTACH: will it be enough to call from mql program?
Thought it was possible to work with WinAPI functions without problems, and closed dll must be initialized additionally,LoadLibraryW("MyDll.dll");