Errors, bugs, questions - page 1702

New comment
 
I see. Thank you.
 
Dmytro Zelenskyy:

OK, how to correctly convert double to int with the sign intact (number doesn't matter, if it goes outside the limit then limit it to int)

Convert to long.
 
fxsaber:
Reply and then close it immediately.

I needed to be able to remove myself (the indicator) in case there was even one copy running, albeit with different input parameters. To do this I needed to find out the handle of myself. Unfortunately, at that time I didn't know that it's impossible in MQL in 100% of cases. I therefore decided to try a not very smart trick.

I went through all the handles. If it coincides with the random I wrote in my indicator before checking, it automatically means the handle belongs to me and I can delete myself, if necessary.

It was from these considerations that such harmless code was written, which caused such an ambiguous, but obviously negative reaction from the developers. You see, you can't do that. What did you do? Well, I read the value of my buffer through the CopyBuffer. Is it illegal?!

There's nothing like "you can't do that" in the developers response. Nowhere does it say it is "illegal".

If you think you absolutely need this "harmless code" - use it. Just add IndicatorRelease(handle)) to OnCalculate() after reading the buffer. You don't need to check on each tick that it is "your" indicator, do you?

That's how the indicator solves your problem and stops being "invisible":

#property indicator_separate_window
#property indicator_buffers 1
#property indicator_plots   1

double Buffer[];

int handle=INVALID_HANDLE;
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnInit()
  {
   ::SetIndexBuffer(0,Buffer,INDICATOR_DATA);
   handle=ChartIndicatorGet(0,1,ChartIndicatorName(0,1,0));
  }

#define  TOSTRING(A) #A + " = " + (string)A + "\n"
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
   if(handle!=INVALID_HANDLE)
     {
      Buffer[rates_total-1]=MathRand();

      double BufferCopy[];

      if(CopyBuffer(handle,0,0,1,BufferCopy)>0)
         Print(TOSTRING(BufferCopy[0])+TOSTRING(Buffer[rates_total-1]));
         
      if(IndicatorRelease(handle)) 
         handle=INVALID_HANDLE;
     }

   return(rates_total);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnDeinit(const int Reason)
  {
   if(handle!=INVALID_HANDLE)
      IndicatorRelease(handle);
   return;
  }


Let the community be aware that it is possible to create in this way a background uncontrolled execution of any code even on the terminal without charts. Here is a little tiptoe. Whether or not to consider it a bug is probably a matter of terminology. My understanding is that the developers are not able to change anything architecturally here. That is why there is such anger. I cannot explain this reaction in any other way.

There is no "anger" in the servicedesk response. There is a misunderstanding of your motivation to regularly exaggerate the problems you encounter.

The developers are able to change things. But they are usually very careful about suggestions to "take away and forbid" even undocumented behavior if it is not unambiguously harmful. This "hack" is rather specific, but perhaps someone is using it.

Perhaps there will still be edits in the terminal about it, but it is certainly not a gigantic problem and the priority of this issue is minimal.

No one will speak out anyway. Such a rake would be well reflected in the Help.

It turns out that you are well aware that this "serious bug" of the terminal is of interest to you only.

Let's close the matter at this point. The technical details have all been discussed, while emotions are unnecessary in this thread.

 
Anton:

There is nothing like "it's not allowed" in the developers' response. Nowhere does it say that it is "illegal".

If you think that this "harmless code" is absolutely necessary for you - use it. Just add IndicatorRelease(handle)) to OnCalculate() after reading the buffer. You don't need to check at each tick that it is "your" indicator, do you?

No, of course, there is no such need.

This is how the indicator solves your problem and ceases to be "invisible":

On this topic I recently received a reply from your colleague

Forum on trading, automated trading systems and strategy testing

Errors, bugs, questions

Slawa, 2016.09.07 17:17

fxsaber:

IndicatorRelease after iCustom should be done?

What for?

Don't. Do not do after IndicatorCreate either

I have not got an answer.

Forum on trading, automated trading systems and trading strategy testing

Bugs, bugs, questions

fxsaber, 2016.09.07 17:27

After does not mean immediately. But if you don't have to, when should you?

There is no "anger" in the servicedesk response. There is a misunderstanding of your motivation to regularly exaggerate the problems you face.

The motivation is purely selfish. I want everything to work predictably, according to the documentation. Bugs are annoying, that's the result.

Developers are in a position to change. But they are usually very cautious about suggestions to "take away and ban" even undocumented behaviour, unless it is clearly harmful. This "hack" is rather specific, but perhaps someone is using it.

Perhaps there will still be edits to the terminal on this, but it's certainly not a gigantic problem and the priority of this issue is minimal.

I agree about the priority.

It turns out you are well aware that this "serious bug" of the terminal is interesting only for you.

Let's finish this question at this point. All technical details are discussed, but emotions are unnecessary in this thread.

No, they don't comment for another reason. No matter how serious the bug was. My "seriousness" was about the bugs that you can ALREADY make and put in the same Market. And then be confronted with the fact that the VPS doesn't have enough computing resources. Anyway, you get the idea.
 
Vladimir Pastushak:

I don't need it that way, I'm trying to do a lot of work to make my life easier in the future.

I solved my problem this way in the parent all proteced and inheritance goes under proteced then override.

If the parent is all protected, then there's no need to do protection-inheritance (you can leave public too). But now it's not clear what you wanted from the beginning. If you need to hide parent methods inside the class (and not outside as I thought), then what's the point of protection? You need a primitive here.
 
Alexey Navoykov:
Only now it's no longer clear what you wanted originally.
It looks like just getting rid of unavailable methods in the pop-up list.
 
Sergei Vladimirov:
Seems like just getting rid of unavailable methods in the pop-up list.
So the inaccessible ones don't appear, do they?
 
Sergei Vladimirov:
Looks like just get rid of the unavailable methods in the popup list.

Not only that, I rewrote the classes of graphical objects for myself and from one class in which all the properties of objects are described, I now easily and understandably (at least for me) make the Button-type descendants.

Further, from these simple elements I can build more complicated ones with minimum error probability, maximum speed and simplicity (at least, for me).

Perhaps you will give me a friendly kicking and say that the standard library has it all, but I'll tell you right now, it's not all and it's all incomprehensible. I'm used to working with what I understand completely, and to understand how it all works you need to try it all yourself...

 
Alexey Navoykov:
So the inaccessible ones don't appear, do they?

No, they do.

It's the same in the studio, by the way.

 
Sergei Vladimirov:

No, they do.

Then Metakvots should pay attention to this. Why show inaccessible methods. After all, everything is hidden for the protected section as it should be. So it should be the same here.
1...169516961697169816991700170117021703170417051706170717081709...3191
New comment