Someone please add a ".name" and a ".datetime" to MqlParam
What do you do about an indicator you're trying to set up that wants a datetime type value?
I have never used MqlParam. I just simply opened the documentation and saw this:
https://www.mql5.com/en/docs/constants/indicatorconstants/enum_datatype
Data Type Identifiers
...
| Identifier | Data type |
|---|---|
| TYPE_BOOL | bool |
| TYPE_CHAR | char |
| TYPE_UCHAR | uchar |
| TYPE_SHORT | short |
| TYPE_USHORT | ushort |
| TYPE_COLOR | color |
| TYPE_INT | int |
| TYPE_UINT | uint |
| TYPE_DATETIME | datetime |
| TYPE_LONG | long |
| TYPE_ULONG | ulong |
| TYPE_FLOAT | float |
| TYPE_DOUBLE | double |
| TYPE_STRING | string |
Have you tried using TYPE_DATETIME?
add a .name
What for? What's the usage scenario for .name? How is this supposed to work?
I have never used MqlParam. I just simply opened the documentation and saw this:
Have you tried using TYPE_DATETIME?
Look at the documentation below. Where would I put a datetime? In the long, or the double, or the string?
I suppose I could smuggle it in through the string and use StringToTime to convert it back, but then I'd have to break open the indicator I'm putting a call to.
Please read more carefully:
The Structure of Input Parameters of Indicators (MqlParam) The MqlParam structure has been specially designed to provide input parameters when creating the handle of a technical indicator using the IndicatorCreate() function. struct MqlParam { ENUM_DATATYPE type; // type of the input parameter, value of ENUM_DATATYPE long integer_value; // field to store an integer type double double_value; // field to store a double type string string_value; // field to store a string type }; All input parameters of an indicator are transmitted in the form of an array of the MqlParam type, the type field of each element of this array specifies the type of data transmitted by the element. The indicator values must be first placed in the appropriate fields for each element (in integer_value, in double_value or string_value) depending on what value of ENUM_DATATYPE enumeration is specified in the type field. If the IND_CUSTOM value is passed third as the indicator type to the IndicatorCreate() function, the first element of the array of input parameters must have the type field with the value of TYPE_STRING from the ENUM_DATATYPE enumeration, and the string_value field must contain the name of the custom indicator.
You see a place for a datetime there? You're limited to 3, just like it says:
"The indicator values must be first placed in the appropriate fields for each element (in integer_value, in double_value or string_value) depending on what value of ENUM_DATATYPE enumeration is specified in the type field."
They even had to kluge their own structure, putting the "name" of the indicator (which, given subfolders, could actually be a partial path/filename) in the string_value field of the first item. Why not just give us a .name?
You basically just proved my point -- plenty to be desired here.
Oh yeah! And what about indicators that use ENUMs in their input parameters? How do you get around that one?
Yeah, IndicatorCreate just died for me. Too restrictive. I'll have to stick with iCustom, my old friend...
Look at the documentation below. Where would I put a datetime? In the long, or the double, or the string?
I suppose I could smuggle it in through the string and use StringToTime to convert it back, but then I'd have to break open the indicator I'm putting a call to.
Please read more carefully:
You see a place for a datetime there? You're limited to 3, just like it says:
"The indicator values must be first placed in the appropriate fields for each element (in integer_value, in double_value or string_value) depending on what value of ENUM_DATATYPE enumeration is specified in the type field."
They even had to kluge their own structure, putting the "name" of the indicator (which, given subfolders, could actually be a partial path/filename) in the string_value field of the first item. Why not just give us a .name?
You basically just proved my point -- plenty to be desired here.
All data types (including enums) can be represented by long, double or string. Haven't you noticed that when getting properties using GetIntger, GetDouble and GetString functions? if you are working with integer values (any data type except float, double and string) use long, if float or double use the double, if string use string.
- www.mql5.com
Oh yeah! And what about indicators that use ENUMs in their input parameters? How do you get around that one?
I quote an example from the help (below). What I've highlighted is an example of passing an enum
https://www.mql5.com/en/docs/series/indicatorcreate
void OnStart() { MqlParam params[]; int h_MA,h_MACD; //--- create iMA("EURUSD",PERIOD_M15,8,0,MODE_EMA,PRICE_CLOSE); ArrayResize(params,4); //--- set ma_period params[0].type =TYPE_INT; params[0].integer_value=8; //--- set ma_shift params[1].type =TYPE_INT; params[1].integer_value=0; //--- set ma_method params[2].type =TYPE_INT; params[2].integer_value=MODE_EMA; //--- set applied_price params[3].type =TYPE_INT; params[3].integer_value=PRICE_CLOSE;
- MODE_EMA is one of the identifiers of the ENUM_MA_METHOD enumeration;
- PRICE_CLOSE is one of the identifiers of the ENUM_APPLIED_PRICE enumeration
All data types (including enums) can be represented by long, double or string. Haven't you noticed that when getting properties using GetIntger, GetDouble and GetString functions? if you are working with integer values (any data type except float, double and string) use long, if float or double use the double, if string use string.
Good thought! Hadn't thought about it like that. But then again, a kluge. So, when I'm asking for the user of an indicator to give me a datetime (with that nice little calendar widget) as they add it to their chart, what's going to happen if a coder iCustom's it and throws a type int at the type datetime? Wouldn't you get a runtime error? I'll have to try and see what happens. I like creative thinking, thanks!
I quote an example from the help (below). What I've highlighted is an example of passing an enum
- MODE_EMA is one of the identifiers of the ENUM_MA_METHOD enumeration;
- PRICE_CLOSE is one of the identifiers of the ENUM_APPLIED_PRICE enumeration
Sure enough, thanks man. I'm going to try that out along with stuffing (int)type_datetime-value into a declared type_datetime and see what happens.
what's going to happen if a coder iCustom's it and throws a type int at the type datetime
long, not int. Because the size of datetime is 8 bytes, and the size of int is 4 bytes. That is, not every datetime value will "fit" into the int type.
void OnStart() { datetime dt = TimeCurrent(); long _long = dt; PrintFormat("datetime = %s, long = %s", TimeToString(dt), TimeToString(_long)); }
2024.04.15 15:00:58.697 scriptTest (EURUSD,H1) datetime = 2024.04.16 01:00, long = 2024.04.16 01:00
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
It's got type and values, why not let us say that the internal name of the variable is? It would really help in check if we got things out of order, and besides, it's just polite, don't you think?
But the real rub here is: What do you do about an indicator you're trying to set up that wants a datetime type value?
I guess MqlParam and IndicatorCreate are kinda screwed, in that case.
This request isn't just reasonable, it's surprising that it needs to be requested.
"But where would it stop, then? Every single data type stuffed into MqlParam?"
Well, it's already stopped short, right? I wouldn't mind a long and a ushort in there, and maybe a couple of other ones. But at least add a .name and a .datetime for heaven's sake!