Login Page - Create Account

Support Board


Date/Time: Sun, 20 Sep 2020 20:39:37 +0000



[Sticky] [Locked] - Version 2151 Available: Foundation For Millisecond/Microsecond Timestamping

[2020-08-12 06:21:12]
Sierra_Chart Engineering - Posts: 793 | Ending Date: 2020-10-09
We have released version 2151 which contains a completely new implementation of the SCDateTime class within Sierra Chart which uses an integer rather than a double for the storage of Date-Time values.

This new implementation allows precise representation of microsecond timestamps without any floating-point error.

The epoch of this is not the standard UNIX epoch. It remains as December 31, 1899 so as to not cause confusion and potential issues with conversions between the old double format and the new integer format.


This version does not yet support true millisecond time stamping. We want to get this version out and ensure that there are no problems and then we will begin the changes to support millisecond time stamping and update all of our market data infrastructure. This second part should not take more than two weeks, once we begin which may not be for about 10 days or so.

Although extensive testing has already been done by us. We do not anticipate any issues.

We finally have gotten this major step completed.

You can install this version by following the procedure here:
https://www.sierrachart.com/index.php?page=doc/SoftwareDownload.php#FastUpdate

As of this writing, the current version is now 2156. So the current version now supports the updated date-time functionality.


The most important thing to understand is that this version breaks compatibility with existing compiled custom studies. Custom studies have to be rebuilt on 2155 or higher to use them with 2155 or higher. Although the change occurred at version 2151, there were subsequent changes and now ACSIL custom studies have to be recompiled using Sierra Chart version 2155 or higher.

This is nothing more than a simple recompile. Instructions:
https://www.sierrachart.com/index.php?page=doc/HowToBuildAnAdvancedCustomStudyFromSourceCode.html

However, this thread documents changes that may need to be made to a custom study:
https://www.sierrachart.com/SupportBoard.php?ThreadID=49810

If you have the source code for your custom studies you can do the recompile yourself. If you do not have the source code, then you need to contact the developer of the custom studies and ask them to recompile them on version 2155 or higher.

If you are providing custom studies to other users or you want to have two versions of your custom studies file supporting both 2151 and higher and 2148 and earlier, we have developed an easy strategy to support this.

The strategy to support this is that custom studies files that support 2151 or higher need to have this file format name:
[custom study file name]_2151.dll (32-bit)
[custom study file name]_2151_64.dll (64-bit)


The above format has been changed in version 2152 and now includes an _ character before the version number. Be sure to use the new above format.

This naming format is optional. It is not required.

Custom studies that support version 2148 and earlier just have the standard naming format without "_2151" in the filename.

----
If you are a custom studies developer providing studies to other users, then be sure to install this version and rebuild your custom studies and use _2151 in the file name (as shown above) and upload them here:
https://www.sierrachart.com/UserControlPanel.php?page=SetFileGroupsForCustomStudies

You will need to manually change the file name, _2151 is not going to be automatically added.

----

When updating to this version or higher it is a good idea that you are already running version 2110 or higher. If you go back to a prior version you will need to go back to a version greater or equal to 2110 because Date-Time values will be written as integers to files and you need that version or later for Sierra Chart to be able to read integer Date-Time values.

----

Finally we want to say that while this is very long overdue it did take a lot of work to make all the necessary changes in Sierra Chart and go through the testing especially with our very busy schedule, to support the new SCDateTime class which uses an integer.

The integer based class provides very stable and consistent Date-Time calculations and comparisons unlike when working with a double. Once we start getting into the microsecond resolution, we start running into issues and that was why it was difficult for us all of this time to support the true milliseconds which also required microsecond resolution in order to ensure there is always a unique timestamp per trade.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation
Date Time Of Last Edit: 2020-08-25 06:12:47
[2020-08-12 20:56:32]
jomanos - Posts: 20 | Ending Date: 2020-09-27
To be clear, if I have custom studies from third-party commercial developers, I will need to wait until they recompile their studies for 2149 and above, before installing any new release past 2148. Correct?

Thanks.
[2020-08-12 21:18:37]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Yes.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-12 22:58:38]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
This version is now available as the main prerelease. So to update to this version simply use Help >> Download Prerelease:
https://www.sierrachart.com/index.php?page=doc/SoftwareDownload.php#FastUpdate
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-12 22:59:00
[2020-08-13 05:24:00]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
We have released version 2150 as the main release but it does not include what we described in the first post. This is still only part of version 2149.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-13 06:32:46]
Ackin - Posts: 1167 | Ending Date: 2020-10-07
We have released version 2150 as the main release but it does not include what we described in the first post. This is still only part of version 2149.

Could you please tell us in advance the time assumption of the next main release that will contain both (2149 + 2150)?
[2020-08-13 10:46:24]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
We will do this tomorrow. We will release 2151 as the prerelease.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-13 10:46:56
[2020-08-13 11:53:13]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
We have just recompiled some custom studies against v2149 and tested with the new naming format:
[custom study file name]2149.dll (32-bit)
[custom study file name]2149_64.dll (64-bit)

The presence of files with these names in the /data folder causes Sierra Chart to unexpectedly exit while trying to Add Custom Study workflow. When the '2149' files are removed from the /data folder, there is no problem and the custom studies compiled with an earlier version are listed just fine (with a warning that they need to be recompiled).

For reference, the test custom study files were compiled using Visual Studio pulling in the v2149 sierrachart.h - compilation with Visual Studio is necessary for these files as they have external references, resources, etc., that cannot be handled by the remote compilation approach.
[2020-08-13 17:36:27]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Can you please privately attach these DLL files here and we will test. We do not know why there would be a problem like this. It does not make sense to us at all.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-13 17:36:34
[2020-08-13 17:46:46]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
Attached as requested. Perhaps because the original DLL name ends with a digit?
Private File
Private File
Attachment Deleted.
[2020-08-13 19:00:22]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
There is a heap corruption occurring:
Critical error detected c0000374

We do not know why. We tested this kind of configuration using user contributed studies and there was not a problem. We had two versions of user contributed studies. One of them using this naming format:
[custom study file name]2149_64.dll (64-bit)
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-13 19:00:35
[2020-08-13 19:13:22]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
OK. What code in a custom study is called during the directory scan? Should I check something?
[2020-08-13 21:07:19]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Every study function is called with sc.SetDefaults set to 1 to find out the names.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-13 21:07:26
[2020-08-13 21:31:39]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Due to the fact, that we have released version 2050 as the main release and this prerelease is 2149, we now have set the starting version number for the integer based SCDateTime class, to be 2151 now. So the file names need to use that version. We apologize for this.

2151 is now available.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-14 06:55:48]
Ackin - Posts: 1167 | Ending Date: 2020-10-07
This change only affects user studies. I see. May I ask what will be the compatibility with lower versions from the point of view saved collections and saved charts (when using the original Sierrachart studies)? Version 2093 caused problems for many SCH users.
Date Time Of Last Edit: 2020-08-14 06:59:26
[2020-08-14 07:17:17]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Saved Study Collections and saved Chartbooks from older versions are not affected by this change. Older versions are still fully compatible.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-14 07:22:33]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
Please can I 100% clarify post #16...

if a Study Collection references a Custom Study named "ABCDE",
...the platform will automatically determine whether to use the pre-/post-2151 version of this study if ABCDE.dll and ABCDE2151.dll (and their 64-bit equivalents) are present in the /data folder
...and therefore no change to the Study Collection is required?
[2020-08-14 08:18:46]
Ackin - Posts: 1167 | Ending Date: 2020-10-07
to binaryduke)

Exactly the same thing interests me (my prior post). We have a large number of collections and saved charts on my forum. Any change and re-storage of all material is very time consuming.
[2020-08-14 09:47:46]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
In response to post #17, yes, this is all automatic. Sierra Chart will know what DLL to use. This has been carefully thought through and also tested.

However, if someone updates to 2151 or higher and adds new instances of a custom study and then goes back to a prior version before 2149, then there potentially there can be a problem.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-14 09:49:01
[2020-08-15 11:05:57]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Update: We are underway, with the remaining work to support millisecond/microsecond time stamping.

So far no issues.

We do want to make one additional SierraChart.h header change related to strings which will require custom studies to be recompiled. This will be out we expect in 2152 but the DLL file naming will still remain the same.

This is a rare opportunity for us to improve the SierraChart.h header. So we want to take advantage of reasonable things we can do to clean up the header and improve performance.

The most significant performance improvement would be for us to remove most of the data members and just replace them with functions and to the extent that can be done without breaking any compatibility, we will do that.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-15 11:08:51
[2020-08-15 14:55:19]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
Triggered by post #20, we have been testing as regards our post #8.

Our studies create their inputs and subgraphs from core routines that are called during SetDefaults based upon the requirements of each study. This is to avoid duplication of code as we have many common Inputs and Subgraphs used by various studies.

We have noticed that we are getting exception errors during the assignment of an SCString (that we create) to a subgraph, e.g.


SCString ExampleName;
SCString ExampleSuffix;
int VariableNumber;

