Slawa or any C++ programmer has an idea of receiving WM_COPYDATA by the platform?
Another option: Let the sending application open a (hidden) window with a text-box that contains the values; then from within the EA you call windows API functions, GetTextA(hwnd) (or something like that), and you have your needed contents.
So only program a dll, then call functions(send and receive data through parameters ) of dll in MQL programm.
peroid can be control but check time[0] in MQL program.
So only program a dll, then call functions(send and receive data through parameters ) of dll in MQL programm.
All in all the childwindow-idea seems to be working....
only maybe arrived so if you are a very excellent programmer like a very excellent hacker.
WM_COPYDATA message is designed for two cooperateing windows, but now you only can control one window! another is MT you can not control(programm).
yes, a separate function could get control from the platform while checking for WM_COPYDATA message ,
it only know the content of WM_COPYDATA in Hex mode, can not process the content.
but not control , only know have message, not know how to process message, since Message transfer is control by system and system supplied API to watch Message pool, and so you only can simulate keydow, mouseclick..... message to MT platform, but not WM_COPYDATA, since MT not processes such messages and MT not supplied such interface.
childwindow-idea , yes, but for a software you do not have source code, you can not program the child of MT's window.
only maybe arrived so if you are a very excellent programmer like a very excellent hacker.
WM_COPYDATA message is designed for two cooperateing windows, but now you only can control one window! another is MT you can not control(programm).
yes, a separate function could get control from the platform while checking for WM_COPYDATA message ,
it only know the content of WM_COPYDATA in Hex mode, can not process the content.
but not control , only know have message, not know how to process message, since Message transfer is control by system and system supplied API to watch Message pool, and so you only can simulate keydow, mouseclick..... message to MT platform, but not WM_COPYDATA, since MT not processes such messages and MT not supplied such interface.
you can create one window to send out WM_COPYDATA message, but you can not create MT Windows to receive and processes WM_COPYDATA message.
why you need WM_COPYDATA mode?
if you sure you need, you can write a dll (inside, to creat a window to receive WM_COPYDATA and record the content, and you any other program send WM_COPYDATA to this window). and then inside your MQL indocator or EA, call the function of the dll, to get record.
more quick method is creat a share dll with share memory, your any other program call function of dll to send recoed, your MQL indocator or EA call the function of the dll to get record
why you need WM_COPYDATA mode?
I just needed the easiest InterProcessCommunication (as I had no experience in this field, I only learnt C++, but haven't worked with it in Windows), and this seemed to be the easiest compared to eg. shared memory.
I found the golden middle though: creating a NamedPipe, this way the two programs (where the client side can be integrated in a dll for MT4) communicate based on the shared memory concept of pipes, and not two windows by messages.
-file communication. I don't like this one, it is slow, and sometimes file transfers are even slower on shared servers. (I started with this one, as this is the easiest, but it errs many times, so it is not a solution)
-winapi's WM_COPYDATA through SendMessage(). This seems to be simple, and it is just made for the same thing I would need. Simple interprocess communication. Now, where I am stuck is the receiving side of the terminal. I have no idea how I could integrate the checking for WM_COPYDATA message into an imported dll. (I only know how to integrate such condition into default source messagemap) I don't even know if it is possible at all (I am rather unexperienced in this field), so any help or even ideas would be highly appreciated.
-the last one would be communication via Clipboard: I haven't ever tried clipboard communication, I have no idea about possible interferences that may or may not happen.
If anyone having experience could help me out with this question would be greater than great... :)
As I've searched the forums I saw that it may be of interest from other people as well..
Thanks in advance: Zap