+1 888 340 6572 GET STARTED
MultiCharts Project Management
previous_open_issue.png
Go to the previous open issue
previous_issue.png
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
feature_request_small.png
Open Feature request MC-1130

Turning a study off and on retrains its sub-chart setting but only if MC is still running.

action_vote_minus_faded.png
4
Votes
action_vote_plus_faded.png
next_issue.png
Go to the next issue (open or closed)
next_open_issue.png
Go to the next open issue
Description

I reported ths before as a bug and the response was that it was not a bug.
http://www.multicharts.com/pm/viewissue.php?issue_no=MC-478
So this time I am reporting it as a feature request. However I can recreate it this time every single time. The key is in the subject line.
Turning a study off and on retrains its sub-chart setting but only if MC is still running.
I have 2 studies which are on the 1 minute bars that create the arrows I move to the tops and bottoms of the waves. I turn these off at the end of the trading day so they are hidden when I save my trade calls and system calls to a png file for my record keeping and review the next morning. If I turn then back on before I close MC down for the day they will remember their subchart setting which is sub-chart #1. If I forget to turn them back on before closing MC down for the night every single time without fail they forget their sub-chart #1 setting and will revert to adding a new sub-chart #3 when they are turned on the next day. So whether it is considered a feature request or a bug it is irrelative and is certainly nothing more than splitting hairs. Either way this is unexpected behabior and certainly unwanted behavior and it will effect every user. Also, it should not matter what any of the other settings are for the study. If the user has selected a specific subchart MC should remember it even after it has been shut down.
I will eventually upgrade to MC 8.0 again and I am pretty sure this problem exists there too.

Steps to reproduce this issue

**Create a study on subchart number 1.
**While MC is up turn the study off and on and it will remember the subchart #1.
**Turn the study off.
**Shut MC down then bring MC back up.
**Turn the study back on and it will create a new subchart at the bottom of the chart.

Comments (1)
#0
user-offline.png  John Bowles (bowlesj3)
Jan 14, 2013 - 14:59

This problem of MC changing the subchart a study/indicator is applied to happened under a different situation today on all my charts (60 min, 30min, 15min, 10min, 5min) except not on the 1 min and 10 second. The only difference is that the 1 minute bar chart is inside MC and the other charts are outside MC so I can have macroexpress position the larger charts consistently.
. . 
IMPACT:
 In total a count of 7 studies had to be manually changed back to subchart #1 where they always have been and always should be. Each of these manual corrections takes exactly 7 mouse clicks. In total this manual correction took me a total of 7 * 7 = 49 mouse clicks due to what I consider a bug in MC and it appears two others agree with me based upon the votes. If my feature requests were in place for the PM system the number would be higher.
. . 
I doubt you or I can reproduce this but here is what happened. I simply changed the studiy over the weekend (with several recompiles over about 7 hours) and did nothing else. Maybe MC was up during one of the compiles (I am not sure). This problem may not be the biggest problem in the MC world but MC should eventually be changed to remember that these studies are designated by my decision to be applied to subchart #1 and it should never change it on the user no matter what happens. In other words, I believe there will never be an exception to this rule.

History
Issue basics
  • Type of issue
    Feature request
  • Category
    Not determined
  • Targeted for
    Not determined
  • Status
    Not Reviewed
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (2)
People involved
Times and dates
  • Posted at
  • Last updated
Issue details
  • Resolution
    Not determined
  • Severity
    Normal
Attachments (0)
There is nothing attached to this issue
Commits (0)
There are no code checkins for this issue
Duplicate issues (0)
This issue does not have any duplicates