
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
because it's a string & not an int look @ http://msdn.microsoft.com/en-us/library/aa364934(v=vs.85).aspx
but what i can't understand is y massing around for such a long time when u have a build in function in mql TerminalPath()
Is there some way to use kernel32.dll to enable my EA to algorithmically determine the current CPU load?
There are some things I'd rather my EA not do if the CPU utilization is currently above a threshold value.
I would think that trading is more important than game playing.
The only thing I could think of would be self-optimizing and for that I would have a batch file delay starting an optimization run while the count of terminals > count of cores.
It is for self-optimizing and I can't rely on simple count of terminal instances in the tasklist queue as not all instances are performing backtesting. My practical limitations are available CPU cycles, not idle threads.
That said, it would be nice to programmatically know the number of available processors as that would help define the threshold value of CPU utilization.
Is there any way to access "%NUMBER_OF_PROCESSORS%" from within an EA?
What I got so far is this:
but it returns the value of "1" instead of the correct value of "4". (as verified by requesting %NUMBER_OF_PROCESSORS% in a command prompt)Ah, got it...ignore what I put above, if anyone wants to programmatically extract the number of processors available in their system use the following:
Here is what I have to do in order to get the correct processor count reported, no idea why I have to make a call to GetEnvironmentVariableA in order to get ExpandEnvironmentStringsA to function.
This correctly outputs:
hrmmm...this is puzzling me now, the above calls do not work unless I make the prior call to GetEnvironmentVariableA.
Going back to your original...
The GetEnvironmentVariable() function puts the value of the variable into the buffer parameter, i.e. "buf". The function's return value is the length of the string. That's why result == 1, because the buf is the single-character string "4".
In other words, there's nothing wrong with your original simpler code except that GetEnvironmentVariable() has two outputs and you're looking at the wrong one.
However, you ought to make two further changes: (a) initialise buf with some dummy data such as "01234567890123456789", and (b) declare the third, "nSize" parameter for GetEnvironmentVariableA() as int rather than string. Otherwise, you are in effect allocating a one-byte memory buffer (the buf variable, consisting of a single null character), and reading a potentially variable amount of data into it with the possibility of overflow.
Failing to initialise buf is only working because you've declared nSize as string rather than int. Therefore, what's happening is that MQL is doing a silent cast of the StringLen integer result to a string, passing the address in memory of that string to GetEnvironmentVariable(), and GetEnvironmentVariable() is then interpreting that value as the size of the buffer - e.g. the string is at memory address 0x43128850 and GetEnvironmentVariable() then believes that the available buffer pointed to by buf is 0x43128850 bytes long.
It is for self-optimizing and I can't rely on simple count of terminal instances in the tasklist queue as not all instances are performing backtesting.
You know the number of terminals you have open. Don't exceed terminals+processors.
Actually I don't know the number of terminals, it is variable over time as it depends on the day to day number of clients/brokers/accounts/etc.
I am also deploying the code on a heterogeneous cluster which does not have a processor count that can be hard-coded into the code (nor would I want to anyway), the number of processors available on any given computer will vary, today as well as in the future.
I need the generalized solution, hence my efforts here are focused on developing such.
Going back to your original...
The GetEnvironmentVariable() function puts the value of the variable into the buffer parameter, i.e. "buf". The function's return value is the length of the string. That's why result == 1, because the buf is the single-character string "4".
In other words, there's nothing wrong with your original simpler code except that GetEnvironmentVariable() has two outputs and you're looking at the wrong one.
However, you ought to make two further changes: (a) initialise buf with some dummy data such as "01234567890123456789", and (b) declare the third, "nSize" parameter for GetEnvironmentVariableA() as int rather than string. Otherwise, you are in effect allocating a one-byte memory buffer (the buf variable, consisting of a single null character), and reading a potentially variable amount of data into it with the possibility of overflow.
Failing to initialise buf is only working because you've declared nSize as string rather than int. Therefore, what's happening is that MQL is doing a silent cast of the StringLen integer result to a string, passing the address in memory of that string to GetEnvironmentVariable(), and GetEnvironmentVariable() is then interpreting that value as the size of the buffer - e.g. the string is at memory address 0x43128850 and GetEnvironmentVariable() then believes that the available buffer pointed to by buf is 0x43128850 bytes long.
Ah yes, I see it now, thank you very much for investigating the code and pointing out the errors.
Now it is a simple matter of choosing my minimum threshold for available resources before spawning new auto-optimizer sessions by way of:
For sake of completion, and to help others who might find themselves walking in my footsteps at a future date, I am attaching the include file as well as a rudimentary EA that details the implementation of the call functions in the include file.
Naturally the mqh include file is to be placed in your include folder, the EA mq4 file goes in your experts folder.