Errors, bugs, questions - page 1543

 
comp:

For example, in the ObjectSetInteger description now

It should be

Read all of the articles to the end.

prop_id

[in] Identifier of the object property. The value can be one of the values of ENUM_OBJECT_PROPERTY_INTEGER enumeration.

I have already told you. Read documentation attentively without a saber in your hand.
 
Slawa:

Read the threads to the end

I've already told you. Read the documentation carefully, without a saber in your hand.

Read VERY carefully and to the end. Your quote is from there

Identifier of an object property. The value can beone of the values of theENUM_OBJECT_PROPERTY_INTEGERenumeration.

It should be

Object property identifier. Value MUST be one of values ofENUM_OBJECT_PROPERTY_INTEGERenumeration.

Requirement of an explicit ghost to this type is confirmed by the only variant compiled in five (check it yourself). Without this ghost the compiler complains about the absence of corresponding overloads.

 
I didn't know this trick. If you open an mq4 file in a five meta-editor, it will compile into ex4!
 
one compiler one editor
 

That is, when you finished reading it, you thought " The value may be one of the values of the enumerationENUM_OBJECT_PROPERTY_INTEGER. Or it may not be. And what may not be is not specified in the documentation, so anything that is not forbidden is allowed. Since we are extending the principles of social life to programming".

I wonder, what did MetaEditor tell you about the type of the corresponding parameter when it sets the parameters of this function?

 
There are a lot of ambiguities in the MQL help. So in that sense comp is right - the fewer possible interpretations of reading the help, the better.
 
Slawa:

That is, when you finish reading it, you think " The value may be one of the values of the enumerationENUM_OBJECT_PROPERTY_INTEGER. Or it may not be. And what may not be is not specified in the documentation, so anything that is not forbidden is allowed. Since we are extending the principles of social life to programming".

No, I didn't think so. I thought that if the code compiled correctly with MT4, it should compile correctly with MT5 as well. When it didn't, I started digging. Check the code on MT4 and on MT5 and make sure

class CHARTOBJECT
{
public:
  template <typename T>
  void SetProperty( const int id, const T Value, const int Modifier = 0 ) const
  {
    const string sType = typename(T);

    if (sType == "double")
      ::ObjectSetDouble(0, "", id, Modifier, (double)Value);
    else if (sType == "string")
      ::ObjectSetString(0, "", id, Modifier, (string)Value);
    else
      ::ObjectSetInteger(0, "", id, Modifier, (long)Value);

    return;
  } 
  
  virtual void operator =( const string Value ) const
  {
    this.SetProperty(OBJPROP_TEXT, Value);

    return;
  }
};

I wonder, what did MetaEditor tell you about the type of relevant parameter when it typed the parameters of this function?

It corrected it correctly using the specification I provided above. In the documentation it is int.

 
comp:

No, I didn't think so. I thought that if the code compiled without errors under MT4, it should also compile without errors under MT5. When it didn't, I started digging. Check the code on MT4 and on MT5 and make sure

Why?

MT4 and MT5 have inherently different architecture

When translating MQL4 from old syntax to new (what is called MQL4+) we had to look back to the old MQL4 syntax which had a lot of things missing including enumerations.

 

comp, let's volunteer to read only for a week. Be a reader, not a writer.

Everything you're talking about here has been discussed many times over, not only on this forum, but also on MQL4.com.

 
Slawa:

Why is that?

MT4 and MT5 have different architecture from the beginning

When migrating MQL4 from the old syntax to the new one (what is called MQL4+) we had to look back to the previous MQL4 syntax which had a lot of things missing, including enumerations.

One can argue for a long time without success. The fact is, if the documentation was not int, but as in the hint when typing the function name, I would have immediately found the cause of the compiler's scolding (it was not obvious in the example with the template). Because according to the documentation the code should have compiled as there int and "can". What prevents me from making the documentation and tooltips match - I don't know. But for the future I'll remember that in case of misunderstanding it's better to look at what the tooltips show instead of documentation.