Support Board
Date/Time: Wed, 23 Sep 2026 13:20:46 +0000
How does SierraChart decide a plugin is incompatible?
View Count: 316
| [2026-08-08 20:40:09] |
| RetardedJimSimons - Posts: 102 |
|
In the latest release (at least going from 2882 to 2933), the time and sales structure went from float to double but Sierra happily loaded an old DLL compiled against 2882. I'm not sure if this causes problems eventually, but I expect it would because you have float Price -> double Price, uint32_t Volume -> double Volume which means something compiled against 2882 is going to be reading garbage. Should SierraChart be refusing to load these DLLs compiled against older versions? I was bit by this once before so I have a script to validate, which is how I noticed this, but now I'm wondering how it's supposed to work in the real world. Thanks. |
| [2026-08-09 00:03:56] |
| Sierra_Chart Engineering - Posts: 24945 |
|
How this works is explained here: https://www.sierrachart.com/index.php?page=doc/Whats_New.php#SCVer2895 The DLL will be loaded, but the Time and Sales data returned is just going to be empty. So no problem. 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 Date Time Of Last Edit: 2026-08-09 00:04:51
|
| [2026-08-09 15:05:56] |
| RetardedJimSimons - Posts: 102 |
|
OK, the issue I came across, if my notes are correct was building against SC_DLL_VERSION=2784 and deploying a version of sierrachart which was 2882. The s_ACSTrade structure grew from 2784->2882, which was causing crashes when the code was reading it because GetTradeListEntry read it into a smaller structure on the stack than expected. So how could I have avoided this issue? The way I'm avoiding it now is *always* building against the exact version of Sierra that's deployed. I hope this is making sense. |
| [2026-08-09 20:49:04] |
| Sierra_Chart Engineering - Posts: 24945 |
|
We are checking that structure now. Sierra Chart does know the version number of the structure that you pass, and it will not write into members that do not exist. This has always been the case. So if there is a problem it is a mistake on our side which we will fix now if it exists. 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 |
| [2026-08-09 20:55:18] |
| Sierra_Chart Engineering - Posts: 24945 |
|
Upon a code review related to s_ACSTrade, in recent versions of Sierra Chart but we are not exactly certain from what version without more research, there is not going to be a problem using a custom studies DLL compiled with an older version of Sierra Chart, that uses this particular data structure. From version 2882 and we are not sure up until what version, some versions, but not the most recent ones, would touch the new structure members even if they did not exist on a call to the Clear function. This has already been fixed. 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 Date Time Of Last Edit: 2026-08-09 20:55:46
|
| [2026-08-10 13:34:46] |
| RetardedJimSimons - Posts: 102 |
|
OK, it would be nice if we can prevent the DLL from loading if the version of SC is different from expected by returning FALSE from dllmain or something. But there isn't a way to check the runtime version of SC in DLLmain afaik.
|
| [2026-08-10 14:00:00] |
| Sierra_Chart Engineering - Posts: 24945 |
|
Sierra Chart is not going to do that. There is already an established method, for handling new structure members. The custom study does know the version of Sierra Chart: sc.VersionNumber(), and can do whatever it wants. 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 Date Time Of Last Edit: 2026-08-10 14:00:21
|
| [2026-08-10 14:52:47] |
| RetardedJimSimons - Posts: 102 |
|
. There is already an established method, for handling new structure members. The issue is that it obviously didn't work for the s_ACSTrade example above. All I want to do is make sure I don't accidentally load the DLL with an unexpected runtime sierrachart version (as I want to make sure built version == deployed version), but it's fine, my external script detects it eventually anyway. Thanks for confirming s_ACSTrade was indeed an issue though, took me a long time to figure out. |
| [2026-08-10 15:10:33] |
| Sierra_Chart Engineering - Posts: 24945 |
|
There was an issue with the new structure member handling, for that particular structure but it has been fixed.
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 |
| [2026-08-10 15:38:54] |
| RetardedJimSimons - Posts: 102 |
|
Good idea re version number though. I can use that to have a custom compatibility checking study and make a pop-up or alert if it doesn't match. Is there a way (similar to the unload dll udp command) to get sierra to unload the plugin dll? |
| [2026-08-11 01:24:18] |
| Sierra_Chart Engineering - Posts: 24945 |
|
No, there is no way to unload the DLL from ACSIL.
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 |
To post a message in this thread, you need to log in with your Sierra Chart account: