extern variables and timeframe change?

G

Is documented, see https://book.mql4.com/programm/special

Changing chart period will cause a deinit(), followed by an init()

Many conditions will cause a deinit, so much though has to go into enabling the EA to resume from where it left off

When running a commercial EA, it helps to have a .set file storing current preferences in case of a deinit occurring

-BB-

It says nothing about EXTERN vars being reinitialized when init() and deinit() occur. It is not obvious at all. Normal global variables for example are NOT reinitialized if init() or deinit() run...

You're right. For example, the output of the following EA differs across reloads depending on whether the global variable is declared as extern or not.

string glbExampleVariable = "first run";
int init()
{
   MessageBox("Value: " + glbExampleVariable);
   glbExampleVariable = "modified value";
}
int start() {}

It's linked to another annoyance of MT4: you can change an extern parameter from within the code, but that change isn't reflected in the properties window.

I'm sure what's happening is that the EA's properties get stored in the .chr file for the chart, and these are re-read from disk every time the EA is loaded back onto the chart. Changing the values in memory (from the code) doesn't affect what's held on disk and subsequently re-read. It is possible to alter the .chr file from within code, in order to make changes to the settings persist, but that's very messy.

I agree. Very messy. And about the properties window as well. Thanks for the info.

Hello BB (and others too :)

If time and inclination, could you list out what your EA saves and when/where?

1. Is the dump a rewrite or an update? eg, simpler to simply dump ALL? or if multi order EA must be arrays or maybe order records? or perhaps just ticket#'s (assuming no other explicit per order data held)

1.1. OR maybe no need to hold any data except that data held in compile time startup datums which may have been altered.

1.2. eg, my EAs all key their orders magic# with 1 or more datums, always the EAID# and none, 1 or more other per order codes. Meaning the TradePool can be inspected using EAID# to p/u current state.

2. Do you deal with 'same EA' on other charts? One implication could be dump file names but assume if each instance has warranteed unique EAID# then not issue.

2.1. What other implications? or if you allow multi instances, how handle...?

3. Does your code 'clean up' on restart+reinstatement of last environment via dump file?

3.1. eg, TradePool could have changed in deinit()...init() time window and dump file would in effect be inconsistent - thinking reconciliation between current ClientTerminal restart environment against reinstated EA environment and rewrite/update of dumpfile etc.

3.2. or with ref to 1. above, TradePool state if indeed relevent, is taken care of by other mechanisms?

Most likely seen as subjective area but since some site users are selling EA's I would presume that some scheme is used to deal with restarts...

Would be very instructive to hear "how U doit" and as always, some detail would be nice instead of just "I dump to file" :/

My list is not I'd hazard a guess, complete or even comprehensible? but How do YOU deal with restarts? should be reasonable question, yes?

Thanks in anticipation...

Here's how I do it, for what its worth.

I save to a recovery file:

- Information that the EA would need to get back in step with its signal decision making

- Information that the EA would need to get back in step with its money management strategy

- Information to validate that this recovery file is current

I do not save to the recovery file:

- Information that is persisted elsewhere such as the Trades and History lists, I tend to have my EAs read their trades out of the Trades list on init()

- Variables that the EA does not change and will automatically be applied by the platform on a reinitialisation

I name the recovery file based upon the EA name, EA version number, and Symbol/Chart.

Hope this helps.

CB

-

CB

Yes - this does help! Will ad to my 'table' of this 'n that's so can come to workable setup for self. Thank you loads :o)

when,where how often save?

asking because there is no warrantee that deinit() entered... eg, power fail, windoz bsod, etc.

eg, if DB system, checkpointed data would/could also be restart point not only for DB state but also for non-stop environment - ummm old now most likely but thinking Tandem o/s+h/w environ.

C'mon guys 'n gals... any other's willing to tell all???

I remember Tandem NonStop indeed. Think I even managed a bit of TAL programming years ago.

I never use deinit() to checkpoint data. I only ever use deinit() to send email to notify the user of the un-initialization reason.

I checkpoint the data after "significant events" which obviously vary from strategy to strategy, but for example, if there is a change to some of that key data which I persist.

CB

Wow.... (massive excitement). I spent 3yrs Tandem Technical support for Barclays in 80's. Came from s/w engineering background and drop naively into tie 'n jacket brigade in air-con plush office/floor - lol

Went on more Tandem and TAL courses than care to think about! Was such a massive shift of knowledge bases. I even scrounged a complete Tandem manual set cuz always getting updates anyways. Took it home and read and read. Man, I just loved it all. Guardian was awesome, coming from Dec's RSX-11M and ..S on pdp's but out of 5 or 6 assemblers used, still have soft spot for pdp-11 assembler + RSX.

I bet you came across Coral-66? Spent over 10yrs with it. Was even using the old girl late 90's on legacy work (only way I got the job was able to spell Coral! nobody wants an old fart that knows way too many LLL's and HLL's circa 70's and 80's :)

You ever hear/see or work on Ferranti Atlas? My first love... Uni of Ldn long time ago.

Sad or what... memories - nowadays is enough to get Print() to work.

.

Ok enuff sad git stuff! THANK YOU indeed. Expected as much but is good to actually hear what other's doing. Is vip area indeed.

Thank you also for mentioning your Tandem NS, TAL assoc. Think I'll go off 'n read some of my old listings, just to relive it a bit :)

My position is very similar to CB's: most of the EAs I deal with need "state" information above and beyond the raw list of orders in MT4. The nature of this state information is broadly very similar to CB's. The only real difference is that I do tend to store information such as the list of trades which the EA thinks it is managing, partially duplicating the information in MT4's trade list, and then have the EA complain very loudly if there's a mismatch with MT4's trade list when the EA restarts. This has never happened in real life, but I'm a very paranoid person.

The data simply gets dumped into the experts\files directory, albeit using Win32 file functions rather than the MT4 built-in ones. As with CB, there is validation that the state file is recent and not corrupt. The frequency of the storage is user-configurable. All the EAs I deal with are not remotely time-sensitive, and there would be no issue in having them save their state data to disk on every single tick given that the operation typically takes about 4 to 5 milliseconds - the EA would miss a few ticks per minute because it was busy saving state data from the previous tick, but this wouldn't matter.

The state data then gets continuously copied to multiple remote sites for disaster-recovery purposes. The remote sites hold an archive of the state data rather than just the most recent file, in case corrupt data gets transferred. And, by extremely careful use of order comments, bearing in mind brokers' ability to alter them, I tend to get EAs to record as much of the state information as possible in the MT4 order comment as well. Where possible, this gives them the ability to be started in a special "recovery mode" in the absence of a state file, telling the EA to do the best job it can of recovering its state from the MT4 order history alone. Such a recovery then typically requires manual intervention sooner rather than later to fill in gaps in the information which has been recovered, but it's better than having the EA refuse to do anything at all because its state data is missing or corrupt.