Support Board
Date/Time: Sun, 23 Feb 2025 21:47:48 +0000
[Programming Help] - scope of sc.GetPersistenInt(*)
View Count: 829
[2021-02-16 20:34:15] |
User30743 - Posts: 365 |
how is with the sc.GetPersistenInt(*) or sc.GetPersistenDouble(*) etc. when using them in function scope. for example here I declare three sc.GetPersistenInt(*) - (1), (2), (3) - https://prnt.sc/zrocao my question is, if later on, somewhere in another function I want to declare other sc.GetPersistenInt(*), do I need to start from (4) or can I safely start from (1) again? Date Time Of Last Edit: 2021-02-16 20:35:07
|
[2021-02-17 08:09:48] |
User907968 - Posts: 833 |
ACSIL Interface Members - Functions: Persistent Variable Functions The persistent variables are specific to each individual study instance. Each study has its own persistent variable storage.
Therefore you would need to continue incrementing the key with each subsequent new persistent variable, otherwise the data will simply be overwritten. |
[2021-02-17 16:26:25] |
User30743 - Posts: 365 |
well that is not really good since if I would want to include this H file into other studies, I need to all the check that the numbers are not coliding
|
[2021-02-17 17:10:32] |
norvik_ - Posts: 106 |
It is wrong. You can include your header so much time you want. The docs are sometimes inconsistent. The previous posters mean that "each study instance has its own storage".
|
[2021-02-18 08:54:33] |
User30743 - Posts: 365 |
yes, that what i mean, imagine i am having a study (main scfexport function) where i use persist ints, hundreds of them, then after a time i decide to also include some of my H files which also uses persist ints - and i don't check their numbers -> so they may collide very easily.. so either i have to carefully choose the numbers or find another workaround..
Date Time Of Last Edit: 2021-02-18 08:55:47
|
[2021-02-18 15:48:49] |
norvik_ - Posts: 106 |
:) Exactly, one more time. For example, you have single dll with your header compiled. Each time, when you add it to the different charts, or even to the same chart for each instance of the applied study Sierra allocates a separate address space for persistent variables storage. So their indecies can be reused, excluding some specific cases.
|
[2021-02-18 16:29:39] |
User30743 - Posts: 365 |
but i dont have .h files compiled separately as dll that can be added to chart.. What i mean is that I use them as #include "some.h" when I write the main study
Date Time Of Last Edit: 2021-02-18 16:30:52
|
[2021-02-19 15:30:59] |
ForgivingComputers.com - Posts: 1012 |
I suggest putting all your persistent variable definitions in one .h file and include that file in all your functions. It doesn't hurt to have a persistent variable defined in a function and not ever get used by that function. This way you can essentially reserve the numbers going forward.
|
[2021-02-20 09:26:19] |
norvik_ - Posts: 106 |
For me is also helpful using a enum class for persistent variables indexing, with the names of enum members assoŃiated with further usage of the variables. this make me sure that nothing will be mixed when a lot of vars used.
|
[2021-02-20 10:04:56] |
User30743 - Posts: 365 |
Interesting.. dont have an idea how to do it to solve this problem though.. Could u paste a piece of code for inspiration?
Date Time Of Last Edit: 2021-02-20 10:06:41
|
[2021-02-20 16:28:28] |
norvik_ - Posts: 106 |
enum PesistentIntVarKey :std::int32_t
{ LAST_POSITION_STATE_POINTER_KEY = 1, LAST_REPLAY_STATUS_POINTER_KEY, MENU_ID_POINTER_KEY, ATTACHED_STOP_ORDER_POINTER_KEY, ATTACHED_TARGET_ORDER_POINTER_KEY, ENTRY_ORDER_POINTER_KEY, LAST_INTRADAY_RECORD_POINTER_KEY }; Than can be used in separate *h/*cpp in your own class: header.h class myclass
{ public: myclass(); void myfunc(SCStudyInterfaceRef sc); ... ... }; Source.cpp ...
myclass::myfunc(SCStudyInterfaceRef sc) { if(sc.PersistentInt(LAST_REPLAY_STATUS_POINTER_KEY) == 0) { ... //do something.. } } |
To post a message in this thread, you need to log in with your Sierra Chart account: