Is the old documentation still available? I think it has an alphabetic list of classes & objects which I found easier to use. I'm re-examining my cTrader Robots after a couple of years inactivity, and am noticing these doc difficulties.
In particular, where is the doc for the original MarketSeries price data collection now? For MarketSeries.High.Last or .Open or .Close etc from before Bars was a dataseries. (I wish people would always issue doc as downloadable pdfs so we KNOW we'll be able to easily refer to the same thing in future.)
As an example of being harder to use, for instance at https://help.ctrader.com/ctrader-algo/references/MarketData/Bars/Bars/#getprices the page says… public abstract DataSeries GetPrices(PriceType priceType) …but that leaves you wondering what a PriceType is, so why isn't the PriceType a link to its description? I think the old doc was better in this respect, linking to the description so you could quickly go forward, read, then return. And where is the info saying Bars is an array, or can use .Last(n) etc?
Obsolete documentation has been removed and obsolete classes are not documented, they are kept for backward compatibility only.
Indeed links to types would be helpful but you can still easily search them on the search bar.
Best regards,
Panagiotis
Making old documentation unavailable is a serious reliability issue for the platform - for instance how is a new programmer supposed to know how to maintain an old cBot or to know what the old API does in order to migrate it to the new?? And why should an ‘old’ programmer have to rely on memory in order to similarly maintain it?
And one might wonder what other undocumented features are in the API! I wonder what's going to happen after ‘cTrader Automate API’ is out, will the Algo API doc disappear?
This is not good enough - old doc, especially for APIs you still support it, needs to be available somewhere, at least in an archive area or something. I could point out there are some forum items, & even cBot examples in the current doc, that use the old methods.
Publishing doc as one pdf would be one way to achieve this long term availability , equivalent to a printed manual that can be referred to for ever. Otherwise you seem to be implying the only way to see old doc is to have downloaded the whole doc website a couple of years ago and host it locally. Traditional software companies keep their archived documentation - you can find what IBM API did 50 years ago even if enhanced or different now, or a 30-year old Windows 3.1 win32 API, or old Linux versions etc.
If an API is actually removed (not just deprecated) there at least needs to be migration doc on how to convert to the ‘new way’ (which to be complete would need to include doc on the ‘old way’ anyway!).
Perhaps the simplest solution nor now is to reinstate the old documentation, in an area clearly marked archive & not to be used for new cBots.
Obsolete documentation has been removed and obsolete classes are not documented, they are kept for backward compatibility only.
Indeed links to types would be helpful but you can still easily search them on the search bar.
Best regards,
Panagiotis
Making old documentation unavailable is a serious reliability issue for the platform - for instance how is a new programmer supposed to know how to maintain an old cBot or to know what the old API does in order to migrate it to the new?? And why should an ‘old’ programmer have to rely on memory in order to similarly maintain it?
And one might wonder what other undocumented features are in the API! I wonder what's going to happen after ‘cTrader Automate API’ is out, will the Algo API doc disappear?
This is not good enough - old doc, especially for APIs you still support it, needs to be available somewhere, at least in an archive area or something. I could point out there are some forum items, & even cBot examples in the current doc, that use the old methods.
Publishing doc as one pdf would be one way to achieve this long term availability , equivalent to a printed manual that can be referred to for ever. Otherwise you seem to be implying the only way to see old doc is to have downloaded the whole doc website a couple of years ago and host it locally. Traditional software companies keep their archived documentation - you can find what IBM API did 50 years ago even if enhanced or different now, or a 30-year old Windows 3.1 win32 API, or old Linux versions etc.
If an API is actually removed (not just deprecated) there at least needs to be migration doc on how to convert to the ‘new way’ (which to be complete would need to include doc on the ‘old way’ anyway!).
Perhaps the simplest solution nor now is to reinstate the old documentation, in an area clearly marked archive & not to be used for new cBots.
Having written “the only way to see old doc is to have downloaded the whole doc website a couple of years ago” I remembered the Internet Archive, and sure enough some old-format doc IS there!
A few dates are available, all very similar eg https://web.archive.org/web/20200811163336/https://ctrader.com/api/reference/bar but not old enough to have MarketSeries, which as I understand from Spotware's 2019 blog re ‘New Features in cTrader Automate API 3.7’ at https://ctrader.com/forum/ctrader-blog/22440/ was exactly equivalent to (a subset of) the Bars object, with the name of each of the several DataSeries within MarketSeries renamed, MarketSeries.Open becoming Bars.OpenPrices etc. The newer Bars object also provide access to a (single) collection/array of Bar structures [via Bars.Last(n) or Bars.LastBar] each of which has a set of property values having the same names as the original (multiple) DataSeries in MarketSeries, ie Bars.Last(2).Open & Bars.Last(2).Low etc.
I've seen the following 3 statements produce identical results (mjsWriteLine just outputs the text to an external log file that gets auto renamed when a backtest ends, to include some of the stats in the filename, and index is always Bars.Count-2 or less to avoid incomplete timesteps):
I still think it would help if there were a reference to MarketSeries in the current doc, rather than having to search around to find the blog item & other references.
“This post awaiting modaration.” - moderation! (e)
Thanks for your suggestions but we disagree with maintaining multiple versions of documentation. Old code does not need to be maintained but needs to be updated. Obsolete methods are only supported so that developers have enough time to update their obsolete code without service interruptions. New development is not supported. Therefore we do not plan to make it easy for people not to update their code.
Thanks for your suggestions but we disagree with maintaining multiple versions of documentation. Old code does not need to be maintained but needs to be updated. Obsolete methods are only supported so that developers have enough time to update their obsolete code without service interruptions. New development is not supported. Therefore we do not plan to make it easy for people not to update their code.
Best regards,
Panagiotis
OK, thank you for your replies on this. Hopefully you understand I wasn't really suggesting “maintaining” the whole old doc, as in having to review or edit it forever, I was merely suggesting either an archive area with complete as-is old doc (ie without relying on internet archive wayback), OR an easy-to-find set of migration docs, issued at the time of the change but to be considered an appendix of the current doc, on how to update from a deprecated way to a new way. Perhaps just an area with all the “what's new in release x” notes would do.
My main point was to suggest the information needed in order to comply with your assertion “Old code does not need to be maintained but needs to be updated” should be somewhere within the official current documentation, and, not only available by searching the internet or interpreting warning compile-time messages or finding old forum or blog items for items such as https://ctrader.com/forum/ctrader-blog/22440/
(My usage of the word “maintain” includes making changes for your “needs to be updated” so I wouldn't [pedantically] agree with “Old code does not need to be maintained”!)
Thanks for your suggestions but we disagree with maintaining multiple versions of documentation. Old code does not need to be maintained but needs to be updated. Obsolete methods are only supported so that developers have enough time to update their obsolete code without service interruptions. New development is not supported. Therefore we do not plan to make it easy for people not to update their code.
Best regards,
Panagiotis
OK, thank you for your replies on this. Hopefully you understand I wasn't really suggesting “maintaining” the whole old doc, as in having to review or edit it forever, I was merely suggesting either an archive area with complete as-is old doc (ie without relying on internet archive wayback), OR an easy-to-find set of migration docs, issued at the time of the change but to be considered an appendix of the current doc, on how to update from a deprecated way to a new way. Perhaps just an area with all the “what's new in release x” notes would do.
My main point was to suggest the information needed in order to comply with your assertion “Old code does not need to be maintained but needs to be updated” should be somewhere within the official current documentation, and, not only available by searching the internet or interpreting warning compile-time messages or finding old forum or blog items for items such as https://ctrader.com/forum/ctrader-blog/22440/
(My usage of the word “maintain” includes making changes for your “needs to be updated” so I wouldn't [pedantically] agree with “Old code does not need to be maintained”!)
More philosophically: without official information on how old code needs to be updated, there is no support for old code, which effectively means there is no real support for current code because the customer can't trust that a current feature they've used might not become old and without migration information ‘next week’.
Thanks for your suggestions but we disagree with maintaining multiple versions of documentation. Old code does not need to be maintained but needs to be updated. Obsolete methods are only supported so that developers have enough time to update their obsolete code without service interruptions. New development is not supported. Therefore we do not plan to make it easy for people not to update their code.
Best regards,
Panagiotis
OK, thank you for your replies on this. Hopefully you understand I wasn't really suggesting “maintaining” the whole old doc, as in having to review or edit it forever, I was merely suggesting either an archive area with complete as-is old doc (ie without relying on internet archive wayback), OR an easy-to-find set of migration docs, issued at the time of the change but to be considered an appendix of the current doc, on how to update from a deprecated way to a new way. Perhaps just an area with all the “what's new in release x” notes would do.
My main point was to suggest the information needed in order to comply with your assertion “Old code does not need to be maintained but needs to be updated” should be somewhere within the official current documentation, and, not only available by searching the internet or interpreting warning compile-time messages or finding old forum or blog items for items such as https://ctrader.com/forum/ctrader-blog/22440/
(My usage of the word “maintain” includes making changes for your “needs to be updated” so I wouldn't [pedantically] agree with “Old code does not need to be maintained”!)
More philosophically: without official information on how old code needs to be updated, there is no support for old code, which effectively means there is no real support for current code because the customer can't trust that a current feature they've used might not become old and without migration information ‘next week’.
Hi martins,
without official information on how old code needs to be updated, there is no support for old code, which effectively means there is no real support for current code because the customer can't trust that a current feature they've used might not become old and without migration information ‘next week’.
For obsolete classes and members you should get a message indicating what you should use instead. See below
Thanks for your suggestions but we disagree with maintaining multiple versions of documentation. Old code does not need to be maintained but needs to be updated. Obsolete methods are only supported so that developers have enough time to update their obsolete code without service interruptions. New development is not supported. Therefore we do not plan to make it easy for people not to update their code.
Best regards,
Panagiotis
OK, thank you for your replies on this. Hopefully you understand I wasn't really suggesting “maintaining” the whole old doc, as in having to review or edit it forever, I was merely suggesting either an archive area with complete as-is old doc (ie without relying on internet archive wayback), OR an easy-to-find set of migration docs, issued at the time of the change but to be considered an appendix of the current doc, on how to update from a deprecated way to a new way. Perhaps just an area with all the “what's new in release x” notes would do.
My main point was to suggest the information needed in order to comply with your assertion “Old code does not need to be maintained but needs to be updated” should be somewhere within the official current documentation, and, not only available by searching the internet or interpreting warning compile-time messages or finding old forum or blog items for items such as https://ctrader.com/forum/ctrader-blog/22440/
(My usage of the word “maintain” includes making changes for your “needs to be updated” so I wouldn't [pedantically] agree with “Old code does not need to be maintained”!)
More philosophically: without official information on how old code needs to be updated, there is no support for old code, which effectively means there is no real support for current code because the customer can't trust that a current feature they've used might not become old and without migration information ‘next week’.
Hi martins,
without official information on how old code needs to be updated, there is no support for old code, which effectively means there is no real support for current code because the customer can't trust that a current feature they've used might not become old and without migration information ‘next week’.
For obsolete classes and members you should get a message indicating what you should use instead. See below
Indeed. I was tending to overlook that fact, and accept that issuing warning hint messages does cover the migration aspect. [note to self: must really stop putting off actioning all the warning messages I've been ignoring!] Thanks again.
PanagiotisCharalampous
02 Sep 2024, 06:24
Hi there,
Obsolete documentation has been removed and obsolete classes are not documented, they are kept for backward compatibility only.
Indeed links to types would be helpful but you can still easily search them on the search bar.
Best regards,
Panagiotis
@PanagiotisCharalampous