Errors, bugs, questions - page 1500

 
coderex:

Before working with a chart, it must be attached to an object of class using Attach method !!! If you don't want to work with the current chart ( 0 ) then implement this check and prohibit using the current chart in your work.

And what does it mean to work with the chart and not close it using the Detach method to exit? Is it really difficult to write one line in the destructor of your classes or in OnDeinit? You must strictly control the work with objects, and then you will avoid mistakes.

I can give you the same advice. Before you work with any chart, you must attach it to an object of your class using the Attach() method. If you want to work with the current chart, use the Attach( void ) method. If you obtained the chart's id earlier, use the Attach( chart ) method. If you want to work with new chart, use method Open(). Use this method only for opening a new chart and working with it.

If you want to work with the chart, without closing it, then you must forget to call the Detach() method. Together with the error of opening - the result is the closure of someone else's chart. Not good!

Here you are writing interestingly. You don't like something, make a check there, add it there and let's live as we used to. I can write my own library, I think, just like you. Why, when the work has been done for us? Let's improve what we have instead of inventing crutches. It's good that the developers were quick to hear me and make the necessary changes.

 

How would you not understand, you are asking the developers to kill the ability to work with the current schedule. If you don't want to control the process of creating, working and deleting objects properly, overload the Open method yourself, as the developers suggested.

In fact, when you create a class object, all its fields are initialized with zeros, it's not pure C++, where you're forced to zero everything after creation.

And you create a class object, work with it and just throw the object to be deleted, without detaching the chart from the class object. And the developers will change the Open method and begs the question, why overloaded Attach method was created in the first place?

Developers, please consider breaking your own ideology of working with the standard library before making these changes.

 
coderex:

How would you not understand, you are asking the developers to kill the ability to work with the current schedule. If you don't want to control the process of creating, working and deleting objects properly, overload the Open method yourself, as the developers suggested.

In fact, when you create a class object, all its fields are initialized with zeros, it's not pure C++, where you're forced to zero everything after creation.

And you create a class object, work with it and just throw the object to be deleted, without detaching the chart from the class object. And the developers will change the Open method and begs the question, why overloaded Attach method was created in the first place?

Developers, please consider breaking your own ideology of working with the standard library before making these changes.

Let's communicate by examples. Your unsubstantiated accusations are getting annoying. And what makes you think that your, in my opinion, fundamentally false approach is correct?

And you, having created a class object, worked with it, simply throw the object away, without detaching the chart from the object of the class. And the developers will now change the Open method, which begs the question, why the overloaded Attach method was created in the first place?

The Detach() method is a separate topic. What we are discussing now is that Open() can impose work with the current chart implicitly! For this there is the Attach() method. It is not clear who and what will be killed by adjusting Open() method...
 
Slawa:

How do you change GMT? "It's a monument!" (c) GMT is Greenwich Mean Time

Hahaha...

You are so witty.

 
Alexey Kozitsyn:

Let's communicate by example. Your unsubstantiated accusations are beginning to bore us. And what makes you think that your, in my opinion, fundamentally false approach is correct?

The Detach() method is a separate topic for discussion. What we are discussing now is that Open() can impose work with the current chart implicitly! For this there is the Attach() method. It is not clear who and what will be killed when adjusting Open() method...

Think what you want, but these lines of code in the proposed update of the Open:

   if(m_chart_id==0)
      m_chart_id=-1;

will changem_chart_id field containing chart ID to -1, if the chart is current i.e. ( 0 ), what kind of unfounded accusations can there be, and no one is accusing you, you're confused. If you don't want to write according to the ideology of the standard library, overload the methods that you believe don't work the way you want. I understand if the class was integrated into some common mechanism, like for example the control panels class family, where some methods can't be overloaded because of the fields they contain in private section of the class. But here the class is simple, you can change its behaviour yourself. But if the developers change the Open method as described above, then the Attach() method will not be clear, because it is the current ( 0 ) chart. In other words, the next call of Open will result inm_chart_id == -1.

In fact, it's not a problem for me, I just add a line to OnInit that gets the ID of the current chart and bind the chart to the object using Attach(long chart) method, but some of the developers who don't read this branch, may have some strange and "unexpected things".

 
Is there any way to copy the variables from the ex4 file?
 
Vasyl Nosal:
Is there any way to copy the variables from the ex4 file?
save the set file - I always do this
 
Vladislav Andruschenko:
save set file - I always do this

:))

You can't.

In mq4 files you can.

(indicator)

 
Vasyl Nosal:

:))

You can't.

In mq4 files you can.

(indicator)

Template? There is no data type there.

 
then only by templating