What does MQL5 ObjectGetInteger(0, ObjectName(0, i, 0, -1), OBJPROP_TYPE) give us?

What does MQL5 ObjectGetInteger(0, ObjectName(0, i, 0, -1), OBJPROP_TYPE) give us?

Manage alerts

Loading saved threads...

jjo mmax · External communityPost link
External question — Stack Overflow Stack Exchange Author: jjo mmax Original post: https://stackoverflow.com/questions/79731789 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I think the type of an object with an index i must be found by the following code: ObjectGetInteger(0, ObjectName(0, i, 0, -1), OBJPROP_TYPE) But this does not give me the index. The above code gives a number, and this number is different from the order of ID#s in the table of ENUM_OBJECT . For example, it gives 12 for OBJ_FIBO , but 0 for OBJ_VLINE .
Quote
Report
user3666197 · External communityPost link
External answer — Stack Overflow Stack Exchange Author: user3666197 Original post: https://stackoverflow.com/a/79737134 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. From the two available ObjectGetInteger() -function's calling signatures, your code uses the value-returning one: long ObjectGetInteger( 0, // chart_id, = an MT5 chart identifier ObjectName( // name, = an MT5 chart object name string, // ( served by an ObjectName() 0, // chart_id, i, // pos, Obj's in-chart ordinal number 0, // sub_window {-1 = all | 0 = main | n } -1 // type {-1 = any | ENUM_OBJECT } ), // ) OBJPROP_TYPE, // prop_id, = ENUM_OBJECT_PROPERTY_INTEGER 0 // prop_modifier ( default = 0, Fibo-level or pitchfork ordinal ) ); So far so good. Your code serves a value for each i -indirectly addressed (most probably iterated) GUI-object. The rest is interpretation. ENUM-s, used as #def-ed symbols, are symbolic proxies for actual values (AMQP + ZeroMQ father, Pieter HINTJENS, calls them "HAUSNUMERO"-s, using them like : #define PUBLISHED_ENUM_CODE HAUSNUMERO+36791 which underlines the separation of actual value from symbolic definition, many times preventing (un)intentional collisions if some guessed value was used in function call, so as NOT to reference a given #def-ed property. A weak, but ultimately better than none, protection from run-time hard-to-debug crashes.) If in a need, create a trivial, yet robust, ENUM-decoder: switch( aReturnedObjPropEnumVALUE ) { case OBJ_VLINE: Print( "This one was an OBJ_VLINE" ); break; case OBJ_HLINE: Print( "This one was an OBJ_HLINE" ); break; case OBJ_TREND: Print( "This one was an OBJ_TREND" ); break; case OBJ_TRENDBYANGLE: ... case OBJ_CYCLES: ... case OBJ_ARROWED_LINE: ... case ... ... case OBJ_GANNGRID: ... case OBJ_RECTANGLE_LABEL: ... default: Print("This was a VALUE not seen in .h or #def-s during MT5 compilation") } If for nothing else but curiosity, one may drill another level deep and reverse-engineer the current (version-dependent, closed source code defined, sure) value of any ENUM-symbol: int aHASUNUMERO_deCODE_if_ULONG(ulong aGuessedToBeIntENUM_to_decode) { ulong aDumbForceINT = 0; while (aGuessedToBeIntENUM_to_decode != aDumbForceINT) { aDumbForceINT++ } return aDumbForceINT; } It is obvious similar approaches are weak and inefficient, as a mere case of a single string, used among other closed-source #def-ed ENUM-values, will turn all similarly naive efforts in wreck havoc.
Quote
Report

Post Reply

Checking account access…