I've installed MC version 3.0.1200.4785 and found the following strange behaviour:
1. I keep getting Timeout error when trying to add a symbol. I remember encountering the same problem with an earlier version. Do I need to wait for a patch to have this fixed?
2. This version generates a lot more files (thousands) under the C:\Documents and Settings\...\Local Settings\Application Data\TS Support\MultiCharts\Cache directory compared to the previous version (2.1.999.999). Whereas the previous version deletes all files in the cache directory when it completely exits, this version leaves behind a huge number of files (more than a thousand taking up more than 1GB). Why??? Is the cache directory supposed to replace TSCACHE.GDB?
3. Strange workspace behaviour (different from 2.1.999.999):
a) The attached screenshot Before.png shows the 'test' workspace with 3 minimized chart windows in the middle of the workspace. If I maximize any chart window and then restore it, the 3 minimized charts in the middle gets moved to the bottom of the workspace as shown in After.png. Why?
b) Try the following steps with the attached test.wsp:
i. minimize the AB #F chart
ii. move it and place it below the minimized 6E #F chart
iii. save the workspace
iv. restore AB #F chart and then minimize it again
Why does the minimized AB #F chart move back to the bottom of the workspace when it was relocated to below 6E #F in the middle of the workspace?
v. close the workspace and then open it again
The minimized AB #F now appears below the minimized 6E #F.
Why is it necessary to close the workspace (after saving) and reopen it before it "remembers" where a minimized chart has been moved?
Strange behaviour of MC 3
-
- Posts: 9
- Joined: 25 Aug 2007
Strange behaviour of MC 3
- Attachments
-
- After.png
- (75.58 KiB) Downloaded 479 times
-
- Before.png
- (79.18 KiB) Downloaded 489 times
-
- Timeout.png
- Timeout when trying to add sumbol
- (25.26 KiB) Downloaded 471 times
-
- test.wsp
- (48.46 KiB) Downloaded 339 times
- Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
Hi autotrade,i'm on my 6th reboot.
Keeps freezing up on me when trying to open script with a chart up. Have to shut it down and restart the computer.
This is definitely not a normal behavior. Please contact our customer support at http://messenger.providesupport.com/mes ... pport.html
-
- Posts: 9
- Joined: 25 Aug 2007
I found that the Timeout error when adding symbol is intermittent and could as likely be a problem with the data provider.
But am I the only one with the problem of having a huge number of files generated and left behind in the Cache directory after MC 3 exits? After running MC 3 a few times, thousands of files are left in the Cache directory taking up GBs of disk space... which cannot be normal behaviour. I've since uninstalled MC 3 and gone back to MC 2.1.999.999 which generates much fewer files in the Cache directory when running and deletes all of them on exit.
Any comments on the strange workspace behaviour I raised in my original post?
But am I the only one with the problem of having a huge number of files generated and left behind in the Cache directory after MC 3 exits? After running MC 3 a few times, thousands of files are left in the Cache directory taking up GBs of disk space... which cannot be normal behaviour. I've since uninstalled MC 3 and gone back to MC 2.1.999.999 which generates much fewer files in the Cache directory when running and deletes all of them on exit.
Any comments on the strange workspace behaviour I raised in my original post?
- Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
Re: Strange behaviour of MC 3
Hi Boon Lee,
Please find the answers to your questions below.
Please find the answers to your questions below.
Cache directory is not cleared automatically upon closing MC anymore. This is done to speed up chart plotting on starting the program again. If you have too much data stored in the cache directory you can simply clear it manually.
2. This version generates a lot more files (thousands) under the C:\Documents and Settings\...\Local Settings\Application Data\TS Support\MultiCharts\Cache directory compared to the previous version (2.1.999.999). Whereas the previous version deletes all files in the cache directory when it completely exits, this version leaves behind a huge number of files (more than a thousand taking up more than 1GB). Why??? Is the cache directory supposed to replace TSCACHE.GDB?
This is an intended behavior.3. Strange workspace behaviour (different from 2.1.999.999):
a) The attached screenshot Before.png shows the 'test' workspace with 3 minimized chart windows in the middle of the workspace. If I maximize any chart window and then restore it, the 3 minimized charts in the middle gets moved to the bottom of the workspace as shown in After.png. Why?
b) Try the following steps with the attached test.wsp:
i. minimize the AB #F chart
ii. move it and place it below the minimized 6E #F chart
iii. save the workspace
iv. restore AB #F chart and then minimize it again
Why does the minimized AB #F chart move back to the bottom of the workspace when it was relocated to below 6E #F in the middle of the workspace?
v. close the workspace and then open it again
The minimized AB #F now appears below the minimized 6E #F.
Why is it necessary to close the workspace (after saving) and reopen it before it "remembers" where a minimized chart has been moved?
-
- Posts: 9
- Joined: 25 Aug 2007
Marina,
A) With regards to the Cache directory:
My observation is that with my usage, after running MC less than 10 times, the Cache directory grows to several thousand files taking up several GB of disk space (The 3 GDB files take up less than 450MB in total, which means the Cache directory is several times bigger than the whole database). This may be insignificant for users with hard disks bigger than 100GB, but I'm still using a 40GB hard disk and 4GB is already 10% of my disk space!
i. Will the Cache directory grow indefinitely?
ii. Can this be implemented more efficiently to reduce the use of disk space?
Prior to version 3, MC was "maintenance free" like most if not all other software. However, with the introduction of a Cache directory that grows indefinitely(?), users have to manually delete files from the Cache directory in order to free up disk space either periodically or when Windows warns of critically low disk space. I suggest doing the following:
1. Let users decide how much disk space to set aside for the Cache directory like web browsers do and how Windows allow users to determine size of recycling bin and virtual memory.
2. Make it an option for MC to automatically empty the Cache directory on exit just like how it is an option whether workspaces are saved on exit.
B) With regards to the workspace behaviour:
I don't understand the motivation or logic behind the change from the previous version. Just as one would expect a maximized window to return to its previous location when it is restored, one would expect other minimized windows to remain where they have been purposely (painstakingly?) placed rather than rearranged to the bottom of the workspace. If the motivation is to make it easy to rearrange multiple minimized windows, I suggest doing the following:
1. Return to workspace behaviour as in previous version.
2. Under the "Window" menu, add a function to "Arrange Minimized". Perhaps even give users the option to arrange the minized windows at the bottom, top, left, or right of the workspace.
A) With regards to the Cache directory:
My observation is that with my usage, after running MC less than 10 times, the Cache directory grows to several thousand files taking up several GB of disk space (The 3 GDB files take up less than 450MB in total, which means the Cache directory is several times bigger than the whole database). This may be insignificant for users with hard disks bigger than 100GB, but I'm still using a 40GB hard disk and 4GB is already 10% of my disk space!
i. Will the Cache directory grow indefinitely?
ii. Can this be implemented more efficiently to reduce the use of disk space?
Prior to version 3, MC was "maintenance free" like most if not all other software. However, with the introduction of a Cache directory that grows indefinitely(?), users have to manually delete files from the Cache directory in order to free up disk space either periodically or when Windows warns of critically low disk space. I suggest doing the following:
1. Let users decide how much disk space to set aside for the Cache directory like web browsers do and how Windows allow users to determine size of recycling bin and virtual memory.
2. Make it an option for MC to automatically empty the Cache directory on exit just like how it is an option whether workspaces are saved on exit.
B) With regards to the workspace behaviour:
I don't understand the motivation or logic behind the change from the previous version. Just as one would expect a maximized window to return to its previous location when it is restored, one would expect other minimized windows to remain where they have been purposely (painstakingly?) placed rather than rearranged to the bottom of the workspace. If the motivation is to make it easy to rearrange multiple minimized windows, I suggest doing the following:
1. Return to workspace behaviour as in previous version.
2. Under the "Window" menu, add a function to "Arrange Minimized". Perhaps even give users the option to arrange the minized windows at the bottom, top, left, or right of the workspace.
- Marina Pashkova
- Posts: 2758
- Joined: 27 Jul 2007
We are planning to change the current arrangement behavior for the minimized windows. Their positions will be saved and won't change when you manipulate different chart windows within a workspace.Marina,
A) With regards to the Cache directory:
The number of MC runs has nothing to do with the cache consumption. What matters is how much data you plot. Normally, if you use the same symbols in the same resolutions every day, the cache won't be growing that much. But if you plot 25 symbols today and then other 25 symbols tomorrow you'll get twice as much data that'll take up twice as much space.My observation is that with my usage, after running MC less than 10 times, the Cache directory grows to several thousand files taking up several GB of disk space
The whole point of the cache as opposed to the database is not to compress the data - to ensure the faster access. In the database on the other hand, everything is tightly packed. The result is a very efficient use of the available space. But exactly because the data is packed it takes longer to access it.(The 3 GDB files take up less than 450MB in total, which means the Cache directory is several times bigger than the whole database). This may be insignificant for users with hard disks bigger than 100GB, but I'm still using a 40GB hard disk and 4GB is already 10% of my disk space!
What you could do is buy a USD hard drive and have you cache files saved there.This may be insignificant for users with hard disks bigger than 100GB, but I'm still using a 40GB hard disk and 4GB is already 10% of my disk space!
Yes. There are no limitations on the cache size.i. Will the Cache directory grow indefinitely?
See above.ii. Can this be implemented more efficiently to reduce the use of disk space?
Clearing cache every now and then should not be too time-consuming.Prior to version 3, MC was "maintenance free" like most if not all other software. However, with the introduction of a Cache directory that grows indefinitely(?), users have to manually delete files from the Cache directory in order to free up disk space either periodically or when Windows warns of critically low disk space.
We will consider your suggestions. However, I must say that we are not going to implement any changes in the nearest future. You are the only customer who has contacted us regarding this issue.I suggest doing the following:
1. Let users decide how much disk space to set aside for the Cache directory like web browsers do and how Windows allow users to determine size of recycling bin and virtual memory.
2. Make it an option for MC to automatically empty the Cache directory on exit just like how it is an option whether workspaces are saved on exit.
B) With regards to the workspace behaviour:
I don't understand the motivation or logic behind the change from the previous version. Just as one would expect a maximized window to return to its previous location when it is restored, one would expect other minimized windows to remain where they have been purposely (painstakingly?) placed rather than rearranged to the bottom of the workspace. If the motivation is to make it easy to rearrange multiple minimized windows, I suggest doing the following:
1. Return to workspace behaviour as in previous version.
2. Under the "Window" menu, add a function to "Arrange Minimized". Perhaps even give users the option to arrange the minized windows at the bottom, top, left, or right of the workspace.