I just installed MC 5 Beta, instructing it to use a different path from the MC 4 installation. (e.g. MultiCharts5).
The beta destroyed the MC 4 installation anyway, and never said that it was going to do so.
What were you thinking ???
This is a terrible way to operate (sorry to be so blunt, but it's in keeping with the BLUNT instrument that you've programmed your installer to be!).
Haven't you any consideration for your users?
PRINCIPLE THE FIRST:
NEVER destroy a user's install (or any user data) without MAKING A BIG DEAL ABOUT IT, and letting them opt OUT!
Let me be straightforward, in all honesty for your own benefit - this behavior needs to be fixed immediately, regardless of whatever you _think_ your other priorities are.
If you don't fix this, you are simply saying "WE DON'T CARE IF WE DESTROY THE CUSTOMER'S SETUP". How good can that be for your business?? How do you think people will feel in the field when you do this to them?
Please consider this post not a slam, but a reminder that consideration of the actual user experience that your software creates _must_ be a TOP PRIORITY in all cases.
MC 5 Beta Install Destroys MC v4
- TJ
- Posts: 7740
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2221 times
- Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
Re: MC 5 Beta Install Destroys MC v4
Our point of view is different from yours. Most people install the new version on top of the old one and want this done automatically. Furthermore, none of your user data is deleted in the process.I just installed MC 5 Beta, instructing it to use a different path from the MC 4 installation. (e.g. MultiCharts5).
The beta destroyed the MC 4 installation anyway, and never said that it was going to do so.
What were you thinking ???
This is a terrible way to operate (sorry to be so blunt, but it's in keeping with the BLUNT instrument that you've programmed your installer to be!).
Haven't you any consideration for your users?
PRINCIPLE THE FIRST:
NEVER destroy a user's install (or any user data) without MAKING A BIG DEAL ABOUT IT, and letting them opt OUT!
Let me be straightforward, in all honesty for your own benefit - this behavior needs to be fixed immediately, regardless of whatever you _think_ your other priorities are.
If you don't fix this, you are simply saying "WE DON'T CARE IF WE DESTROY THE CUSTOMER'S SETUP". How good can that be for your business?? How do you think people will feel in the field when you do this to them?
Please consider this post not a slam, but a reminder that consideration of the actual user experience that your software creates _must_ be a TOP PRIORITY in all cases.
- Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
Hi TJ,I too, would like to see 2 concurrent versions on my computer.
Especially knowing we are still in beta, it is only prudent if we can roll back with the least pain and effort.
Windows installer installs the newer versions of programs on tops of others.
In future, we are planning to add a feature that will allow having two different versions of MultiCharts on your computer at the same time.
Regards.
- TJ
- Posts: 7740
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2221 times
that's good new.Hi TJ,I too, would like to see 2 concurrent versions on my computer.
Especially knowing we are still in beta, it is only prudent if we can roll back with the least pain and effort.
Windows installer installs the newer versions of programs on tops of others.
In future, we are planning to add a feature that will allow having two different versions of MultiCharts on your computer at the same time.
Regards.
Thanks.
And, most people wind up losers in the market ...Most people install the new version on top of the old one and want this done automatically.
Anyone who is willing to have their primary realtime trading platform (RTTP) installation over-written at arbitrary intervals is only 1 disaster away from a BIG enlightenment .
MC could never be my RTTP without the ability to have multiple versions installed on the same machine without interfering with each other. I don't personally know any serious trader who feels differently.
In any case, if anyone wants for any reason to go on ahead and cream their old installation when installing the new, it's fine to let them. It's just not fine to make the rest of us follow suit.
As always, thanks for your response and your candor.
I hope the future multi-install capability is soon in coming. This is a good problem to solve, and then never have to face again.
- Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
Hi MC _Prog,
The way Windows System Installer works is that it requires that a program should be removed from the system before another program with the same name can be installed.
Several MC versions ago, removal and the subsequent installation were done in two steps. First, a user was asked to run the installer and choose the 'remove' option. After that the installer needed to be run again - to put the new version of the program on your PC.
Many MC customers said that the process was too cumbersome and inconvenient and asked it to be all done in one step, which we have since implemented.
Now, what you are talking about - the ability to use two different versions of the program on your computer - is a perfectly reasonable requirement whose implementation will enhance your trading experience. However, the implementation of this feature is not as easy as it might seem.
As I said, Windows does not allow having two programs with exactly the same name on your computer. This means, that we'll need to make sure that every MC build has its own name. Which isn't difficult to do. However, the real challenge is: how to go about user data? For the system, you will have two different programs on your PC. The problem is that these two programs will need to share data. We need to find a way to solve this problem.
The bottom line is: in future, it will be possible to have two MC versions on your PC at the same time. ETA for this feature hasn't been determined yet.
The way Windows System Installer works is that it requires that a program should be removed from the system before another program with the same name can be installed.
Several MC versions ago, removal and the subsequent installation were done in two steps. First, a user was asked to run the installer and choose the 'remove' option. After that the installer needed to be run again - to put the new version of the program on your PC.
Many MC customers said that the process was too cumbersome and inconvenient and asked it to be all done in one step, which we have since implemented.
Now, what you are talking about - the ability to use two different versions of the program on your computer - is a perfectly reasonable requirement whose implementation will enhance your trading experience. However, the implementation of this feature is not as easy as it might seem.
As I said, Windows does not allow having two programs with exactly the same name on your computer. This means, that we'll need to make sure that every MC build has its own name. Which isn't difficult to do. However, the real challenge is: how to go about user data? For the system, you will have two different programs on your PC. The problem is that these two programs will need to share data. We need to find a way to solve this problem.
The bottom line is: in future, it will be possible to have two MC versions on your PC at the same time. ETA for this feature hasn't been determined yet.
- TJ
- Posts: 7740
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2221 times
Marina,
Good background and good discussion. Thanks!
IOW, the multiple programs do not necessarily need to share data. They can each have their own data store, and probably should. The older data store can be copied forward to form the baseline of the newer data store. They can subsequently be kept separate.
Disk space is cheap, so that should not be the issue.
I would say that one important issue would be having a new release corrupt a perfectly good, carefully collected data store. Of course, this would never be intended, but it could happen. This is a catastrophic result for someone who is relying upon their trading platform for their income stream. IMO, we are back to Principle the First here. The careful trader's goal is the highest possible stability in both code and data, once each are found to be correctly working for that trader's campaign.
The safest course is clearly to have a new version write to a new data store. This also has the merit of not requiring a "shared data store solution" to be designed and implemented.
I'm really glad you brought this up. IMO, this subject is worthy of detailed discussion with the community before the effort of design and implementation is decided upon. Thanks again!
Good background and good discussion. Thanks!
Well, I think it might be worth questioning this assumption. Certainly there are counter-examples out there.Now, what you are talking about - the ability to use two different versions of However, the real challenge is: how to go about user data? For the system, you will have two different programs on your PC. The problem is that these two programs will need to share data. We need to find a way to solve this problem.
IOW, the multiple programs do not necessarily need to share data. They can each have their own data store, and probably should. The older data store can be copied forward to form the baseline of the newer data store. They can subsequently be kept separate.
Disk space is cheap, so that should not be the issue.
I would say that one important issue would be having a new release corrupt a perfectly good, carefully collected data store. Of course, this would never be intended, but it could happen. This is a catastrophic result for someone who is relying upon their trading platform for their income stream. IMO, we are back to Principle the First here. The careful trader's goal is the highest possible stability in both code and data, once each are found to be correctly working for that trader's campaign.
The safest course is clearly to have a new version write to a new data store. This also has the merit of not requiring a "shared data store solution" to be designed and implemented.
I'm really glad you brought this up. IMO, this subject is worthy of detailed discussion with the community before the effort of design and implementation is decided upon. Thanks again!
The problem is that these two programs will need to share data. We need to find a way to solve this problem.
There are two issues worth noting here:Well, I think it might be worth questioning this assumption. Certainly there are counter-examples out there.
1. some people have HUGE data stores
2. A thought out backup regimen solves a lot of problems