MetaTrader 4 Build 574 with Updated MQL4 Language and Market of Applications Released - page 10

Hmm, and I just stumbled upon the fact that these major upgrades were going to happen..what if I hadn't noticed until it was released, and all users were forced to upgrade? This is bad practise!

But allright, here are my pro-active results so far;

-running the already compiled EX4 from an older build works, including the DLL, if in the correct location

-https://www.mql5.com/en/code/10644 works natively in MQL4/5 in newly compiled test code

-but recompiling anything we had, breaks it now

-I noticed that even MQLLock still works as long as it has already been compiled in an older build

So my options are;

-keep compiling the EA on an older MT4 build; for how long is this going to work?

-rebuild the API completely for client-server communication, basing it on winInet

Thanks for the quick answers.

I would definitively go with the wininet.dll. Though it uses a few string arrays in calls, they can be mostly skipped, filling in the null pointer.

Regarding the recent ex4, I think they will go on working for a long time, perhaps forever. So preserving a metalang/metaeditor from the 509 is a good idea, if you are not going commercial.

hello, after my first test, i want to write some critics about installation options and directory structure

- upgrade from 509 to 574 is smooth, but during the upgrade, no message shown to user. so, if user re-starts another instance of exe, then another process starts.. so it produces many terminal id's and mql4 directories for one MT4 installation's upgrade.

- after upgrade, i tested "portable" mode. but it is not smooth like UAC mode. my idea, during the upgrade, at start of upgrade (or at start of installation) you should give user an option: portable mode or UAC mode.

i prefer portable mode, by default. i could not switch portable mode, after upgrade with UAC mode.. you can vote for portable/UAC default. my PC has one user. UAC is for multiple user PC's.

and microsoft's UAC policies are not so much suitable for traders. for security and upgrade, you may prefer, but user need to know where physical file is.

- i prefer portable mode, all files in a simple directory, by default. UAC is not for traders. terminal runs 24 hour/5 days. and user is never changed.

i wish an easy upgrade.

Thanks :)

Ps. I completely agree with cbalta, almost every serious user runs MT4 on a single user VPS, please either make portable the default, or definitely make this an option for the user during the upgrade / fresh install.

That makes no sense, there is no need to use portable mode on a VPS.

On File menu, choose Open data folder, and you get your data.

hi, possibly you are a developer, not a trader.

if you are running some tens of terminals? . if you run 40 terminals, you will have 40 data dir x40 install dir =1600 matching possibilities. i prefer gamble with fx, not gamble with dirs..

the critical mistake of MQ during mt5 was, they listened to developers, not traders. this last movement will fix this. so we will be able to use MT5 in exchange markets, with mql4, i hope so.

make easy.

The UAC remote storage complicated things. I doubt multiple users share any MT4 terminal. It has complicated things for developers as well. Supposing I use Winapi for file handling, I have to snoop after the storage first, traversing the appdata folder and searching for something like C:\Users\Administrator\AppData\Roaming\MetaQuotes\Terminal\50CA3DFB510CC5A8F28B48D1BF2A5702\origin.txt (thanks god for the origin.txt, without it I could not find it)

What is difficult with "On File menu, choose Open data folder, and you get your data." ?

Why do you need to use Winapi for file handling ?

In the "old" MQL there were a few reasons.

- ill implementation of the file sandbox protection, refusing to accept two dots in the file name (I use a broker that has those dots in a symbol name),

- file write sharing that could not be switched off (fixed in the MQL+)

- data exchange among EAs, when I need access outside the sandbox

- building scripts, that need access to the source folder (yes, I use MQL scripts to support build)

- installing support files (mostly libraries), which are embedded in the script (no longer possible with MQL+, as it does not allow lazy library fetching)

In the MQL+, there are fewer reasons, but still some of them remain valid.