Strange behaviour of MC 3

Questions about MultiCharts and user contributed studies.
Boon Lee Quah
Posts: 9
Joined: 25 Aug 2007

Strange behaviour of MC 3

Postby Boon Lee Quah » 17 Apr 2008

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?
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 337 times

autotrade
Posts: 15
Joined: 04 Apr 2008

Postby autotrade » 17 Apr 2008

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.

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 17 Apr 2008

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.
Hi autotrade,

This is definitely not a normal behavior. Please contact our customer support at http://messenger.providesupport.com/mes ... pport.html

Boon Lee Quah
Posts: 9
Joined: 25 Aug 2007

Postby Boon Lee Quah » 22 Apr 2008

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?

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Re: Strange behaviour of MC 3

Postby Marina Pashkova » 29 Apr 2008

Hi Boon Lee,

Please find the answers to your questions below.

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?
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.
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?
This is an intended behavior.

Boon Lee Quah
Posts: 9
Joined: 25 Aug 2007

Postby Boon Lee Quah » 30 Apr 2008

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.

SUPER
Posts: 646
Joined: 03 Mar 2007
Has thanked: 106 times
Been thanked: 84 times

Postby SUPER » 30 Apr 2008

Would it not make more sense to create symbol based cache folder/files and update them rather then creating new files each day. ( similar to what TS does)

User avatar
Marina Pashkova
Posts: 2758
Joined: 27 Jul 2007

Postby Marina Pashkova » 30 Apr 2008

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 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.
(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!
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.
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.

i. Will the Cache directory grow indefinitely?
Yes. There are no limitations on the cache size.
ii. Can this be implemented more efficiently to reduce the use of disk space?
See above.
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.
Clearing cache every now and then should not be too time-consuming.
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.
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.
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.
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.


Return to “MultiCharts”