how to include a file.txt in an mq4 file ??
1 put it in \experts\include
2 rename it to var.mqh
3 use it in your mq4 file with:
#include <var.mqh>
Great thanks DxdCn
I put the file in experts\include and rename it
But when I try to compl the file, I've got another error for the first line
"iHigh initialization expected"
I try to do this :
int high_d1 = iHigh(NULL, PERIOD_D1, Current + 0);
or
string high_d1 = iHigh(NULL, PERIOD_D1, Current + 0);
or
double high_d1 = iHigh(NULL, PERIOD_D1, Shift + 0);
But no one is working
Help please!
This are another questions !!!
In fact, I do not understand what you need, in your file, only have somethings like variables, not function, you know, include... most used for some functions used frequently.
your high_d1 ... not function, and Current is not defined also !!
all these can be used in file directorily, why use include ???
if you want use, change them to function mode, name parameters... something.....
since you know include, so I think you have c language kowledge.
Exact
I wanted to use var.mqh in all mq4 files.
In facts I have a lot of variables (ihigh, ilow, iopen, iclose, iStochastic, isar etc...) and when I want to change or add one of it
( for example : double high_m15 = iHigh(NULL, PERIOD_M15, Shift + 0);)
, I have to do it in all my files.
That why I thinked I could use the include fonction.
If it's not possible, I'll still use my old methode.
Great think !
just some ramblings chucked into the cooking pot... ;)
include files are great way to remove requirement for constants planted inline and used in many files - can easily become a nightmare.
#define is a lifeline for above.
wherever possible one can even do pseudo OOPs like variable 'hiding'. eg, many grouped functions living in a .mqh file may all like to have access to a few variables and these variables do not need to be known about outside that one .mqh file, yes?
Anyway, globals are considered by many to be vip dangerous simply because R/W access is program wide and the "who,what,when and where" game can happen - again and again and....!
Making simple single functionality functions that help/remove need for globals... after all, that's what function parameters are for yes?
if functions kept simple and single function the includes are great for grouping into .mqh's eg, includes for files, logs, trace, CT global handling, trade environment informational types and of course defines and EA global/extern variables.
you can build an EA with a top level .mq4 source file with just #include's in it. Then, even start(),init(),deinit() can be in own .mqh file.
since start() is where a lot of specific strategy coding is often done, by having in own file and the 'generics' in other files - is very easy to build many EAs simply and reliably. The bulk of 'generic supporting code' hardly ever needs touching, yes? eg, once you have an errorHandler() just when is it required to touch? Same idea can be used for tradeOps, fileOps, logs, traces (which you turn on/off via extern and have embedded trace function calls in your developing code etc...)
going step further, could even have a tradeDecision() and stopLoss() and exitDecision(),.... that way with a bit of work can probably make start() generic too.
Speed considerations will become even less an issue when MQL5 comes along - 'real compiled/chip native' code I believe and some if(bTrace){...} will not impact on EA speed - just simple compare with jump around if not true...
all of above is how I'm going along the trail. takes more time, more testing, more designing etc. for me, end result is easy EA strategy testing and trading setup and ultimately very easy to modify trading code and not have to concern self with all that generic gunk which can just, in the end, obscure the guts of the beast...
of course: all fwiw and imho
:o))
just some ramblings chucked into the cooking pot... ;)
include files are great way to remove requirement for constants planted inline and used in many files - can easily become a nightmare.
#define is a lifeline for above.
wherever possible one can even do pseudo OOPs like variable 'hiding'. eg, many grouped functions living in a .mqh file may all like to have access to a few variables and these variables do not need to be known about outside that one .mqh file, yes?
Anyway, globals are considered by many to be vip dangerous simply because R/W access is program wide and the "who,what,when and where" game can happen - again and again and....!
Making simple single functionality functions that help/remove need for globals... after all, that's what function parameters are for yes?
if functions kept simple and single function the includes are great for grouping into .mqh's eg, includes for files, logs, trace, CT global handling, trade environment informational types and of course defines and EA global/extern variables.
you can build an EA with a top level .mq4 source file with just #include's in it. Then, even start(),init(),deinit() can be in own .mqh file.
since start() is where a lot of specific strategy coding is often done, by having in own file and the 'generics' in other files - is very easy to build many EAs simply and reliably. The bulk of 'generic supporting code' hardly ever needs touching, yes? eg, once you have an errorHandler() just when is it required to touch? Same idea can be used for tradeOps, fileOps, logs, traces (which you turn on/off via extern and have embedded trace function calls in your developing code etc...)
going step further, could even have a tradeDecision() and stopLoss() and exitDecision(),.... that way with a bit of work can probably make start() generic too.
Speed considerations will become even less an issue when MQL5 comes along - 'real compiled/chip native' code I believe and some if(bTrace){...} will not impact on EA speed - just simple compare with jump around if not true...
all of above is how I'm going along the trail. takes more time, more testing, more designing etc. for me, end result is easy EA strategy testing and trading setup and ultimately very easy to modify trading code and not have to concern self with all that generic gunk which can just, in the end, obscure the guts of the beast...
of course: all fwiw and imho
:o))
just some ramblings chucked into the cooking pot... ;)
include files are great way to remove requirement for constants planted inline and used in many files - can easily become a nightmare.
#define is a lifeline for above.
wherever possible one can even do pseudo OOPs like variable 'hiding'. eg, many grouped functions living in a .mqh file may all like to have access to a few variables and these variables do not need to be known about outside that one .mqh file, yes?
Anyway, globals are considered by many to be vip dangerous simply because R/W access is program wide and the "who,what,when and where" game can happen - again and again and....!
Making simple single functionality functions that help/remove need for globals... after all, that's what function parameters are for yes?
if functions kept simple and single function the includes are great for grouping into .mqh's eg, includes for files, logs, trace, CT global handling, trade environment informational types and of course defines and EA global/extern variables.
you can build an EA with a top level .mq4 source file with just #include's in it. Then, even start(),init(),deinit() can be in own .mqh file.
since start() is where a lot of specific strategy coding is often done, by having in own file and the 'generics' in other files - is very easy to build many EAs simply and reliably. The bulk of 'generic supporting code' hardly ever needs touching, yes? eg, once you have an errorHandler() just when is it required to touch? Same idea can be used for tradeOps, fileOps, logs, traces (which you turn on/off via extern and have embedded trace function calls in your developing code etc...)
going step further, could even have a tradeDecision() and stopLoss() and exitDecision(),.... that way with a bit of work can probably make start() generic too.
Speed considerations will become even less an issue when MQL5 comes along - 'real compiled/chip native' code I believe and some if(bTrace){...} will not impact on EA speed - just simple compare with jump around if not true...
all of above is how I'm going along the trail. takes more time, more testing, more designing etc. for me, end result is easy EA strategy testing and trading setup and ultimately very easy to modify trading code and not have to concern self with all that generic gunk which can just, in the end, obscure the guts of the beast...
of course: all fwiw and imho
:o))
Ok think you for these analysis!
[...]
Hi ukt!
I'm sorry to interrupt this, but I've seen several of your postings now and I've got some things I'd like to ask you. Would you be so kind to contact me via ICQ? 241150374Thanks a lot and sorry once again.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hi everybody
I've got a file (var.txt) with some variables
//************var.txt*********************//
double high_d1 = iHigh(NULL, PERIOD_D1, Current + 0);
double low_d1 = iLow(NULL, PERIOD_D1, Current + 0);
double highp1_d1 = iHigh(NULL, PERIOD_D1, Current + 1);
double lowp1_d1 = iLow(NULL, PERIOD_D1, Current + 1);
double sto14 = iStochastic(NULL, 0, 14, 3, 5, MODE_EMA, 0, MODE_MAIN, Current + 0);
double sto14s = iStochastic(NULL, 0, 14, 3, 5, MODE_EMA, 0, MODE_SIGNAL, Current + 0);
double sar = iSAR(NULL, 0, 0.02, 0.2, Current + 0);
double open = iOpen(NULL, 0, Current + 0);
double close = iClose(NULL, 0, Current + 0);
//*******************************//
and I want to put this file in an mq4 file (test.mq4) with the fonction "include" like this
#include <var.txt>
But the programm return this message : " #include <var.txt> cannot open the programm file"
Is it possible to do that ? and how?
Thanks in advance for your help!!