Hi TS-Support,
After stuggling with this issue myself and seeing a few others do the same it occured to me that MC could help the traders program easier if, when they click on the "update on every tick" checkbox, a popup came up (which could be turned off of course) that mentioned the IntraBarPersist and BarStatus commands. It would recommend the "IntraBarPersist" usage on all variables if "update on every tick" was choosen. Also if this popup had buttons to go direct to the help on these two commands it would help new traders. The help might be enhanced with generic test samples and diagrams to explain what is going on when IntraBarPersist is and is not used. Some of the posts URLs below related to this issue have a few ideas for this.
Additionally, if the user wanted, maybe they could set an option to force "IntraBarPersist" use if a study is set to "Update On Every Tick". If this is done it might be worth having a shortform such as "IBP" for the "IntraBarPersist" reserve word.
Note that one of these posts mentions the fact that Text, Arrows and TrendLines get deleted over and over until the end of the bar when "Update On every tick" is used. Maybe this could be mentioned in the popup. Maybe the help could be enhanced here too.
http://forum.tssupport.com/viewtopic.php?p=23072#23072
http://forum.tssupport.com/viewtopic.ph ... highlight=
http://forum.tssupport.com/viewtopic.php?t=5815
I am finished my programming so it has no impact on me but it may help increase MC sales if traders have less stuggles in this area.
Thanks,
John.
Suggestion - Update on every tick popup warning.
Re: Suggestion - Update on every tick popup warning.
John
My view is different. In a perfect world if update eveytick was selected variables should automatically persist. No extra coding should be necessary. Short of that ultimately its the programmers duty to understand the limitations of the platform he/she is coding on. Its unnecessary fluff and I would rather they spend their time fixing real bugs or inconsistencies.
J~
My view is different. In a perfect world if update eveytick was selected variables should automatically persist. No extra coding should be necessary. Short of that ultimately its the programmers duty to understand the limitations of the platform he/she is coding on. Its unnecessary fluff and I would rather they spend their time fixing real bugs or inconsistencies.
J~
I actually agree.
Hi drwar,
I agree with most of what you say. However I differ here. Your idea of a perfect world is more a normal world. I worked as a full time programmer for 19 years and learned 11 languages during that period including TS4.0's EL but for End of day only. So all my experience has been that languages always hold their variables and never under the hood set them back to zero (in other words it generally goes without saying that they should). So MC's EL setting them back to zero (for whatever reason that may be) is an obvious anomaly in the real programming world. Someone said the real time TS does not do this when set to run the code on every tick. I can't say personally.
I agree that the manual should be read first (which I did by the way but at the time I bought MC the manual containing IntraBarPersist was not out there) Ironically most of my code updates on every tick and works without IntraBarPersist (Don't ask me how but it does).
Unfortunately there is some confusion and lost time being caused by it. A popup notice recommending those commands would be easy. In my database program you are looking at about 5 minutes time. That popup would save Marina a lot of support time and for only 5 minutes work that is a really good ROI. An option to Force intrabarpersist would obviously be harder since you are getting into compiler parsing, storing parameters etc. Something to consider well after the gold release maybe.
Like I said. I am done so I don't really care and MC 2.1.999.999 is probably my last release. I personally think MC 2.1.999.999 is a great program. I have no need to upgrade at all nor any interest in looking at another product.
John.
I agree with most of what you say. However I differ here. Your idea of a perfect world is more a normal world. I worked as a full time programmer for 19 years and learned 11 languages during that period including TS4.0's EL but for End of day only. So all my experience has been that languages always hold their variables and never under the hood set them back to zero (in other words it generally goes without saying that they should). So MC's EL setting them back to zero (for whatever reason that may be) is an obvious anomaly in the real programming world. Someone said the real time TS does not do this when set to run the code on every tick. I can't say personally.
I agree that the manual should be read first (which I did by the way but at the time I bought MC the manual containing IntraBarPersist was not out there) Ironically most of my code updates on every tick and works without IntraBarPersist (Don't ask me how but it does).
Unfortunately there is some confusion and lost time being caused by it. A popup notice recommending those commands would be easy. In my database program you are looking at about 5 minutes time. That popup would save Marina a lot of support time and for only 5 minutes work that is a really good ROI. An option to Force intrabarpersist would obviously be harder since you are getting into compiler parsing, storing parameters etc. Something to consider well after the gold release maybe.
Like I said. I am done so I don't really care and MC 2.1.999.999 is probably my last release. I personally think MC 2.1.999.999 is a great program. I have no need to upgrade at all nor any interest in looking at another product.
John.
Re: Suggestion - Update on every tick popup warning.
I cannot see why an Update on every Tick should have any influence in the variabel collection?John
My view is different. In a perfect world if update eveytick was selected variables should automatically persist.
Update on every Tick is only a UI-thing as far as I know!
Re: I actually agree.
Depends on the scopeSo all my experience has been that languages always hold their variables and never under the hood set them back to zero (in other words it generally goes without saying that they should).
I'm not sure if MC has function variable scopes? Or if all variables just belong to the same pool - do you?
If I understand you question correctly, I think they have scope within a function simply because you can use byref in the function. However, I have never tried to use the same variable name inside and outside of a function.
Cobol is a language that has all variables inside a common pool (can't do otherwise). VBA as you probably know can put a variables in a common pool by making them public.
As far as the "suggestion to use a popup" goes, if users are warned when they click "Update On every tick" that varibles will be zeroed on each new tick when using "Update on every tick" if they do not include the "IntraBarPersist" statement this will most definitely catch their attention. Then if, at this point , a second small paragraph suggests that they read the help on "IntraBarPersist" and "BarStatus" for more information and more importantly read all available documentation before doing any production programming (not including learning tests) I think you may get a generally better educated set of users (faster at least). A little fear can motivate people.
John.
Cobol is a language that has all variables inside a common pool (can't do otherwise). VBA as you probably know can put a variables in a common pool by making them public.
As far as the "suggestion to use a popup" goes, if users are warned when they click "Update On every tick" that varibles will be zeroed on each new tick when using "Update on every tick" if they do not include the "IntraBarPersist" statement this will most definitely catch their attention. Then if, at this point , a second small paragraph suggests that they read the help on "IntraBarPersist" and "BarStatus" for more information and more importantly read all available documentation before doing any production programming (not including learning tests) I think you may get a generally better educated set of users (faster at least). A little fear can motivate people.
John.
Hi Januson
Had a chance to read your post a little better.
When I say MC is setting a variable back to zero obviously I am saying it is setting the specific area in computer memory back to zero which normally in other languages would not be set back to zero. Ending a function and having those variables get lost is normal unless (as VBA can do) you define the function as static and the variables are not lost even when you exit the function and even though they are variables only found within that function (this is power way beyond EL). The EL tests I did were studies that had absolutely no functions in them at all. Some of the other situations that some of the other guys are describing I never had to deal with. One of my tests was contained in one of the posts mentioned in the first post of this thread. It is very simple and demonstraites the problem clearly.
John.
Had a chance to read your post a little better.
When I say MC is setting a variable back to zero obviously I am saying it is setting the specific area in computer memory back to zero which normally in other languages would not be set back to zero. Ending a function and having those variables get lost is normal unless (as VBA can do) you define the function as static and the variables are not lost even when you exit the function and even though they are variables only found within that function (this is power way beyond EL). The EL tests I did were studies that had absolutely no functions in them at all. Some of the other situations that some of the other guys are describing I never had to deal with. One of my tests was contained in one of the posts mentioned in the first post of this thread. It is very simple and demonstraites the problem clearly.
John.