Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Tue, 23 Apr 2024 11:37:58 +0000
v2195 recompilation...
View Count: 1766
| [2020-11-15 13:15:44] |
| binaryduke - Posts: 358 |
|
Are the v2195 time function changes that require recompilation backwards compatible to earlier versions or do we need to have a hard split on study version pre-2195/post-2195? When is the planned transition date for 2195 please? Ideally it would not be during the trading week. |
| [2020-11-16 09:49:50] |
| |
|
There is no backward compatibility. For the affected ACSIL functions in version 2195, custom studies built with older versions are not going to get any valid value out of those functions. And custom studies built with 2195 or higher, cannot be used in an earlier version. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-11-23 19:45:07] |
| gomifromparis - Posts: 244 |
|
Another breaking change ? Again ? With no backwards compatibility ? Again ? So now we need to deploy 3 versions to customers? pre-2151, 2151-2191 and 2195+ ?? This is going to be hell to deploy... |
| [2020-11-23 20:11:33] |
| |
|
Insist that the users update. There is no problem for them to be updating from any version after 2151. There is no consequence for them to do so. Just insist they update. Just simply update. That is not a problem. There is no problem with them updating. Absolutely do not go through all of this nonsense that you are. Just simply put out a new version and insist they update. This is all. There is no consequence to this. There is no hell here. That is a false claim. Put out a new version and tell them to update. We will force the update for you. We will force the update in two weeks. And furthermore, since the change with SCDateTime, there have been small related issues resolved since then. So users should be up-to-date anyway. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2020-11-23 20:41:14
|
| [2020-11-23 23:00:15] |
| @sstfrederik - Posts: 403 |
|
One suggestion in this regard. It would be great if we can drop the _2151 addition to the filename at some point. Right now the filename with _2151 gets precedence when loading a study. If starting at some new version you could give precedence to the normal file if it is compiled under a newer SC version that would be great. I can than continue to provide updates while using the original filename and stop providing the automatic download of the _2151 files. Also the user can keep their current chartbooks. Would save a ton of time in the future. Thanks for considering. Frederik |
| [2020-11-23 23:37:51] |
| Ackin - Posts: 1865 |
|
With regard to the first post, I would like to ask if at least the information about the changes could always be in advance. The Instructions / functions / structures that will change for example one week + description of what/where. Developers as well as regular users could prepare for it .... now everything was fast when the update was released (backwards incompatible). We are all your customers and you can make it very easy for us (if you want). note. You don't like "Thank you" but really sincerely thank you very much for the historical market depth, it's a really big step forward .... Date Time Of Last Edit: 2020-11-24 07:27:16
|
| [2020-11-25 15:11:10] |
| |
|
We will follow up here as soon as possible.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-11-26 16:51:57] |
| User90125 - Posts: 715 |
|
+1 Thank you. |
| [2020-12-13 09:03:32] |
| @sstfrederik - Posts: 403 |
|
Any progress on #5?
|
| [2020-12-14 22:27:15] |
| |
|
We think that what we need to do is to support any version number in a SC DLL file name. It would indicate the version it is compatible with, up until infinity if there is no other DLL (with the name the same aside from the version number) with a newer version number, or compatibility up to a DLL with a newer version number.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-12-15 00:12:27] |
| bradh - Posts: 854 |
|
We think that what we need to do is to support any version number in a SC DLL file name.
That will help, but it leaves behind a trail of dead soldiers. If you could create a way to remove obsolete versions from a user's data folder through the automatic distribution process, that would help keep things orderly. Today a client could have Study.dll, study_64.dll, and study_2151_64.dll, etc. Removing the file from the distribution file group would prevent new downloads, but the old files will remain in the user's data folder. The study_64.dll creates error messages in the add custom study window if it is below the supported version. Another user and I have also seen issues with too many dlls in the data folder, which is not good. If I could delete the first two, and be left with the highest version dll, that would be great. This capability would also allow me to move everyone to a specific minimum version 2xxx and only have one dll: Study.dll. An alternative is breaking everyone's copy of the study until they update, keeping only one version of the file: study.dll. This would not be a good choice for users. |
| [2020-12-15 01:31:03] |
| Ackin - Posts: 1865 |
|
Sierra Chart Engineering) We think that what we need to do is to support any version number in a SC DLL file name. It would indicate the version it is compatible with, up until infinity if there is no other DLL (with the name the same aside from the version number) with a newer version number, or compatibility up to a DLL with a newer version number. bradh) An alternative is breaking everyone's copy of the study until they update, keeping only one version of the file: study.dll. This would not be a good choice for users. bradh) If you could create a way to remove obsolete versions from a user's data folder through the automatic distribution process, that would help keep things orderly. As far as I know, the problem is only with the automatic update process. Sierrachart can find out for which version of the SC system the library was recompiled. I think it would be enough to ignore all the dlls from a certain version below (Sierra would ignore it as incompatible files...Nor would it display them in the program's library list). It won't hurt anyone, and the only thing that will grow is the size of the user's Data folder. Due to the size of the datafeed, this is a negligible size. Every developer should offer customers a batch script for deleting old files or instructions on how to do it manually, which can start completely outside of Sierrachart support. But I don't know how technically difficult (or even possible) it is to "ignore" old libraries by the system. Date Time Of Last Edit: 2020-12-15 02:04:18
|
| [2020-12-15 02:37:41] |
| bradh - Posts: 854 |
|
I think it would be enough to ignore all the dlls from a certain version below (Sierra would ignore it as incompatible files.
Agreed. |
| [2020-12-15 04:56:45] |
| |
|
The study_64.dll creates error messages in the add custom study window if it is below the supported version. Another user and I have also seen issues with too many dlls in the data folder, which is not good.
In the case where there are multiple DLL files with the same name except for _64 and the version number only one of them would ever be listed. This is the case now. The others would not be listed or cause any errors. All of the extra files, would not cause a problem related to, too many DLLs loaded and that is where the issue is. It is not too many files but just too many DLLs loaded but that seems to only have been a problem on the 32-bit version of Sierra Chart due to a Windows limitation. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2020-12-15 16:39:15] |
| @sstfrederik - Posts: 403 |
|
We think that what we need to do is to support any version number in a SC DLL file name. It would indicate the version it is compatible with, up until infinity if there is no other DLL (with the name the same aside from the version number) with a newer version number, or compatibility up to a DLL with a newer version number. Will filenames without a version number have precedence in this solution? When do you think this will be implemented? Naming the study file with a version should be optional in my opinion. Just looking to offer updates on studies from a filename without a version number. The _2151_ arrangement makes this not possible and I need to upload multiple versions. If from a certain SC version the dll without a version number can take precedence over the _2151_ filename I can phase out the autodownload of that _2151_ and do not need to make things to difficult managing all these different files. |
| [2020-12-30 08:22:36] |
| Sierra_Chart Engineering - Posts: 14052 |
|
We have not had time to get back to this and think about all of this. So we are not quite sure as to how this will all be done.
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
| [2021-01-02 07:03:21] |
| |
|
Refer to: Advanced Custom Studies DLL Loading Management Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
To post a message in this thread, you need to log in with your Sierra Chart account: