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
Uh, something was messed up in the latest build. .ex5 of one of the indicators has grown in size by almost 10 times compared to the .ex5 compiled by the previous build. Well, it is not a problem. But an error appeared when drawing the indicator (before entering its parameters):
I've already fixed 3\4 code. And if I again comment out a little bit, I'll get it (together with error above):
and it really doesn't workAnd if I again comment out a bit the code, the first two errors disappear, but I get them when unloading the indicator:
(Numbers may be different - depends on how much code I've commented out)I found out beforehand, that my function is too big by volume - I'll beat it on small functions.
...and everything was fine in the last build
Uh, something was messed up in the latest build. .ex5 of one of the indicators has grown in size by almost 10 times compared to the .ex5 compiled by the previous build. Well, it is not a problem. But an error appeared when drawing the indicator (before entering its parameters):
I've already fixed 3\4 code. And if I'll change it a little more, I'll get (together with error above):
We have tightened control over the sandbox environment for the sake of better security.
The message about the stack tells you that you have used more than 256 kilobytes of stack in one of your functions, which is a serious problem in programming. For instance, in C/C++ using a local stack function even for 16Kb is considered a serious warning.
You probably allocate a lot of static arrays in functions, for example:
You must not do that.
If you need large arrays, use dynamic arrays better. For example:
We have tightened control over the sandbox environment for the sake of increased security.
The message about the stack tells you that you have used more than 256 kilobytes in one function of the stack, which is a serious issue in programming. For instance, in C/C++ using a local stack by even 16 kb in a function is considered a serious warning.
You probably allocate a lot of static arrays in functions, for example:
You should not do that.
If you need large arrays, use dynamic arrays instead. For instance:
I don't use static arrays at all in this indicator; I don't pass anything heavier than int in functions, etc. But you actively use all sorts of graphical functions.
For example,
If the last line is commented out, everything is fine. The problem is that there are a lot of such calls and this one
is the 20th or 30th in a row.
I think the problem lies in the size of the function, since commenting the code avoids the problem, while most of the code consists of ObjectSetXXX. I've found out through experiments that breaking it into smaller parts is useless too - an aggressive inliner will still pile everything up and generate errors. I can try to put out more code, but I'll do it tomorrow. The service desk is also tomorrow, if we don't figure it out earlier.
I don't use static arrays at all in this indicator; I don't pass anything heavier than int into functions, etc. But all sorts of graphical functions are actively used.
But there is something huge, isn't there?
For example, include a local copy of a class which just has a ton of static arrays in its members. That's usually where the deposits of local stack consumers hide.
For example,
If the last line is commented out, everything is fine. The problem is that we have a lot of such calls and this one
is the 20th or 30th in a row.
I think the problem is in the size of the function, since commenting the code avoids the problem, and most of the code consists of ObjectSetXXX. I've found out through experiments that breaking it into smaller parts is useless too - an aggressive inliner will still pile everything up and generate errors. I can try to put out more code, but I'll do it tomorrow. Service Desk also tomorrow, if we don't figure it out before.
Divide up functions, stack into classes.
Inliner most likely has nothing to do with it - it doesn't insert too large pieces of code. Especially if they are heavy/lots of local variables.
But there is something huge, isn't there?
For example, include a local copy of a class which just has a ton of static arrays in its members. That's usually where the deposits of local stack consumers are hiding.
Divide up functions, stack into classes.
Inliner probably has nothing to do with it - it doesn't insert too big chunks of code. Especially if they have heavy/lots of local variables.
Why is it like this ? sloppy payout or what ! only 1 agent earned 1 kr and 0.3 kr was paid per day !
Be sure to write to servicedesk with these headers:
Terminal version and bit rate
...
Problem description
...
Sequence of actions ...
...
Result obtained ...
...
Expected result ...
...
Additional information ...
...
Or can you put it in your own words?
or can you put it all in your own words?
Do you have to write to servicedesk with these headings?
or can I do it in my own words?
you can do it all in your own words, but
Terminal version and bit rate
Problem description
Action sequence
Result obtained
Expected result
necessarily.
------------
You are not writing an essay on a free subject, you are writing a text for a developer who should quickly understand what you want from him without any details.
you can do all of your own, but
Terminal version and bit rate
Problem description
Action sequence
Result obtained
Expected result
necessarily.
------------
You are not writing an essay on a free subject, you are writing a text for a developer who should quickly understand what you want from him without any details.