VariableNumber = 3;
ExampleSuffix = " Example";
ExampleName.Format("Subgraph %i %s", VariableNumber, ExampleSuffix.GetChars());

sc.Subgraph[0].Name = ExampleName;

This style causes an exception error. The Call Stack lists:

SCString::StringDelete(chart * String) Line 766
there seems to be an issue with m_DefaultString <Error reading characters of string.>

SCString::Initialize() Line 280

This style/functionality has been working fine prior to v2149/v2151. Should we await v2152?

As an aside, we do NOT use contiguous members of the sc.Subgraph array, e.g. we may use 0,1,2,3,4,58,59. We had an issue with this approach and the sc.Input array that we discussed with you here:
https://www.sierrachart.com/SupportBoard.php?ThreadID=39216
and here:
https://www.sierrachart.com/SupportBoard.php?ThreadID=46022 (post #24 relating to changes to the DisplayOrder member)
and modified our approach accordingly.

While I see that our use of non-contiguous members of the sc.Subgraph array could be causing the problem, the exception errors occur on the first call to our routine i.e. when populating sc.Subgraph[0]. We have also tested using contiguous members of the sc.Subgraph array by inserting code prior that sets the DrawStyle of all available subgraphs so that each member of the sc.Subgraph array is populated.
[2020-08-15 15:32:08]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
Further to #21, it seems anything we do now with strings during sc.SetDefaults for the sc.Input and sc.Subgraph array causes an exception error, e.g. sc.Input[1].SetCustomInuptStrings("ABC;DEF");

In Visual Studio we have the project character set as Unicode which has been fine up until now. Has something changed here?

...and running using the Visual Studio debugger does not produce any exception errors - we have a heisenbug here
Date Time Of Last Edit: 2020-08-15 16:02:00
[2020-08-15 23:23:15]
Sierra_Chart Engineering - Posts: 793 | Ending Date: 2020-10-09
Regarding post #21 and #22, there is no reason why there would be a problem. Nothing has changed in regards to ACSIL SCString or anything related up to this point with string processing and ACSIL or any string processing for that matter.

We cannot identify any problem in a debug or release build using Visual C++. What compiler are you using? Visual C++?
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation
[2020-08-16 01:17:57]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
One thing we are going to make sure of is when the same DLL is loaded but with two different names, related to the version number, that they are pointing to the same loaded DLL instance.

Perhaps the issue is related to there being two instances of the same DLL loaded.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-16 11:02:57]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
I have a simple custom study that compares the current bar date/time to session times and also stores the last processed date/time value in PersistentSCDateTime variable.

This compiles and works just fine on v2138.

Compiling the same study on v2151 provides the following error during remote compilation:


-- Starting remote build of Custom Studies Source files: DATETIMESTUDY.cpp. 64-bit -- 11:54:42
Allow time for the server to compile the files and build the DLL.

The remote build did not succeed. Result:

In file included from scstructures.h:98:0,
from sierrachart.h:22,
from DATETIMESTUDY.cpp:1:
scdatetime.h: In function 'constexpr int64_t ADJUST(int64_t, int64_t)':
scdatetime.h:147:1: error: body of constexpr function 'constexpr int64_t ADJUST(int64_t, int64_t)' not a return-statement
}

^
scdatetime.h: In function 'constexpr double ADJUST(double, double)':
scdatetime.h:156:1: error: body of constexpr function 'constexpr double ADJUST(double, double)' not a return-statement
}

^

-- End of Build -- 11:54:44

Date Time Of Last Edit: 2020-08-16 11:03:42
[2020-08-16 17:20:10]
User79074 - Posts: 74 | Ending Date: 2013-06-21 [Expired]
I get the same error as post #25... I am not able to compile my studies in 2151.
Date Time Of Last Edit: 2020-08-16 17:23:15
[2020-08-16 18:51:38]
gr93 - Posts: 13 | Ending Date: 2020-08-28 [Expired]
Does this mean we can use sub-second time intervals in charts?
[2020-08-16 18:55:28]
User907968 - Posts: 333 | Ending Date: 2020-12-27
Similar error message using local build with debug from within Sierra Chart -
g:\sierrachart_dev\acs_source\scdatetime.h(143): error C3249: illegal statement or sub-expression for 'constexpr' function
g:\sierrachart_dev\acs_source\scdatetime.h(141): error C3259: 'constexpr' functions can only have one return statement
g:\sierrachart_dev\acs_source\scdatetime.h(152): error C3249: illegal statement or sub-expression for 'constexpr' function
g:\sierrachart_dev\acs_source\scdatetime.h(150): error C3259: 'constexpr' functions can only have one return statement


No problem compiling in VS2019 or using MSVC v142 command line tool, and so far no problems in SC with recompiled code.
[2020-08-16 20:40:43]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Regarding post #25, we will have a new release out later this evening to resolve this.

Does this mean we can use sub-second time intervals in charts?
Yes but not right now. We will get to this as soon as possible.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-17 03:02:37]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
We will be releasing version 2152 in about 10 minutes. This will resolve posts #25, #26 and #28.

Although we think the problem in #28 is that the compiler you have installed, is too old. And does not support the language feature being used.

We did make one change to the file naming format. We have added an _ in front of the the optional version number:
[custom study file name]_2151.dll (32-bit)
[custom study file name]_2151_64.dll (64-bit)

We apologize for this, but this is our only opportunity to get the naming convention neat and clean. So we want to take advantage of this.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-17 03:03:21
[2020-08-17 13:54:47]
User79074 - Posts: 74 | Ending Date: 2013-06-21 [Expired]
Can you please confirm that with version 2152 there will be no more code breaking changes, so that we can calmly recompile our indicators and continue after that as usual?
[2020-08-17 16:16:25]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
Trying to compile in v2153 yields this error relating to sc.VersionNumber:


-- Starting remote build of Custom Studies Source files: buildtest_2151.cpp. 64-bit -- 17:15:12
Allow time for the server to compile the files and build the DLL.

The remote build did not succeed. Result:

buildtest_2151.cpp: In function 'void scsf_JAManagementLines(SCStudyInterfaceRef)':
buildtest_2151.cpp:34:20: error: cannot convert 'const char [9]' to 'SCString (*)()' in assignment
sc.VersionNumber = "20200816";

^

-- End of Build -- 17:15:14

Date Time Of Last Edit: 2020-08-17 16:16:43
[2020-08-17 16:29:33]
User79074 - Posts: 74 | Ending Date: 2013-06-21 [Expired]
There is also another issue. I have compiled using 2153 successfully. I want to support both the old Sierra Chart and the new Sierra Chart. I need to include all the dll files for my customers.

For example

# Old Sierra Chart version
test.dll
test_64.dll

# New Sierra Chart version
test_2151.dll
test_2151_64.dll


Now If I include all the versions of the test dll indicator in a zip and they extract it into the new Sierra Chart data folder, you will see redundant indicators of test_64.dll and test_2151_64.dll, which looks cluttered and bad. Can you hide the test_64.dll indicator from the study view in the new Sierra Chart if there is a test_2151_64.dll there? That would solve the problem. Thanks.
[2020-08-17 19:20:54]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
In regards to post #32, sc.VersionNumber is now function which returns SCString.

In regards to post #33 we need to develop a solution to this. We will do that.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-17 19:21:03
[2020-08-18 08:28:09]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
Re: post #34 & sc.VersionNumber, the same error is occurring in pre-release v2154.
[2020-08-18 11:14:21]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
This is not valid:
sc.VersionNumber = "20200816";
This is not supported. Refer to:
https://www.sierrachart.com/index.php?page=doc/ACSIL_Members_Variables_And_Arrays.html#scVersionNumber

Thinking about it, it is probably not unsafe but it serves no purpose.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-18 11:35:36]
binaryduke - Posts: 249 | Ending Date: 2020-09-30
#36 My bad. Confused sc.VersionNumber with sc.StudyVersion. Apologies.
[2020-08-18 11:42:57]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Now we have just updated the documentation for that member but still in the past that was not correct what the code was doing. But we would not expect it to cause any harm either.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-18 11:43:12
[2020-08-18 12:49:57]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
If you are using version 2154 and using the US equities data exchange with the Sierra Chart Exchange Data Feed you will now see true millisecond timestamps.

This is still under development and is not fully implemented but it is now available.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-18 12:50:37
[2020-08-18 13:45:21]
User79074 - Posts: 74 | Ending Date: 2013-06-21 [Expired]
Has #33 been addressed? My customers are already asking me to compile the indicators on the new Sierra Chart, but I want to make sure I support both Old and New Sierra Chart so that there will be no confusion for customers.
[2020-08-18 18:41:49]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Regarding post #40, yes this has been in the latest prerelease, 2154.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-19 16:30:49]
User220914 - Posts: 126 | Ending Date: 2020-09-30
this is FANTASTIC thank you
[2020-08-20 06:22:22]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
We have done some additional ACSIL cleanup in version 2155, to be released. The following functions and data members have been removed:

int AreTimeSpecificBars()

int AreRangeBars()

int AreNumberOfTradesBars()

int AreVolumeBars()

int AreRenkoBars()

int AreReversalBars()

int ArePriceChangesBars()

int AreDeltaVolumeBars()

int ArePointAndFigureBars()

sc.NumberOfTradesPerBar
sc.VolumePerBar
sc.RenkoTicksPerBar
sc.ReversalTicksPerBar
sc.PointAndFigureBoxSizeInTicks      
sc.PointAndFigureReversalSizeNumBoxes
sc.RenkoTrendOpenOffsetInTicks      
sc.RenkoReversalOpenOffsetInTicks
sc.DeltaVolumePerBar
sc.PriceChangesPerBar
sc.DailyDataBarPeriod
sc.DaysPerBar
sc.RangeBarValue
sc.RangeBarType  
sc.MonthsPerBar

These functions and members have been out of date now for years and have been documented as being deprecated during all of that time.

The replacement function to access this data is:
https://www.sierrachart.com/index.php?page=doc/ACSIL_Members_Functions.html#scGetBarPeriodParameters

The following text string members are now changed to functions:

SCString sc.VersionNumber();
SCString sc.UserName();
SCString sc.DataFilesFolder();
SCString sc.ServiceCodeForSelectedDataTradingService();
SCString sc.SCDataFeedSymbol();
SCString sc.CustomAffiliateCode();
SCString sc.ChartbookName();
SCString sc.ChartTextFont();

This is now a function:

n_ACSIL::DTCSecurityTypeEnum sc.SecurityType();

There are two reasons for this code cleanup. One reason is just to remove members which are just out of date and deprecated and the other reason is to improve performance and improve code safety.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-20 20:58:53
[2020-08-20 08:06:23]
User79074 - Posts: 74 | Ending Date: 2013-06-21 [Expired]
Is that the end of code breaking changes requiring indicator recompilation or will there be more?
[2020-08-20 10:22:29]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Yes this is all and we are releasing version 2155 in about 20 minutes.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-20 12:30:36]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
We expect to have a full release of the microsecond time stamping functionality, released over this weekend at least on half of the servers.

Trades will be timestamped to the millisecond and microseconds will increment by 1, for each trade within the same millisecond.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-20 12:31:18
[2020-08-20 13:26:51]
User79074 - Posts: 74 | Ending Date: 2013-06-21 [Expired]
I replaced sc.UserName with UserName() and there is a compilation error

error: 'UserName' was not declared in this scope

Same thing with ChartbookName(), doesn't work either.
[2020-08-20 15:25:23]
Ackin - Posts: 1167 | Ending Date: 2020-10-07
We expect to have a full release of the microsecond time stamping functionality, released over this weekend at least on half of the servers.

What version of Sierrachart will be needed for that? 2151?
[2020-08-20 17:03:04]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
I replaced sc.UserName with UserName() and there is a compilation error
Use:
sc.UserName()

As you can see the change is very simple.

What version of Sierrachart will be needed for that?
Any version. But 2151 or higher is needed to receive the microsecond timestamps. Really the user should be on 2156.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-20 20:57:43
[2020-08-20 21:57:42]
ejtrader - Posts: 597 | Ending Date: 2021-04-19
SC Team - What are the new functions for the following (version 2154 was the last version supported these functions)?

sc.AreTimeSpecificBars()
sc.RenkoTicksPerBar

Thanks
[2020-08-20 22:13:03]
Ackin - Posts: 1167 | Ending Date: 2020-10-07
ejtrader)


sc.AreTimeSpecificBars()
Type: Function
This ACSIL structure member is considered out of date/deprecated. Instead use the sc.GetBarPeriodParameters and sc.SetBarPeriodParameters functions.
https://www.sierrachart.com/index.php?page=doc/ACSIL_Members_Functions.html#scAreTimeSpecificBars

sc.RenkoTicksPerBar
Type: Read/Write integer variable.
This ACSIL structure member is considered out of date/deprecated. Instead use the sc.GetBarPeriodParameters and sc.SetBarPeriodParameters functions.
https://www.sierrachart.com/index.php?page=doc/ACSIL_Members_Variables_And_Arrays.html#scRenkoTicksPerBar
Date Time Of Last Edit: 2020-08-20 22:19:00
[2020-08-21 04:25:34]
Sierra_Chart Engineering - Posts: 793 | Ending Date: 2020-10-09
Yes post #51 is correct in regards to answering post #50.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation
Date Time Of Last Edit: 2020-08-21 04:25:42
[2020-08-21 05:59:18]
User79074 - Posts: 74 | Ending Date: 2013-06-21 [Expired]
I asked if you were done with code breaking changes in 2155 and you said yes. Now there is breakage once again in 2156. There needs to be a better system of communication for Sierra Chart users to know exactly what is going on. Especially since I am a vendor and people are writing me saying the indicators are broken after installing 2156, very frustrating and this has been consuming a lot of my time this week doing re compilations for my indicators every day.
[2020-08-21 06:19:20]
Sierra_Chart Engineering - Posts: 793 | Ending Date: 2020-10-09
In regards to post #53, what is the problem? We are unaware of any change in 2156 which would cause a compatibility issue with custom studies compiled in 2155.

There should be none and we are not observing anything ourselves.

We need precise details. There is no change between 2155 and 2156 which would cause a compatibility issue with custom studies.

The most likely explanation is that the users are using an ACSIL DLL which was not compiled with 2155 and they are running an older one.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation
Date Time Of Last Edit: 2020-08-21 06:36:41
[2020-08-21 09:49:45]
Ackin - Posts: 1167 | Ending Date: 2020-10-07
User79074: very frustrating and this has been consuming a lot of my time this week doing re compilations for my indicators every day.
Same experience as you and thanks for your words, I already felt like I was alone ...

In this respect, a very simple thing would suffice, as it works in other software. That they release Update only once in a longer period and in the meantime beta versions are created which are available only for testers and programmers (registered users see separate new content of new updates in separate sections). This would eliminate cases where the Newcomer automatically downloads the last update and then requires the full functionality of everything. Or ... chaotic patches when a part of an already functioning feature falls out and is fixed in the next update. I worked for many years in a development company. Errors can occur in the update ... it is not always possible to test everything, but it is always possible to improve communication with "colleagues in the same area" or facilitate the work of those who rely on this information. Not only errors but also changes in code writing.


Sierra_Chart Engineering: But 2151 or higher is needed to receive the microsecond timestamps.
Could you please post an opinion somewhere on the sierrachart forum for everyone what the change to milliseconds will bring? People trading live are worried about what will happen to their charts and settings in the trading session after this weekend.
You don't write anywhere how the change will affect people who do not update to 2151 and higher. Will the axes in the charts change? Will DOM / T & S / QuoteBoard change? Problems and unexpected states cannot be solved while running in trade.

You're an excellent trading platform, but in the press releases you keep things secret like the FBI.

I write because of many Sierrachart traders with whom I am in contact every day.

thanks
[2020-08-21 09:55:29]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
: very frustrating and this has been consuming a lot of my time this week doing re compilations for my indicators every day.
The changes were only during pre-releases. Not the main release. You could have also waited a few days, for the changes to be completed and become stable.

If a user of your custom studies wanted to update to the prerelease and could not run your custom studies, that is not a problem. They should just simply live without the custom studies for a few days or go back to the main release. It was their choice to update to the prerelease. There is no consequence for them to having updated to the prerelease and roll back to the main release.


People trading live are worried about what will happen to their charts and settings in the trading session after this weekend.
You don't write anywhere how the change will affect people who do not update to 2151 and higher. Will the axes in the charts change? Will DOM / T & S / QuoteBoard change? Problems and unexpected states cannot be solved while running in trade.
There has not been anything said about this because there is nothing to be concerned with. There is no impact if the user does not update, and if they do update, there still is no impact. There is nothing for anyone to be concerned with.

And if nobody notices an impact now, then this proves as a matter of fact, that there will be no impact because we have been running for several days now with some of our systems already updated with the latest code to support microsecond time stamping. Our server processes are aware, of the supported messages from the DTC clients and only send out compatible messages.


For example on one of our Denali data servers, for CBOT, the new microsecond time stamping is being transmitted. The same is true for our market statistics data, crypto currency data and Forex data. One of the systems has been updated for days now transmitting microsecond timestamps.
----

And we are also very happy, with how gracefully everything has worked, with next to zero problems. And the reason for this is that there has been extensive testing going on for more than a year now and lots of consideration of so many different things related to the time stamping change and a lot of updates to Sierra Chart over this time to make the transition very graceful with zero impact.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-21 10:16:05
[2020-08-21 10:14:28]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
We may also decide that for the CME data, and all of the exchange feeds, that we may just simply support the native exchange microsecond time stamping, if available, rather than just the millisecond component.

We will evaluate that over the next few days.



Update: Our decision on this, is not to do this because it does increase the amount of bandwidth requirement for data transmission. Already millisecond time stamping is increasing the amount of bandwidth requirement. Not by much but a little.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-21 10:19:35
[2020-08-21 10:18:04]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
The only issue that someone can face, which does create some extra effort and an issue them would require help/guidance from us is if they update to 2151 or higher and then go back to a version earlier than 2110.

In this case they would need to re-download a portion of their historical Intraday data, and go back to backup Chartbook files and a backup of the main configuration file.

The thing to keep in mind is that there are automatic backups made, and the historical Intraday data is readily available to be re-downloaded.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-21 10:18:23
[2020-08-21 10:22:48]
BlakJak - Posts: 82 | Ending Date: 2020-10-13
Thanks for working on this. It is working perfectly for me and I have been waiting for the millisec timestamping to update some of my orderflow studies which currently use computer timestamps (not so successfully). I am glad it is done.
[2020-08-23 18:16:10]
BrMa - Posts: 56 | Ending Date: 2020-12-05
Dear Sierra Chart Engineering,

first of all thank you for the update and the intended increase in precision out of a timing perspective.

I worked through it today and adapted my code. When doing this I approached three minor topics I'd like to address here and ask you for updates:

1) In my code I'm using sc.GetEndingDateTimeForBarIndex() which returns a double value representing the ending Date-Time of a chart bar specified by its bar index. Isn't that inconsistent? From my point of view the interface should return a consistent data-type representing date/time information - whatever you decide to go for. sc.GetTradingDayStartDateTimeOfBarForChart() is affected as well.
For the time being I'm passing the double value returned to the SCDateTimeMS()-constructor which seems to me to be a multiple convert SCDateTime (I guess used internally) -> double -> SCDateTimeMS!?
scdatetime.h says SCDateTimeMS is derived from SCDateTime - just adapted methods for SCDateTimeMS... so it would be much more efficient to have the "original" data-type for further processing...

2) In post #43 you mentioned that the following text string members are now changed to functions but documentation lacks information or is at the wrong place:
SCString sc.VersionNumber();
Marked as type function but still in the secion Variables and Arrays - not Functions
SCString sc.UserName();
Marked as Read-only Character string and still in the secion Variables and Arrays - not Functions
SCString sc.DataFilesFolder();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not Functions
SCString sc.ServiceCodeForSelectedDataTradingService();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not Functions
SCString sc.SCDataFeedSymbol();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not Functions
SCString sc.CustomAffiliateCode();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not Functions
SCString sc.ChartbookName();
Marked as Read-only SCString variable and still in the secion Variables and Arrays - not Functions
SCString sc.ChartTextFont();
Marked as Read-only string variable and still in the secion Variables and Arrays - not Functions

3) As with normal coding guidelines and also your naming conventions for functions up to now I'd suggest to add a "get" in front of the function name - e.g.: sc.getVersionNumber() or sc.getUserName()
Date Time Of Last Edit: 2020-08-24 06:18:13
[2020-08-24 10:26:59]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
1. In general we do not change functions in order to not break compatibility in a way which requires code changes if we can avoid it.

There is a very good reason why that function returns a double and that is when SCDateTime is passed as a copy either as a return value or as a parameter the GCC compiler handles it differently for unknown reasons than Visual C++ and therefore there is a stack corruption which occurs because there is a slightly different convention/size being used with that parameter type. This is avoided by using a double.


Regarding the other items, the documentation will be updated.

3. You are not the one providing support here. You need to understand, the massive load and the massive complaints we deal with the user support. This is why we do not put Get here. We do not want to put up with the complaints. Understand that! There always is a reason for everything. We can make all kinds of changes to improve things tremendously, but we do not want to deal with all of the dumb questions that get posted here. It really is quite dumb when people basically tell us that their code does not compile, and they can easily look at the documentation and see that function has been renamed and is also documented on the What is New page.

Why do you think we complain so massively about Interactive Brokers. A true garbage service. Complete utter garbage. Our intelligence level is not worth stooping down to that level of garbage for any price. For any price. And when we ask people to pay extra for support which is well justified they do not even want to pay.

Just look at a lot of the nonsense that gets posted on this Support Board . We should start deleting more posts (Which we will do). It is astounding the level of alleged problems that people post which are just simply just nonexistent or are the result of operating system problems or external service issues, or failure to read documentation.

Just look inside of this thread at the things that get posted.

And we decided not to remove sc.FreeDLL even though it is completely unused because we want to have a most studies recompile without any error and eliminate unnecessary support questions.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-25 09:35:51
[2020-08-24 10:39:01]
BrMa - Posts: 56 | Ending Date: 2020-12-05
Sorry, I did not want to bother you. My post was meant to be constructive - NOT provoking.
I do appreciate your tool a lot! That's why I thanked in the beginning of the post for the step you've taken.
[2020-08-27 22:34:31]
User806682 - Posts: 9 | Ending Date: 2021-02-01
Hello -

I use to have this working before the recent upgrade for a custom chart I've created.
The method `GetMillisecond` on the IntradayRecord is returning 0 every time.
This is inside the `sc.fp_ACSCustomChartBarFunction` function.

Could you tell me what I'm doing wrong here.


const s_IntradayRecord record = ChartBarInterface.NewFileRecord;
const SCDateTimeMS date = record.DateTime;
date.GetMillisecond(); // This now returns 0 every time

Thanks for the help.
[2020-08-27 22:44:13]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Use GetMicrosecond instead.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
[2020-08-28 23:02:07]
User654912 - Posts: 25 | Ending Date: 2021-01-12
How can I receive trade data structures with the new milli/micro timestamps via DTC?

The structs I'm interested in are:
s_MarketDataUpdateTradeWithUnbundledIndicator
or
s_MarketDataUpdateTradeWithUnbundledIndicator2

The default struct returned when I make a market data request with DTC is:
s_MarketDataUpdateTradeCompact

Thanks
[2020-08-29 04:36:32]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
For the latest DTC server messages, bitwise or these with the Integer_1 variable in the logon request:
const unsigned int DTC_LOGON_REQUEST_INTEGER_1_USE_MARKET_DEPTH_UPDATE_FLOAT_WITH_MS_MESSAGES = 0x80;
const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_NO_TIMESTAMP_MARKET_DATA_MESSAGES = 0x400;
const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_MARKET_DEPTH_SNAPSHOT_LEVEL_FLOAT = 0x800;
const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_MARKET_DATA_UPDATE_TRADE_WITH_UNBUNDLED_INDICATOR_2 = 0x80000;
const unsigned int DTC_LOGON_REQUEST_INTEGER_1_SUPPORT_MARKET_DATA_UPDATE_BIDASK_MICROSECOND_MESSAGE = 0x100000;

Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.
Date Time Of Last Edit: 2020-08-29 04:38:14
[2020-08-30 00:38:09]
ejtrader - Posts: 597 | Ending Date: 2021-04-19
SC Team - I have version 2159 running one with All Services and one with Futures Order routing.

With All Services - I get true milli/micro second timestamps in T&S data and only a counter based timestamp with Order routing service. What setting I should use to make sure I get true timestamp for the T&S data? Both of them are using Denali feed. Is this data dependent on the server I am connected to or some setting on the client side?

Attached are the T&S data from these 2 sources.

Thanks
Date Time Of Last Edit: 2020-08-30 00:39:37
imageAllServices_TS_data.JPG / V - Attached On 2020-08-30 00:37:50 UTC - Size: 216.9 KB - 46 views
imageFurtues_OrderRouting_TS_Data_IncorrectTimestamp.JPG / V - Attached On 2020-08-30 00:37:57 UTC - Size: 144.96 KB - 51 views
[2020-08-30 17:45:59]
ejtrader - Posts: 597 | Ending Date: 2021-04-19
Update to Post #67.

Explored further on this. Interestingly the same data works fine and displays correctly(DateTime) during replay. Same T&S data gets counter based time immediately after the replay. (Same chart/instrument - no other changes). The T&S data is from Friday - when the charts were running.

SC Team - Would you please review and comment?

Thanks
Date Time Of Last Edit: 2020-08-30 20:14:24
imageSC_TS_Data_AccurateDuringReplay.JPG / V - Attached On 2020-08-30 17:44:52 UTC - Size: 229.54 KB - 54 views
imageSC_TS_Data_ImmediatelyAfterReplay_Incorrect.JPG / V - Attached On 2020-08-30 17:45:00 UTC - Size: 232.81 KB - 51 views
[2020-08-31 13:29:52]
ejtrader - Posts: 597 | Ending Date: 2021-04-19
Post # 67 & 68 can be marked as closed. Read the release notes for 2156 and apparently related to Market Data servers update. All good now with respect to the T&S data displayed correctly now.

https://www.sierrachart.com/index.php?page=doc/Whats_New.php#SCVer2156

Thanks
[2020-08-31 15:39:20]
Sierra Chart Engineering - Posts: 89756 | Ending Date: 2021-04-05
Reviewed.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. If possible please keep your questions brief and to the point. Please be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

If your question/request has been answered and you do not have anything further, then it is easiest for us if you do not reply again to say thank you.

To post a message in this thread, you need to login with your Sierra Chart account:

Login

Login Page - Create Account