Avoiding MT5 update to modify Include\Trade\ files

New comment
 

Hello,

due to obvious reason related to buggy metaquotes libraries (that they seems not want to fix them) every time that my MT5 platform get updated library are restored to "original" with all related problems.

Is there a way to avoid MT5 to update libraries?

Or better, is there some way to invite MetaQuotes to fix their bugged libraries? (bug that are already found, documented and fixed by a lot of users)

Like this one:

https://www.mql5.com/en/forum/326381

And this one:

https://www.mql5.com/en/forum/328929

 

You could prevent MT from applying updates. If a new version is pending, create a copy of the installation, let it update and lock again.

So you end up with folders like MT.2087, MT.2280, MT.2340 etc, and you develop/test on one of that versions. Whenever you feel you want to move the codebase to a newer release, do it.

 
Thanks for this suggestion
 
lippmaje:

You could prevent MT from applying updates. If a new version is pending, create a copy of the installation, let it update and lock again.

So you end up with folders like MT.2087, MT.2280, MT.2340 etc, and you develop/test on one of that versions. Whenever you feel you want to move the codebase to a newer release, do it.

I can't read this "prevent updates" advice without reacting. It's a very bad advice. Do it a your own risk.
 
Fabio Cavalloni:

Hello,

due to obvious reason related to buggy metaquotes libraries (that they seems not want to fix them) every time that my MT5 platform get updated library are restored to "original" with all related problems.

Is there a way to avoid MT5 to update libraries?

Or better, is there some way to invite MetaQuotes to fix their bugged libraries? (bug that are already found, documented and fixed by a lot of users)

Like this one:

https://www.mql5.com/en/forum/326381

And this one:

https://www.mql5.com/en/forum/328929

By preference order :

1. Never modify the library files directly. But work on a copy, fix the bugs. Of course there are drawbacks in case of good changes or addition made by MQ, you will need to port it to your copy,

2. Take the libraries as a base by copying them (as point 1), but after that maintain them entirely yourself.

3. Add the libraries to the mql5 storage. This way you can control the changes and accept or refuse the ones coming with the new updates. Of course there are drawbacks, but different from point 1, you will need to check on each update.

4. Stop using these buggy libraries, allegedly "standard". It is my preferred solution :-D (I use also solution 3 for some I am still using).
 

Thanks Alain for pushing me in the right direction!

I think that I will start to make my own copy and, during next projects, starting to avoid using them, but they are very usefull, specially for trade and position functions...

 
Alain Verleyen:
I can't read this "prevent updates" advice without reacting. It's a very bad advice. Do it a your own risk.

It's not uncommon to develop software on/for a stable environment. Auto-updates might be appreciated by normal users, but for developers it can cause a lot of trouble. Thinking of the issues that turned up recently, things like optimizer failure, or changes to standard calls that caused EAs to malfunction from one day to another. Moreover it's practical to have a bunch of releases at hand for the sake of development and debugging on a release of your choice.

By the way you recommend to work with legacy copies yourself, by just creating copies of headers and classes from a prior release. How stable is this if you use headers/classes from release X compiled with the system of release Y? What if - ok, in theory - the behavior of an internal call changed and you compile an outdated library that relied on the former version of it? Different error codes returned, things like that.

The recommendation you gave is to create a 'happy' mix of libraries from different releases. This is even worse than the advice that I gave. :D

 
lippmaje:

It's not uncommon to develop software on/for a stable environment. Auto-updates might be appreciated by normal users, but for developers it can cause a lot of trouble. Thinking of the issues that turned up recently, things like optimizer failure, or changes to standard calls that caused EAs to malfunction from one day to another. Moreover it's practical to have a bunch of releases at hand for the sake of development and debugging on a release of your choice.

Blocking update of official release is a bad practice, used as a workaround to avoid managing coding issues correctly. (You proposed to block updates to avoid files to be overwritten, seriously ?). And it's against MT5 licence by the way. Beside that, I never said you can't use old builds, are you thinking I am always working with the last official release ? This is something else entirely.
This a public forum, read by a lot of people (which for the most part never write here), it's not about you or developers which anyway will do what they want, because they are supposed to know what they do. It's about users having an issue and searching for a solution on the forum. Never recommend to block updates. It is elementary.

By the way you recommend to work with legacy copies yourself, by just creating copies of headers and classes from a prior release. How stable is this if you use headers/classes from release X compiled with the system of release Y? What if - ok, in theory - some of the system calls changed and you compile an outdated library that relied on the former version of it? Different error codes returned, things like that.

What the libraries source code have to do with a given release of MT5 ? Nothing or almost, they are published at the same time but except in rare case, when MQ break backward compatibly (thanks to them for that), you don't need a given build to run a library.

The recommendation you gave is to create a 'happy' mix of libraries from different releases. This is even worse than the advice that I gave. :D

This is completely wrong.  Firstly I didn't recommend anything. Secondly there is nothing in what I suggested as solutions which is related from near or far to a "mix" of libraries. Read again. Finally, if you want to see a recommendation in what I wrote, it's to NOT use any of these libraries at all.

In summary you wrote a lot of assumptions, you misread or interpreted or misunderstood what I wrote. I am not accustomed to read such dishonest post from you, it's a pity.
 
How would you see your item list if not as recommendation? A developer following that list would end up with a bunch of libraries copied from different releases, where 'bugs' are partly fixed. This bunch would have to be examined for compatibility for every new release. This is what I perceive when I read your answer, and I pointed that out. Let's cut it here and refrain from taking this to a personal level. If you want to argue, please stay polite.
 
lippmaje:
How would you see your item list if not as recommendation? A developer following that list would end up with a bunch of libraries copied from different releases, where 'bugs' are partly fixed. This bunch would have to be examined for compatibility for every new release. This is what I perceive when I read your answer, and I pointed that out. Let's cut it here and refrain from taking this to a personal level. If you want to argue, please stay polite.

You are free to be wrong in your perception. I just clarified how you was wrong. Why can't you just answer on YOUR recommendation about blocking the updates, instead of talking about my supposed recommendation ? If you don't want personal reaction, don't make personal offence.

Where was I not polite ?

 
You wrote that blocking updates was a 'very bad' advice, and so I clarified my point - the developer may deliberately choose on which release the development/testing is carried out, for the sake of avoiding hazards. There is no offence in my reply. Highlight the part that you perceive to be offensive and I'll comment. However, I don't see where this part of discussion would be a benefit to this forum. Pm me if you want.
12
New comment
Reason: