Error #1 when modifying orders - page 6

New comment
 
tara:
How did you vote?
It was cool today (+15), so I went out with my clothes on. And I didn't poke anything as it didn't concern me.
 
Akella ...
 
tara:
Akella...

Don't get cocky! What do you want to say?

 
borilunad:

All checks are done before the loop, with conditions relating to each type and a call to this function, which only checks for errors in Modify():

Anything else, ask, but I'm off to dinner now. ;)

Boris, Thanks, of course for the help. But it turned out that my bug was buried in the wrong place. It was in another place. After order sending in the same method of sending order there was a modification, and then, on the same tick, modification by another condition. So, when the order was opened, there were errors on that tick. And there were no errors at other times.

If we go further, the function of checking for Stop Loss and Freefall + price correction there, if the conditions are not absolutely observed, is correct though, but the compiler curve does not want to handle it correctly for some reason. I print everything, it gets everything as it should, one level up everything is clear too. But it didn't get any results. I sawed that function into two parts, and now everything works.

Of course, I don't fucking like all this curvature, but I'll survive it for now...

 
hoz:

Boris, thank you, of course, for your help. But, in fact, it turned out that I had the wrong place to be buried. It was in another place. After sending order in the same method of sending order there was a modification, and then, on the same tick, modification by another condition. So, when the order was opened, there were errors on that tick. And there were no errors at other times.

If we go further, the function of checking for Stop Loss and Freefall + price correction there, if the conditions are not absolutely observed, is correct though, but the compiler curve does not want to handle it correctly for some reason. I print everything, it gets everything as it should, one level up everything is clear too. But it didn't get any results. I sawed that function into two parts, and now it's working.

Of course, I don't fucking like all this curvature, but I'll get over it for now...

You're welcome! I don't have everything in order either! Finally finished another EA. I have tried it all the day long and it finally binds properly only now. I will have some surprises on Real again. The main thing is persistence, patience and perseverance!
 
https://forum.mql4.com/ru/65622
 
azfaraon:
https://forum.mql4.com/ru/65622
I advise you to contact the professor himself! You want to change the logic of his system, and no one will do it better than him, and it is unlikely that you will find someone willing to mess with someone else's code, especially, most likely outdated, and for "security" by an untitled security guard!
 

Boris, the catch is that your function does not take into account a number of factors. For example, whether or not a tradewolf is allowed... etc. I have such strings in my modification function:

   while (IsTradeAllowed() == true)
      {
         if (!IsExpertEnabled() || IsStopped() || li_Cnt > 200)
         {
            CLogs.WriteLog (StringConcatenate ("Error: Trying to send order ", GetNameOP (fi_Type), " | Price: ", DToS (fd_Price), " NOT IsTradeContextBusy"));

            if (!IsExpertEnabled())
            {
               CLogs.WriteLog ("Permit ExpertEnabled !!!");
            }
            return (-1);
         }

This is for example. So my point is that brevity is not always convenient. After all, these checks are present in the real torrent anyway. So why not put them in the black box?

and don't think about them anymore? It's also easier that way...

It's simpler only if you have an adequate platform. In our case, it is not the best option. But it is possible to find a middle ground of sorts. Not very long codes, but not empty either.

 
hoz:

Boris, the catch is that your function does not take into account a number of factors. For example, whether or not a tradewolf is allowed... etc. I have such strings in my modification function:

This is for example. So my point is that brevity is not always convenient. After all, these checks are present in the real torrent anyway. So why not put them in the black box?

and don't think about them anymore? It's also easier that way...

It's simpler only if you have an adequate platform. In our case, it is not the best option. But it is possible to find a middle ground of sorts. Not very long codes, but not empty either.

Victor, I have a check for trade resolution before opening a position, and also check for sufficient Equity and many other things, but in the start, not in the functions! So why check at modification?
 
borilunad:
Victor, I have a check to allow trading before opening a position, as well as a check for sufficient Equity and many other things, but in the start, not in the function! So why check at modification?

Boris, it's simple.

Firstly, in this case you won't forget it in the future because this check will always be present.

Secondly, this check requires so little time that it will not give any optimization of the code and will not speed up the process. I.e. either check for "Allowed to trade" and enter the function, or enter and check for "Allowed to trade".

Third, I agree about the equity, it should be implemented separately. I had this piece sawed off. And a lot of things removed. Now the function is short in general.

1234567
New comment
Reason: