[ARCHIVE]Any rookie question, so as not to clutter up the forum. Professionals, don't pass it by. Can't go anywhere without you - 5. - page 371

New comment
 
Fox_RM:

There is practically no difference, just a slightly different process of getting the A and B control points. I've already tried it with arrays.

Then between A and B I would also have to loop through the bars. I don't see another way, that's why I'm asking.

Maybe somebody can give me a hint. Maybe there is something wrong with the logic of code writing?


1. avoid saving lines in your code (in a staircase).

2. Instead of repeated short conditional statements use construct if(...) ... else...

3. Take the call of the graphical object forming function out of the inner loop (main brake).

 
Chiripaha:

this one:



... or better yet, one of these:

if (AOBuffer3[i]<=0){
   ExtMapBuffer1[i] =  nSum; Vol_Arr[i] =  Volume[i]*Point*coaf;
}
else{
   ExtMapBuffer1[i] = -nSum; Vol_Arr[i] = -Volume[i]*Point*coaf;
}
 
tara:

... or better yet, one of those:

Yes, I agree.

I collect all my suggestions in the "old" comment (if anything). - It may not be quite 'right', but it won't be scattered.

I think the problem is the accumulation of texts - Reflected in the main comment (don't know how to link to it - sorry).

 
tara:

3. Take the graphical object formation function call out of the internal loop (main brake).

Now, I wonder too - How do you do that? (implement)

Hm.... Exactly! - It's stackable. And intermediate values are not important.

      if (shift_up > shift_dn)
       {
        for (int dn_br = shift_dn; dn_br <= shift_up; dn_br++)            //-------------- Перебор значений внутри основного цикла
          {
           Vol_AO_up += Volume[dn_br]; 
          }   
         ObjectDelete ("Awesome_super_volumes"+up_koaf);        // Заодно и удалить старый текст, чтобы не копился
         SetText("Awesome_super_volumes"+up_koaf, DoubleToStr(Vol_AO_up,0), AO_time_dn, AO_dn, Blue);
       }

Then there won't be a whole bunch of them...

 

I have this call in my init function:

GetMarketInfo();

This function here:

//+-------------------------------------------------------------------------------------+
//| Сбор рыночных данных                                                                |
//+-------------------------------------------------------------------------------------+
void GetMarketInfo()
{
   gd_spread = MarketInfo(Symbol(),MODE_SPREAD) * Point;
   gd_stopLevel = MarketInfo(Symbol(),MODE_STOPLEVEL)  * Point;
   gd_tickSize = MarketInfo(Symbol(),MODE_TICKSIZE);
}

Variables gd_spread, gd_stopLevel, gd_tickSize I have declared globally until now. Now I've decided to write some libraries that use these variables. It turns out that I've moved these variables to the header file. So, to avoid errors at library compilation, I should transferGetMarketInfo() function to the library too, right?

 
hoz:

I have this call in my init function:

This function here:

Variables gd_spread, gd_stopLevel, gd_tickSize I have declared globally until now. Now I've decided to write some libraries that use these variables. It turns out that I've moved these variables to the header file. So, to avoid errors at library compilation, I should transferGetMarketInfo() function to the library too, right?

Definitely not to call this function in the init - spread and stoplevel may vary in time
 
artmedia70:
Certainly not in the init - spread and stop levelling can change over time


I think the inite should be discarded, to avoid problems in real trading. If connection is cut off by DC, and then appears, reinitialization will not happen and it causes errors and problems when working in real trade, right?

Well, what should we do then? Constantly call some function in each function that will return these market variables?

 
hoz:


I think the init should be abandoned, so that there will be no malfunctions in real trading. After all, if the connection is cut off by the DC, and then appears, reinitialization will not happen, and it already leads to errors and faults when working in real, right?

Well, what to do then? Constantly call some function in each function, which will return these market variables?

This kind of information should be divided into changeable and immutable.

The immutable data can be written anywhere, because even if there is a connection break, the data will still be relevant. - Better, of course, not in the start, so as not to burden the owl unnecessarily.

But the variable ones can be either through function call (if library is used) or just update them at the beginning of start function.

 

That's also true. The brain is always thinking about productivity, at a time when the mind doesn't quite know how to do it best. I've got a temper... a twin :(

Right, you have to separate one from the other at once.

Then again, though. If variables of market environmentgd_stopLevel,gd_tickSize are used in different functions (functions of modification, order sending etc.), then it is not quite reasonable to call function that get specified values constantly in library function. Is there some way to unify this? After all, unlike the spread, the stop loss and tick size will always be the same.

 
hoz:

That's also true. The brain is always thinking about performance, at a time when the mind doesn't quite know how to do it best. I've got a temper... a twin :(

Right, you have to separate one from the other at once.

Then again, though. If variables of market environmentgd_stopLevel,gd_tickSize are used in different functions (functions of modification, order sending etc.), then it is not quite reasonable to call function that gets specified values constantly in library function. Is there some way to unify this? After all, unlike the spread, the stop loss and tick size will always be the same.

Artem has already said that stoplevel can also float - it's not a constant value! - And the tick size is, yes, a constant.

To unify - again, divide it into 2 functions - MarketInfoConst and MarketInfoImage (variable). Place one in Inite, the other at the beginning of Start(s). And it will be possible to combine it into a library.

The question for productivity (owl optimization) is different. I personally don't cram all these functions into the owl. I just take parameters as I need them. Yes, I have to write more code, but owl handles less "superfluous" library stuff, because not everything from MarketInfo may turn out to be necessary in owl.
1...364365366367368369370371372373374375376377378...432
New comment