how to include a file.txt in an mq4 file ??

To add comments, please log in or register
natsirte
427
natsirte  

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!!

okwh
1643
okwh  

1 put it in \experts\include

2 rename it to var.mqh

3 use it in your mq4 file with:

#include <var.mqh>

natsirte
427
natsirte  

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!

okwh
1643
okwh  

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.

natsirte
427
natsirte  

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 !

ukt
473
ukt  

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))

natsirte
427
natsirte  
ukt:

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))

natsirte
427
natsirte  
natsirte:
ukt:

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!

schnappi
248
schnappi  
ukt:
[...]

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? 241150374

Thanks a lot and sorry once again.

ukt
473
ukt  

schnappi, I am ignorant of contact medium you give. Not know how use any topical comms functionality except email and forums and [even at a push;] the telephone...

So not able to do icq contact. May be ukttku at gmail dot com is your best route.

Regards

To add comments, please log in or register